[tw5] Just a goofy thought: a way to get javascript into a Tiddler

Google Group (Read Only)
#1

I don’t know what made me think of this.

In case this has not been brought up in a while (I doubt this is new to seasoned folk) …

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={{{ [[

]] }}}>
<iframe srcdoc=<> style=“border:none;width:100%;”>
</$vars>

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

#2

Better to keep the HTML readable, drag this package of two tiddlers into some TiddlyWiki:

#3

Better to keep the HTML readable, drag the attached json with two tiddlers into some TiddlyWiki:

(Attachment TwClock.json is missing)

#4

Charlie,

Thanks for this.

  • I presume it is secure because the iframe acts like a sandbox

  • The result will be what is displayed because there is no permitted way to impact the wiki
    I wonder if

  • A template can be used rather than the variable? yes the following worked

  • Use a TiddlyWiki template for the content of the iframe may need to wikify first.
    Have you played with the innerwiki plugin it’s similar but different? It can pass a lot more data to the iframe (I think), in fact can build a whole wiki inside the iframe.

Speculation;

  • Could this be used by students of javascript?
  • what kind of Javascript code can be implemented this way?
  • Could it access functions defined in the parent wiki eg raw tags?
    • I suppose it could if added to the template.
  • Could we use iframes in which to publish complete html pages including javascript as a website development or learning tool.
    Regards

Tones

#5

Charlie

I assume this is a very clever solution!
Can we say this is a backdoor to inject JS into TW.
Of course I am not familiar with iframe features in TW!

Best wishes
Mohammad

#6

Well, I’m more assuming than presuming that it is secure.

Yup, template in my quick follow-up after initial post looks much nicer.

Nah, I have not played with the Innerwiki plugin. I largely prefer single-file TiddlyWiki’s, and Innerwiki seems to be for TiddlyWiki on nodejs. I’ll try it sometime for giggles, but my goal here is the ability to quickly add simple javascript needs with simple copy/paste and without javascript macros.

I’m loving the speculation.

  • In particular: TiddlyWiki as an editor for creating web pages (HTML, CSS, javascript)

Be aware that the TiddlyWiki cannot see what is in the iFrame, and the iFrame cannot see what is in the TiddlyWiki.

However and hypothetically: the HTML fed to the iFrame can be dynamic (i.e. the HTML created by TiddlyWiki, thus allowing TiddlyWiki to include TiddlyWiki info in the HTML. Interesting possibilities …

#7

Yeah, for sure a backdoor way to get javascript into TW, I’m assuming safe (i.e. TiddlyWiki knows nothing about the javascript in the iFrame, and the javascript in the iFrame knows nothing about the javascript.

So should be a nice little sandbox.

#8

I am not so sure about the security running javascript in iframes. Everywhere we are told, that we should sandbox the iframe for that reason. I am not the one to know anything about it - I am just worried.

It is all about knowing what we are doing - and I am not in the know.

Birthe

#9

Updated one of the tiddlers in the JSON package. New version attached.

The addition highlighted below:

**document.oncontextmenu = function() {** **return false;** **};** let clockEl = document.getElementById("clockDiv");

…

The reason for the added code: block access to the back button in the iFrame (by blocking access to the entire menu), which winds up performing the back button operation on the entire browser page.

(Attachment TwClock.json is missing)

#10

Another code sample. Drag the attached to TiddlyWiki.com .

The “Random HTML” tiddler is a patchwork of code bits I scammed from the web. This Tiddler has the javascript needed to get a random value from a comma-separated-value list and present that value.

The “Getting Random Values” tiddler puts in a variable (“vReplacement”) a comma-separated-value list of tiddler titles, for all tiddlers having “HTML” in the title. (Yeah, I could have been a little bit more creative and put together something much more practical.)

The “source document” for the iFrame in “Getting Random Values” alters the transcluded HTML (from “Random HTML” tiddler) by substituting a keyword in the HTML (“CsvList”) with the value of the “vReplacement” variable.

So this little sample code pattern demonstrates how an iFrame can show dynamically created/modified HTML+javascript.

(Attachment TwRandomFromCsvList.json is missing)

#11

This seems EXTREMELY INSECURE. What is to stop an attacker from injecting malicious JS into a tiddler, regardless of whether it is “sandboxed”.
Paste this Proof-of-Concept into a blank tiddler. What it does it steals your GitHub PAT if you have it configured, and alerts it to you. While I have not done it here, I could easily make it both invisible and have it email me the PAT’s it gathers.

CODE:

<$vars vSrcDoc={{{ [[

]] }}}>

<iframe srcdoc=<> style="border:none;width:100%;">

Long-story-short, an attacker can easily bypass any sanitation TW employs, and harvest credentials from various sites. It is my belief that this issue needs to be fixed immediately, and brought to the attention of Jeremy and other devs.

I would be happy to help on the repair process. I have some experience with PenTesting and fixing XSS vulnerabilities (mainly in my own applications). I would recommend adding a listener to TW changes, and checking for an iframe code. If it does contain this, TW should add a sandbox constraint on it (<iframe>: The Inline Frame element - HTML: HyperText Markup Language | MDN)

#12

Alerted Dev Group of potential vulnerability: [BUG] Potential XSS Vulnerability · Issue #5958 · Jermolene/TiddlyWiki5 · GitHub. Hopefully they re-imagine the TW Github saving mechanism, as I proposed, to something beyond the scope of what the iframe can access (such as browser Cookie)

1 Like
#13

It kind of sounds like the iFrame element should then be outright eliminated from the web entirely.

That might be problematic.

Re security, couldn’t any tiddler that is a javascript macro be altered for nefarious purposes just as easily as injecting malicious javascript into an iFrame?

#14

cj.v…,

I don’t have much experience with JS macros in TW, but I can imagine it would be the same, especially if there is no sanitisation whatsoever. As to eliminating iframes, normally there is no way to break-out of it. However, in the case of my Proof-of-Concept with TW, the localStorage is global, and can be accessed by ANY SITE. This is just one more reason I believe TW should use browser cookies: they are not accessible from inside iframe, and have more options for security and access.

#15

Scratch that.

Seems like an easy TW security fix is in the works so that this stream of “potential goodies” on my mind will be sooner-than-later worry-free.

Woohoo!

After a few times of this happening (me finding something cool that software allows, which has security-minded folk having an “oh poop” moment.) Hmm, maybe I should be thinking of a career as a white hat, kind of an Inspector Clouseau version …

#16

Hi Finn

#17

Charlie,

Whatever you wish but I feel I needed to clarify the innerwiki plugin can run on single file wikis and generate new single file wiki, like in an iframe., from where you can save it as a new single file wiki, if you wanted. Perhaps a good place to test.

Its purpose was for documentation snapshots which requires node, other applications of it do not need node.

Regards
Tones