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