New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 683798 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Regression



Sign in to add a comment

ERR_BLOCKED_BY_XSS_AUDITOR when using crbug.com with a query including ">"?

Project Member Reported by falken@chromium.org, Jan 23 2017

Issue description

Chrome Version: 57.0.2986.0 (Official Build) dev (64-bit)
OS: Linux

This is an apparent regression. The bug does not happen on Chrome 55 Stable.

What steps will reproduce the problem?
(1) Go to https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3Ablink%3Eserviceworker%2CBlink%3EWorkers++NextAction%3Ctoday-1+&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids
(2)
(3)

What is the expected result?

See the bug listing.

What happens instead?

Get the error:
This page isn’t working

Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards).
Try visiting the site's homepage.
ERR_BLOCKED_BY_XSS_AUDITOR

If I remove the NextAction part of the query, it works.

 

Comment 1 by falken@chromium.org, Jan 24 2017

You can also see the bug by typing NextAction<today-1 in the crbug.com query box and clicking Search.
I was able to repro the issue in the latest Canary 58.0.2991.0 on Mac OS. It seems to be a request failure after the response is received. I captured the net logs dump, and looking at the the original request, we seemed to have no problem. However, those URLRequests to bugs.chromium.org/static/js/... are aborted. 
net-internals-log (5).json
252 KB View Download
Cc: mkwst@chromium.org
Components: Blink>HTML>Parser
+mkwst who has been making changes to XSS auditor, afair. Most likely not a networking issue.

Comment 4 by mkwst@chromium.org, Jan 25 2017

Owner: tsepez@chromium.org
Looks like a false-positive due to some strange markup that monorail generates (I think the unquoted empty attribute in `<form id='bulkremoveissues' method="POST" action=>` is confusing the Auditor).

Filed https://bugs.chromium.org/p/monorail/issues/detail?id=2142 against Monorail, as that markup seems broken, but we should probably tune the auditor as well. Tom, would you mind taking a look?
Components: -Internals>Network
(Removing the network label since this is originating from Blink.)

Comment 6 by rbyers@chromium.org, Jan 26 2017

Labels: -Pri-3 ReleaseBlock-Stable Pri-1
I just hit this too (and then was frustrated that my queries attempting to find bugs modified recently mentioning ERR_BLOCKED_BY_XSS_AUDITOR weren't working).  This is a recent regression (Chrome 55 seems fine), right?  Seems potentially urgent - marking P1 release blocking proactively.

Comment 7 by rbyers@chromium.org, Jan 26 2017

Labels: Needs-Bisect
Let's get a bisect to see what CL broke this.

For the record here's one URL that triggers this error in Chrome 57 but works in Chrome 55:
https://bugs.chromium.org/p/chromium/issues/list?can=1&q=touch-action+cc%3Arbyers+Status%3AWontFix+closed>today-60
I'm not sure if BLOCKED_BY_XSS_AUDITOR shows up in net error codes (which are only logged if the request does not complete).

It would be a good idea to ensure xss monitor has metrics so we can properly detect significance of issues like this.

Comment 9 Deleted

Labels: -Pri-0 Pri-1
I was ready to up the priority but I suppose I can do triage on a stable release.

For the record, the problem is not the ">", it's the length of the string combined with certain characters.

For example, this works
Component:Blink>Paint,Blink>Paint>Invalidation status=Unconfirmed,Untriaged

but this does not

Component:Blink>Paint,Blink>Paint>Invalidation status=Unconfirmed,Untriaged -has:NextACtion
To be precise, it's not just the ">", it's the ">" combined with the length or something else.
I deployed a new version of Monorail that fixes the <form action=> markup.  The original link in this issue description now works on Chrome 58.0.2993.0 canary 64-bit on mac.
First off, you need one of [><"'] in the URL or the auditor doesn't even run.
 
From the example in the original description, we may matching
|action=| in the page against |NextAction<Today|, which should have failed since we're supposed to include the equals sign and the value (in this case empty).




Status: Started (was: Untriaged)
For unquoted attributes at the end of a tag, we've been silently losing the equals sign for comparison, matching the name only, and then re-writing this as name=, which changes nothing until blocking was enabled by default.

CL at https://codereview.chromium.org/2663433002/
Labels: -Needs-Bisect -ReleaseBlock-Stable Needs-Feedback
Its working fine now on Ubuntu 14.04,Mac 10.12.2 and Win 10 using 57.0.2987.8,55.0.2883.87/95 and canary 58.0.2993.0.

Removed the Needs-Bisect and RealeaseBloack-stable labels for now, please ad again if its reproducible again.
Status: Fixed (was: Started)

Sign in to add a comment