I agree, that would be a vulnerability.
But I think this is not the core of my wonder.
I wonder, why do Web developers have to
guess what the Browser thinks is JS and executes
it and what isn't?
Why can't they just ask the Web Browser to do that
for them?
That would be more secure because
all third-party libraries parse somewhat differently
than all the Web Browser they are used with.
On 4/6/19 12:51 PM, Craig Francis wrote:
While I quite like the simplicity of this idea, where it kind of
reminds me of the @inert attribute.
My main concern is how to bypass it, take the code:
<div noscripts="true"><?= $unsafe_user_name ?></div>
Where the attacker can set their username to
`X*</div>*<script>evil_code</script><div>`
---
Unfortunately, I think this is why we need to work with more
complicated/advanced solutions...
We need to sanitise all strings that are included in the HTML on the
server side - e.g. using templating systems; or passing the string
though something like HTML Purifier:
http://htmlpurifier.org/
Or, and you have to be careful here... escaping all HTML output though
functions like htmlentities() / htmlencode(), where this does not fix
`<a href=<?= htmlentities($unsafe_url)>` due to the url being able to
start with `javascript:`, or being able to take advantage of the
missing quotation marks on the attribute via ` onclick=evil_code`.
And when working with strings in JavaScript - you should use safe
methods like `element.textContent`, or pass them though something to
sanitise the HTML (both in removing the many ways JavaScript can be
included, but also just making sure the HTML is well formed):
https://github.com/google/closure-library/blob/master/closure/goog/html/sanitizer/htmlsanitizer.js
https://github.com/punkave/sanitize-html
Then you would ideally add a Content Security Policy to limit the
scripts on the page, just incase you miss something.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
And as an extra bonus, start playing with the (currently in
development) Trusted Types, to make sure you aren't using unsafe
things like element.innerHTML.
https://developers.google.com/web/updates/2019/02/trusted-types
Or for even more fun (pain), on your local development server, try
setting the header:
Content-Type: application/xhtml+xml; charset=UTF-8
Do not do this on live, as any bad formatting of your HTML will break
the page - but this ensures all of your attributes are quoted, and all
of your tags are perfectly nested (this includes `<br>` needing to be
`<br />`, the attribute `selected` needing to be
`selected="selected"`, etc).
Craig
On Fri, 5 Apr 2019 at 23:47, Yog Bii <joris.gutj...@gmail.com
<mailto:joris.gutj...@gmail.com>> wrote:
XSS prevention is a very important and costly part of a Websites
Security.
Because XSS is currently prevented by matching for JS in user input
and is than either blocked or masked by the Web Developer, each on his
own site,
XSS attacks find differences between the matching of the Web Developer
and the Browser, such that the Web Developer's matching doesn't
recognize JS as JS, but the Browser executes it.
This is a constant fight between the Web Developer and the XSS
attacker,
that costs many resources needed somewhere else instead.
And this fight favors larger business over small Web developers.
I think that this fight can be terminated by letting the
Web Developer not guess what the Browser may think to be JS
and instead tell him explicitly that somewhere shouldn't be any code.
The Browser then behaves in that region like
he would have JS disabled.
I would do that with a new attribute, called noscripts.
Inside an HTML element with noscripts = "true",
the Browser handle anything inside that element like
JS would be disabled globally.
An example HTML would look like this:
<!doctype html>
<html>
...
<div noscripts="true">
<script>
// No danger by unescaped <script> tags
</script>
<button onclick="nor by Event listeners">Click me</button>
...
</html>
If you know a way to do this without any differences between what the
Browser executes and what ever that mechanic lets pass, let me know
and let me know why it isn't thought in every HTML/JS Tutorial and
every Documentation about Web Development.
_______________________________________________
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
