XSS prevention in the Browser by the Browser

#23

No, I mean that the developer marks a certain area inside the page where the browser behaves as if JS was disabled globally, for the whole browser. And this kind of control for the web developer is not given by CSP.

#24

I think that relying on just CSP to protect from XSS is inherently wrong.

Because just a small change to the CSP would necessitate a test of the whole page to ensure that XSS is impossible on the page.

The cost of such a security review mounts.

I think if you can make security close to the place where it adds security makes the measure for this security more reliable.

And more modular. Because CSP is enforced on the whole page you need to make a sure your code works, if you imported that from anther project. But if you can directly see what protection mechanisms were used by that particular snippet and that protection doesn’t require you to change the overall protection of the site, you can import that snippet without worrying that it might be broken by your CSP or other global XSS protection.

If you say that CSP does all I propose, I don’t oppose that notion. But if you try to convince me that CSP is the best way to prevent XSS in all cases, you’ll be wasting your time.

Thus even if privileges are not helpful today, locally disabling JS is.

#25

“Locally disabling JS”

I want to explain a little bit more about how I imagine the “locally disabling JS” feature should work.

Use of this

I think that if the browser disables JS in those areas in a page that output user input, XSS wouldn’t be execute after it used a some parse differential in sanitizers and other XSS prevention tools.

How to use it (eventually)

I already made some proposals on the dev-security mailing list by Mozilla. But I’ll make a proposal here again: There should be a function called something like disableScripts. It would take a DOM Object inside the document and disable JS in that:

<div id="output_user_input" 
     onload="disableScripts(document.getElementById('output_user_input')">
<noscript>
{{ user_input | safe}}
</noscript>
</div>

As you can see I used Jinja Syntax to directly insert user input without sanitizing. If disableScripts() works that shouldn’t be a vulnerability here. But still it’d be possible to close the noscript and div tag, what would make it possible to inject XSS again. How would you solve this? Sanitizing I think. But I think that this sanitizing function would be much smaller:

function sanitize(html) {
    if (/</noscript>/.test(html)) {
        //XSS detected, definitively 
       return "XSS-Attack detected";
    } else {
       return html;
   }
}

The advantage here is both the simplicity and that it is without a doubt. Because you do not use a closing noscript tag if you write user input. By the way because JS is disabled I think that the content of a noscript tag should displayed.

I also think that this can be used very efficiently with TrustedTypes.

#26

What about a user extension? Something the user themselves have deemed allowed to operate on a page. Would this disabling then block those? If so, this is a no-go from the start. Users needs overrule site requests.

It seems to me you are opening a vector that can only work in some cases but not in others. CSP works in the best interest of sites and users. Because user scripts can still run regardless of the CSP rules.

Your suggested method of “definitively” detecting an XSS attack is not so definitive given the user-scripts case. Therefore, it isn’t as worthwhile as you lead yourself to believe, nor would it be as worthwhile to developers at large in this context.

#27

user-script case? What is that? I didn’t stumble about that yet.

#28

Do you think that it would be possible to implement this, if it is still possible for extensions to run JS inside those DOM-Elements, where Scripts were disabled by the site?

#29

I think you had better look again at the purifier system @craig.francis referenced when this was first posted. That type of system has a much better chance at being included in browsers over this blunt trauma approach.