Dangerous workaround for running scripts from an iFrame... #5955

ericshulman · 2021-08-16T03:38:57Z

ericshulman
Aug 16, 2021
Maintainer

In a recent post in the GoogleGroups, CJ.veniot wrote:

I was thinking: could I use an iFrame to include simple javascript in a tiddler without getting into macros or plugins that enable javascript.

And, if I could, then could I set things up so that the iFrame is showing javascript dynamically created by the tiddler ?

So here is a way to show a digital clock in TiddlyWiki, for non-programmers who just want to copy and paste javascript code from the web without figuring out how the javascript code works :

Put this in a brand new tiddler:

<$vars vSrcDoc={{{ [[<body>
  <div id="clockDiv"></div>
  <script>
    let clockEl = document.getElementById("clockDiv");
    function getClockTime() {
      let date = new Date();
      let hr = date.getHours();
      let min = date.getMinutes();
      let sec = date.getSeconds();
      hr = ("0" + hr).slice(-2);
      min = ("0" + min).slice(-2);
      sec = ("0" + sec).slice(-2);
      clockEl.innerHTML = `${hr}:${min}:${sec}`;
    }
    setInterval(getClockTime, 1000);
  </script>
</body>]] }}}>
<iframe srcdoc=<<vSrcDoc>> style="border:none;width:100%;"></iframe>
</$vars>

Sneaky sneaky, has me wondering what kind of other fun things could be done...

I was going to reply to his post in the GoogleGroup, but then I though perhaps this is too dangerous a topic for discussion there!

The danger is that the javascript running in the iframe can use "window.parent" to do some nasty things.

For example, the following tiddler content will automatically delete "$:/HistoryList" as soon as the tiddler containing the iFrame is viewed, which instantly wreaks havoc on the main Story column, with no obvious way to recover.

<$vars vSrcDoc={{{ [[<body><script>window.parent.$tw.wiki.deleteTiddler("$:/HistoryList");</script></body>]] }}}>
<iframe srcdoc=<<vSrcDoc>> style="border:none;width:100%;"></iframe>
</$vars>

What can we do to prevent this kind of mayhem?!?

pmario · 2021-08-16T09:12:58Z

pmario
Aug 16, 2021

@ericshulman ... It seems your formatted source doesn't work. I needed to modify it a bit.

\define source()
<body>
  <div id="clockDiv"></div>
  <script>
    let clockEl = document.getElementById("clockDiv");
    function getClockTime() {
      let date = new Date();
      let hr = date.getHours();
      let min = date.getMinutes();
      let sec = date.getSeconds();
      hr = ("0" + hr).slice(-2);
      min = ("0" + min).slice(-2);
      sec = ("0" + sec).slice(-2);
      clockEl.innerHTML = `${hr}:${min}:${sec}`;
    }
    setInterval(getClockTime, 1000);
  </script>
</body>
\end

<$vars vSrcDoc={{{ [<source>] }}}>
  <iframe srcdoc=<<vSrcDoc>> style="border:none;width:100%;"></iframe>
</$vars>

They finally found a way to directly execute "copy / pasted" <script> code :) ... But I think in this case it is valid.

If the code would come from a different domain, imo the window.parent. ... example won't work, because of the "same origin" policy. ... If the user copy pastes your code into a tiddler and runs it, imo that's a valid behaviour. ...

Users already can create wikitext that runs havoc using action-setfield. .. See: #5916

0 replies

pmario · 2021-08-16T09:35:39Z

pmario
Aug 16, 2021

What can we do to prevent this kind of mayhem?!?

We would need to modify the html-parser and add some sanitation to some elements. With sanitation I mean: Adding some parameters to the widget tree eg: <iframe referrerpolicy="same-origin">

To lock it down we would need <iframe referrerpolicy="no-referrer" sandbox="" allow="" "> ... Where we could add some configuration titddlers that would let us specify what's allowed and what is not

5 replies

flancast90 Aug 16, 2021

Great ideas! I just opened my own issue on this topic, not seeing this first. Another implementation to steal the GitHub PAT from a user would look like:

<$vars vSrcDoc={{{ [[<body> <div id="clockDiv"></div><script>document.getElementById('clockDiv').innerHTML = `<a id="xss" href="javascript:alert('Your GitHub Token is:'+localStorage.getItem('tw5-password-github')+'. If it is blank, you probably don\\'t have TW GitHub saving configured');"></a>`; document.getElementById('xss').click();</script></body>]] }}}>
<iframe srcdoc=<<vSrcDoc>> style="border:none;width:100%;"></iframe>
</$vars>

I agree with the proposal for sandboxing, etc.

pmario Aug 16, 2021

The token is stored in the browser local storage. So you have to have access to the users computer to get this info. If someone has full access to the PC they have a much bigger problem ... ;)

Jermolene Aug 16, 2021
Maintainer

I think @flancast90 is correctly pointing out that if an attacker can induce you to import a malicious tiddler into your private wiki then JS within that tiddler could exfiltrate user data.

To mitigate attacks like that we try to restrict JavaScript execution to explicit module tiddlers, by neutralising script tags and event handler attributes etc. The fact that we've managed to miss this particular attack vector shows that it is wise for users to be very cautious about importing other peoples tiddlers into their own wikis.

pmario Aug 16, 2021

The fact that we've managed to miss this particular attack vector shows that it is wise for users to be very cautious about importing other peoples tiddlers into their own wikis.

That's absolutely true. But as you point out, it is already possible to import module tiddlers and "raw markup" code. I think raw markup is even more dangerous than this iframe-issue. ...

As far as I know, if iframe-content comes from a 3rd party uri it only has access to the "main site" via a "postmessage()" function and window.parent doesn't work. ... right? ... "raw markup" has no such protection.

So it mainly is a "social engineering" vulnerability, which imo needs to be addressed in 2 ways. Information, "core sanitation" and may be a configuration option, for those who think they know what they do. ..

Jermolene Aug 16, 2021
Maintainer

That's absolutely true. But as you point out, it is already possible to import module tiddlers and "raw markup" code. I think raw markup is even more dangerous than this iframe-issue. ...

As far as I know, if iframe-content comes from a 3rd party uri it only has access to the "main site" via a "postmessage()" function and window.parent doesn't work. ... right? ... "raw markup" has no such protection.

That is correct, as I understand it.

So it mainly is a "social engineering" vulnerability, which imo needs to be addressed in 2 ways. Information, "core sanitation" and may be a configuration option, for those who think they know what they do. ..

Yes, that's fair.

Jermolene · 2021-08-16T16:16:42Z

Jermolene
Aug 16, 2021
Maintainer

As @ericshulman says, the problem is not so much that iframes can be created that contain executable JavaScript, but that the JS has access to the TiddlyWiki global scope:

The danger is that the javascript running in the iframe can use "window.parent" to do some nasty things.

The fix would indeed appear to be to enforce a sandbox attribute on iframes. It actually needs to be done at render time, not parse time. We need to consider whether we should allow users to override it on a per-iframe and/or global basis, as @pmario suggests.

2 replies

AnthonyMuscio Aug 17, 2021

Not all, in fact many TiddlyWiki's, reside in peoples own document folders on LAN drive. The potential features that one could introduce, by design for cases where we do not need strict limitations are in my view a reason to allow this to be overridden if desired.

I have no difficulty with the additional security being applied by default and I think you can provide an override that is somewhat restricted like it needs a save and reload, and a dialogue box to confirm before enabling the override.

I would hate the security tail to wag the dog and reduce the possibility of innovation.

Keep in mind If I really wanted to do something malicious like this I could use raw mark-up, even a direct edit of the html file.

Perhaps the best approach to security would be a plugin that tests the wiki to report what security issues exist in it. eg report iframes not sandboxed. Non standard modules, edited system tiddlers ....

Regards
Tones

ericshulman Aug 17, 2021
Maintainer Author

...If I really wanted to do something malicious like this I could use raw mark-up, even a direct edit of the html file.

Using raw markup requires a save-and-reload for it to take effect, and editing the html file requires access to the user's filesystem (either via remote network access or actual physical access to their computer).

In contrast, the iframe scripting method will execute it's payload immediately upon viewing the offending tidder, without even the modest safety net of a save-and-reload cycle. All that is needed is a bit of social engineering to convince the user to import the tiddler into their current TiddlyWiki session.

Maybe the solution is to disallow direct use of HTML iframes, and instead provide an $iframe widget -- with full support for all standard iframe attributes -- that acts as a wrapper pass-thru to an underlying HTML iframe with default sandboxing and the ability to use sandbox="..." to specify any of combination of the sandbox allow-* attribute values (see https://www.w3schools.com/tags/att_iframe_sandbox.asp for a list of attribute values).

This would break backward-compatibility for any TiddlyWiki that is currently using iframes, but with a quick fix by simply changing from <iframe ...> to <$iframe ...> without changing any of the existing attributes (except, of course, for adding an overriding sandbox="..." attribute if needed).

-e

Dangerous workaround for running scripts from an iFrame... #5955

Uh oh!

ericshulman Aug 16, 2021 Maintainer

Replies: 3 comments · 7 replies

Uh oh!

pmario Aug 16, 2021

Uh oh!

Uh oh!

pmario Aug 16, 2021

Uh oh!

flancast90 Aug 16, 2021

Uh oh!

pmario Aug 16, 2021

Uh oh!

Jermolene Aug 16, 2021 Maintainer

Uh oh!

pmario Aug 16, 2021

Uh oh!

Jermolene Aug 16, 2021 Maintainer

Uh oh!

Jermolene Aug 16, 2021 Maintainer

Uh oh!

Uh oh!

AnthonyMuscio Aug 17, 2021

Uh oh!

ericshulman Aug 17, 2021 Maintainer Author

ericshulman
Aug 16, 2021
Maintainer

Replies: 3 comments 7 replies

pmario
Aug 16, 2021

pmario
Aug 16, 2021

Jermolene Aug 16, 2021
Maintainer

Jermolene Aug 16, 2021
Maintainer

Jermolene
Aug 16, 2021
Maintainer

ericshulman Aug 17, 2021
Maintainer Author