disableScripts function for DOM Objects

joris

unread,

Apr 22, 2019, 10:35:24 AM4/22/19

to Firefox Security Mailing List

In a previous Mail I talked about
a noscript tag, that if set on a HTML Element would
direct the Browser not to execute any Scripts inside
that Element, thus behaving like JS would be disabled
globally. But this approach has the disadvantage of
being enabled and disabled entirely in HTML,
thus given unmasked user input the opportunity
of just closing the Element with the noscript tag
and going on to write XSS.
But I think to locally disable JS in a DOM / HTML
Element, that would then be filled with untrusted
user-input, could still prevent many XSS attacks.
I propose to instead of disabling JS in HTML for HTML,
to disable JS from JS for HTML.
For example:
A function, called disableScripts(), takes a DOM
Object as argument and tells the Browser to parse
that Object, like there wouldn't be any Scripts enabled:
<html>
        <div id="xss_output"
onload="disableScripts(document.getElementById('xs$
                <?php echo $untrusted_user_input ?>
        </div>
</html>

Now the $untrusted_user_input is formated,
but any JS would be ignored, whether by Events or <script> tags.
I have also added a .php File as an attachment, with the same code as above.
The advantage here would be that nobody can call a function that enables
scripts
again without already having JS executed.

Craig Francis

unread,

Apr 23, 2019, 7:39:20 AM4/23/19

to joris, Firefox Security Mailing List

Hi Joris,

I think this suffers from the same issue...

<div id="xss_output"
onload="disableScripts(document.getElementById('xss_output')">
<?php echo '*</div>*<script src...' ?>
</div>

I'd suggest you look at the Content-Security-Policy header, which can stop
inline JavaScript (dangerous), and limit where JavaScript files can be
loaded from.

I'd also suggest you never rely on the browser for XSS protection - all the
browser can really do is help apply limits when mistakes are made (e.g.
httpOnly cookies, fetch requests limited to certain locations, etc).

Craig

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

Anne van Kesteren

unread,

Apr 23, 2019, 8:57:40 AM4/23/19

to joris, Firefox Security Mailing List

Hey Joris,

This isn't really the place to discuss new web platform features.
https://discourse.wicg.io/ might be a better starting place.
https://whatwg.org/faq#adding-new-features might also help in getting
a handle on what it takes to add new features to the web platform.

Kind regards,

Anne

joris

unread,

Apr 24, 2019, 10:18:34 AM4/24/19

to Craig Francis, Firefox Security Mailing List

Yes.
But: this would still shrink the masking/sanitizing efforts,
because you could just use a tag that nobody else should use
inside user input like:
<html>
   <article id="xss_output"
onload="disableScripts(document.getElementById('xss_output')">
   </article>
   <script>
    let user_input; //Load user_input without masking
    let pattern = /</article>/;
    if(!pattern.test(user_input)) {
        document.getElementById('xss_output').innerHTML = user_input;
     } else {
        alert("XSS Attack detected");
     }
</script>
</html>
I know this seems a little bit ugly, but I hope the principle is clear:
Instead of matching for every possible insertion of JS, you just match
for the closing of the article tag and if there is such a tag, just
don't display the content.

> dev-se...@lists.mozilla.org <mailto:dev-se...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security
>

Craig Francis

unread,

Apr 24, 2019, 11:22:38 AM4/24/19

to joris, Firefox Security Mailing List

Hi Joris,

I think we should follow Anne's advice and discuss this elsewhere.

But what you're suggesting is starting to look a lot more like a browser
provided sanitiser function:

document.getElementById('xss_output').innerHTML = *sanitize*(*user_input*);

There is some discussion about it at:

https://github.com/WICG/purification

https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html

Where you could enforce the use of sanitisation though Trusted Types, as
discussed in this issue (the repo is about how Trusted Types will hopefully
work one day):

https://github.com/WICG/trusted-types/issues/43

e.g.

var myTrustedTypes = {
'createHTML': function (s) {
return *sanitize*(s);
}
};
if (window.TrustedTypes) {
myTrustedTypes = TrustedTypes.createPolicy('my', myTrustedTypes);
}
document.getElementById('xss_output').innerHTML = myTrustedTypes.createHTML(
*user_input*);

Craig

On Tue, 23 Apr 2019 at 13:57, Anne van Kesteren <ann...@annevk.nl> wrote:

> This isn't really the place to discuss new web platform features.
> https://discourse.wicg.io/ might be a better starting place.
> https://whatwg.org/faq#adding-new-features might also help in getting
> a handle on what it takes to add new features to the web platform.

>> https://lists.mozilla.org/listinfo/dev-security
>>
>
>

joris

unread,

Apr 24, 2019, 11:55:30 AM4/24/19

to Craig Francis, Firefox Security Mailing List

Yes,
in a way it would do the same job as a sanitizer,
but it is more than that.
I think that a simple sanitize function could
be wrong.
A function to disable JS would
be the last barrier for an XSS.
While a sanitize function
would just be another
barrier between XSS Code and
the Browsers JS Engine.
Where there could still be something
between sanitizing and rendering
on the web page if you just have
a Browser sanitize function.
But if the JS Engine isn't
even enabled, nobody can execute
XSS at the last point.

On 4/24/19 5:22 PM, Craig Francis wrote:
> Hi Joris,
>

>> <mailto:dev-se...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-security
>>
>

joris

unread,

Apr 25, 2019, 1:53:25 AM4/25/19

to Craig Francis, Firefox Security Mailing List

Hey Craig,
I did open this
discussion somewhere else:

https://discourse.wicg.io/t/xss-prevention-in-the-browser-by-the-browser/3518/4