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> 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 > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
