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 <[email protected]> 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.
On Wed, 24 Apr 2019 at 15:18, joris <[email protected]> wrote:
> 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.
>
> On 4/23/19 1:38 PM, Craig Francis wrote:
>
> 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
>
>
>
> On Mon, 22 Apr 2019 at 15:35, joris <[email protected]> wrote:
>
>> 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.
>> _______________________________________________
>> dev-security mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-security
>>
>
>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
