XSS auditor blocks even code that is not going to be executed
Reported by
teo8...@gmail.com,
Feb 14 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Example URL: Steps to reproduce the problem: The typical use case is when using backend control panels of CMS'es, blogs, bulletin boards etc. For example, you are editing some HTML source code of a page/template through a form, you submit a chunk of HTML code containing <script>s, and you get back the same form with the HTML code within a textarea - even entity-encoded btw - and yet, it triggers the fucking XSS-protection error! Apparently, the test that is being done is something like this: If I submit text that contains a <script> tag or other "dangerous" stuff, and the "dangerous" part of the submitted string is found in the body of the response, this triggers the protection. This is INCREDIBLY stupid. At the very least, you should check that the potentially dangerous code, that is submitted and reflected in the response, is in a part of the DOM such that there's a possibility that it is actually executed. If the executable code is reflected into the contents of a textarea and encoded, for example, it's completely harmless and there's no reason whatsoever to block it. It appears that you are even going through the trouble to entity-decode it to match it against the submitted code! What is the expected behavior? If I submit a string, containing some <script> and <style> tags and other potentially executable code, and this is reflected back as harmless encoded plain-text that can't possibly be going to be executed by the browser (e.g. entity-encoded and presented within a <textarea>, but this is just an example), it shouldn't trigger any block What went wrong? it gets blocked. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Does this work in other browsers? Yes Chrome version: 64.0.3282.140 Channel: n/a OS Version: Flash Version:
,
Feb 14 2018
suspect there is more going on that what you have reported. XSSAuditor is called from the HTML parser, and is not invoked unless there is an actual script tag being generated by that parser, not a mere entity-encoded string found somewhere in the document. Can you give us an example post-body along with the complete view-source of the page in question? Note that in view-source mode XSSAuditor indicates where it thinks the reflection is occurring -- it may not be where you think it is.
,
Feb 14 2018
> Please provide the URL of a simple test page that reproduces this issue? I would have to build one from scratch, because the ones that I usually observe are private website control panels, which unfortunately I cannot share. I think I have provided enough information for you to try and build a test case the same way I would do. Unless you have a reason to think that there's more to it than I suggest (e.g. chrome does attempt to check for occurrences of the reflected strings that are actually executable, but gets it wrong in some particular cases)
,
Feb 14 2018
> Unless you have a reason to think that there's more to it than I suggest We do. As noted in #2, "XSSAuditor is called from the HTML parser, and is not invoked unless there is an actual script tag being generated by that parser"
,
Feb 14 2018
For example, given a URL containing: ...?x=<script>alert(0)</script> and a page reflecting as: <html> <textarea><script>alert(0)</script></textarea> </html> The auditor does not fire. But when the page is <html> <textarea><script>alert(0)</script></textarea> <script>alert(0)</script> </html> The auditor does indeed fire on the second script tag. So at least in the simple case it knows the difference. Please do take a look at the view-source for any blocks highlighted in red, since XSSAuditor does point out where it thinks the reflection is occuring. Maybe you can share that snippet with us if not the whole page.
,
Feb 14 2018
,
Feb 14 2018
I see.
You're right, I completely misdiagnosed the issue.
Here's what happens:
- I go to "my" vBulletin-based website's admin control panel
- I search templates for the string 'onclick="window.open('
- I am presented with a list of templates (without the actual content). I double click one of them, which triggers a new request (which again contains the string searched before, for no good reason at all, but this is vBulletin's fault)
- the response contains the snippet shown in the attached screenshot, which would be there anyway regardless of the submitted input, and it matches by mere chance.
So this is actually a duplicate of bug 702542.
To me it seems that this example shows that the very idea of the XSS auditor (checking whether the page contains executable code that matches a submitted string) is flawed.
If one submits a string that is likely to occur in the result page javascript (regardless of submitting it), you're always going to have a huge likelyhood of false positives.
,
Feb 14 2018
Thank you for providing more feedback. Adding requester "tsepez@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 14 2018
Thanks. We believe the case you describe is uncommon on the web at large, and that your best workaround is to set the X-XSS-PROTECTION: 0 header.
,
Feb 14 2018
> We believe the case you describe is uncommon on the web at large,
I believe you are delusional.
> and that your best workaround is to set the X-XSS-PROTECTION: 0 header
Yeah right. What about a workaround for the user?
Speaking of which, how comes there is not even an option to display the content anyway ("at your own risk" or something)?
,
Feb 14 2018
leo - You're entitled to your opinion, but please refer to https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md In the absence of hard statistical data to the contrary, we aren't planning on changing behaviour based on opinion.
,
Feb 14 2018
,
Feb 14 2018
Closed to external comments due to code of conduct violations. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by elawrence@chromium.org
, Feb 14 2018