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,
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
<mailto: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.
On Wed, 24 Apr 2019 at 15:18, joris <joris.gutj...@gmail.com
<mailto:joris.gutj...@gmail.com>> 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 <joris.gutj...@gmail.com
<mailto:joris.gutj...@gmail.com>> 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
dev-security@lists.mozilla.org
<mailto:dev-security@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
