Disallow `javascript:` urls

[Jermolene]

The use of JavaScript pseudo-URLs makes it possible to include executable JavaScript in wiki text. For example:

<a href="javascript:alert('boo')">Click</a>

This is undesirable because it means that any wiki text tiddler could contain malicious JavaScript. TiddlyWiki5 requires all executable JavaScript to be in tiddler modules that can easily be filtered during imports/upgrades.

These javascript: URLs should be filtered so that they are not executed.

---

Update:

Referring to https://html5sec.org shows there are several situations where javascript: URIs can be used:

<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>

<math href="javascript:alert(1)">CLICKME</math>  <math> <!-- up to FF 13 --> <maction actiontype="statusline#http://google.com" xlink:href="javascript:alert(2)">CLICKME</maction>  <!-- FF 14+ --> <maction actiontype="statusline" xlink:href="javascript:alert(3)">CLICKME<mtext>http://http://google.com</mtext></maction> </math>

<embed src="javascript:alert(1)"></embed>
<img src="javascript:alert(2)">
<image src="javascript:alert(2)">
<script src="javascript:alert(3)"></script>

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">  <animation xlink:href="javascript:alert(1)"/> <animation xlink:href="data:text/xml,%3Csvg xmlns='http://www.w3.org/2000/svg' onload='alert(1)'%3E%3C/svg%3E"/>  <image xlink:href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' onload='alert(1)'%3E%3C/svg%3E"/>  <foreignObject xlink:href="javascript:alert(1)"/> <foreignObject xlink:href="data:text/xml,%3Cscript xmlns='http://www.w3.org/1999/xhtml'%3Ealert(1)%3C/script%3E"/>  </svg>

<svg> <a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="?"> <circle r="400"></circle> <animate attributeName="xlink:href" begin="0" from="javascript:alert(1)" to="&" /> </a>

[twMat]

These javascript: URLs should be filtered

What does this actually mean? Simply not import that tiddler? Filter out the javascript segment?

[Jermolene]

No, it wouldn't affect importing. It just means that clicking on the link shouldn't execute the JavaScript.

[twMat]

OK, I hope to remember to bring this up in a hangout because there is much that is not clear from this. I'll mention some here but no need to aswer as it is more of a discussion probably: How could this be worse than importing buttons that execute code? Or should that aslo be stopped? And how would the user be informed about why the feature doesn't work? Maybe he should be alterted during import and informed how to work around it should he really want it to work. And aren't we loosing out on protenitally good stuff - I recall in TWC when we suddenly couldn't start up local software from within the browser which was a anti-improvement (disprovement) for me. Etc, etc. Point is there seem to be undesirable consequences also from blocking this. But, again, it's for a future hangout.

[tobibeer]

In a way, Mat is rather right. If some code wants harm done, it wants harm done. Whether we undergo a save/relaoad cycle or run that immediately, what's the difference?

[Jermolene]

We already block JavaScript within wiki text: both the <script> tag and any event attributes like onclick are suppressed. The fact that JavaScript URIs work right now is an oversight.

The reason is really simple. We want to be able to build multi-user systems with TiddlyWiki: both TiddlyWeb-style centralised systems, and federated systems. In either case, it is not acceptable for viewing one of your tiddlers to run the risk of executing your JavaScript.

So we go to some trouble to make sure that executable JavaScript can only be included within tiddler modules, which allows us to sandbox or filter its execution.

No serious multiuser wiki allows for embedded JavaScript within wikitext for this same reason.

In a way mat is rather right. If some code wants harm done, it wants harm done. Whether we undergo a save/relaoad cycle or run that immediately, what's the difference?

This is nothing to do with the save/reload cycle. This is to do with being able to identify and therefore filter/sandbox executable JavaScript.

[tobibeer]

This is nothing to do with the save/reload cycle. This is to do with being able to identify and therefore filter/sandbox executable JavaScript.

Yes. So the question is, is there any concept for sandboxing modules (yet)? E.g. "test first" ...and, if not happy, abort?

[Jermolene]

So the question is, is there any concept for sandboxing modules (yet)?

Well, sandboxing isn't really possible in the browser so the focus is more on making sure that we can reliably filter executable JavaScript.

E.g. "test first" ...and, if not happy, abort?

You're imagining that a user would be able to "use" a tiddler to verify that it is not malicious. I don't think that's true for most users.

There's nothing to stop a plugin being written that does allow the execution of inline JavaScript, it's just not something that could ever go into the core.

[tobibeer]

You're imagining that a user would be able to "use" a tiddler to verify that it is not malicious. I don't think that's true for most users.

That is true, but the question remains if there is a concept for handling / disabling malicious modules that kick-in after reloading the wiki... and a user realising that this is the case. Probably safe-mode + delete.

TWc does some sandboxed execution on startup to list failing plugins...

[Jermolene]

the question remains if there is a concept for handling / disabling malicious modules that kick-in after reloading the wiki... and a user realising that this is the case

No, that would be useless I think. It's game over if a malicious module has had a chance to do its stuff. This is about filtering out executable modules so that they don't get executed at all. There's no point in trying to mitigate the effects of executing a module; it's too late.

[tobibeer]

ok, thanks for clarifying

[tobibeer]

I believe there is a certain demand for something equivalent to TiddlySpace and...

config.evaluateMacroParameters = "full";

...allowing users and authors to explicitly enable javascript urls in their wikis, even script tags ...via a different config tiddler.

[pmario]

@Jermolene ... This is a long-standing one. IMO the attribute parser should catch that one. Just a thought

[Jermolene]

@Jermolene ... This is a long-standing one. IMO the attribute parser should catch that one. Just a thought

The attribute parser doesn't know which attribute values contain URLs, and thus must be blocked from the "javascript:" prefix. The fix will need to know which attributes of which widgets contain URLs that need checking. I think the checking needs to be done at the widget level. For example, the "element" widget that handles HTML elements needs updating to check for attribute values where the name starts with on.