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
