XSS auditor should have a "continue anyway" option
Reported by
teo8...@gmail.com,
Feb 16 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Steps to reproduce the problem: 1. open a webpage containing a form that is susceptible to a XSS, or even better, to Chrome's idiotic XSS auditor false positives 2. submit something that will trigger the XSS auditor and block the page What is the expected behavior? Assuming it is a good idea to block the content (which it isn't), you should be presented the warning that indicates the content has been blocked AND an option to continue anyway at your own risk, similar to when you try to acces an insecure https website. What went wrong? The content is blocked and the expected error page is shown but there's no option to continue anyway if, for example, you know what you are doing and know there's no real threat. Did this work before? N/A Chrome version: 64.0.3282.140 Channel: n/a OS Version: Flash Version:
,
Feb 19 2018
teo8976@ Thanks for the issue. Request you to provide a URL where this issue can be reproduced which will help in further triaging. Thanks..
,
Feb 19 2018
I don't have any that I can share. Anyway, ANY url triggering the XSS auditor will do. I wonder what you even need that for.
,
Feb 19 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 21 2018
,
Feb 21 2018
tsepez@: This seems WONTFIX to me, wdyt?
,
Feb 23 2018
The issue seems to be a feature request. Hence marking it as untriaged for further inputs from dev team. Thanks...!!
,
Feb 23 2018
I went and looked to see what it would take to add a "--disable-xss-auditor" command line flag, and, as it turns out, someone had already added one (!!!). So starting chrome --disable-xss-auditor should have done what you've wanted all along, and eliminate the need for this specific feature. Give it a try and re-open if this doesn't meet your needs.
,
Feb 23 2018
NOPE that's an entirely different thing. Let's say I am a user that does NOT want to turn the feature off entirely (in order to stay safe), or that I don't even know how to run Chrome from a command line for that matter. I go to a page, submit some form and get the XSS bullshit -pardon- false positive error. Let's say I understand what the error message says and I know that there's nothing unsafe about what I'm doing, so I just need to ignore the warning and go on anyway. Having to close Chrome and restart it with a flag (and start over submitting whatever I submitted) is not an acceptable solution. It's an OBVIOUS feature that one rightfully expects EVERY time something is blocked for whatever reason, and even more when there's the possibility of false positives. For example, when the popup blocker blocks a popup, you have a way to unblock it and display it. When you try to access an https page that has an invalid https certificate, you can go to "Advanced" and then "continue at your own risk" or whatever it is called. And so on. Would you imagine having to restart chrome with a flag to disable the popup blocker or https certificate verification in those cases? That would be ridiculous, wouldn't it? So is it in the case of XSS blocking.
,
Feb 23 2018
I can't believe I even had to explain this.
,
Feb 23 2018
NO, putting security decisions in the hands of the user is one of the anti-patterns chrome avoids at all costs. If you can't live with the command line switch, then I'm afraid chrome simply isn't going to work the way *you* think it should Also, please note the chrome community guidelines as pointed out on your previous reports. Closing issue to further comments due to violations. A subsequent infraction may result in banning your account. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by krajshree@chromium.org
, Feb 18 2018