New issue
Advanced search Search tips

Issue 813066 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

XSS auditor should have a "continue anyway" option

Reported by teo8...@gmail.com, Feb 16 2018

Issue description

UserAgent: 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:
 
Labels: Needs-Triage-M64
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET Needs-Feedback
teo8976@ Thanks for the issue.

Request you to provide a URL where this issue can be reproduced which will help in further triaging.

Thanks..

Comment 3 by teo8...@gmail.com, 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.
Project Member

Comment 4 by sheriffbot@chromium.org, Feb 19 2018

Labels: -Needs-Feedback
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
Components: Blink>SecurityFeature>XSSAuditor
Cc: tsepez@chromium.org
Labels: -Type-Bug Type-Feature
tsepez@: This seems WONTFIX to me, wdyt?
Labels: M-66 FoundIn-66
Status: Untriaged (was: Unconfirmed)
The issue seems to be a feature request. Hence marking it as untriaged for further inputs from dev team.

Thanks...!!

Comment 8 by tsepez@chromium.org, Feb 23 2018

Status: Fixed (was: Untriaged)
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.



Comment 9 by teo8...@gmail.com, 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.

Comment 10 by teo8...@gmail.com, Feb 23 2018

I can't believe I even had to explain this.
Labels: Restrict-AddIssueComment-EditIssue
Status: WontFix (was: Fixed)
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