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

Reply via email to