Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 702542 False positives with ERR_BLOCKED_BY_XSS_AUDITOR
Starred by 16 users Reported by liamd...@gmail.com, Mar 17 Back to list
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1
Hotlist-1


Sign in to add a comment
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36

Steps to reproduce the problem:
1. Submit a post request with a Twitter embed
2. See the error

What is the expected behavior?
To not think a twitter embed is an XSS attack, like usual.

What went wrong?
It broke

Did this work before? Yes 55

Chrome version: 57.0.2987.98  Channel: n/a
OS Version: Antergos Arch
Flash Version:
 
Cc: elawre...@chromium.org
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Thanks for the report!

Can you please help improve this report by including URLs on which you are able to reproduce this problem, and logs from the Console tab from the Chrome developer tools?
Labels: Needs-Feedback
This is happening to my VBulletin forums site at www.screamandfly.com.
This has begun happening when submitting posts, or editing posts. 

It began a few days ago after the latest installation of Chrome.
chrome-error-1.jpg
39.2 KB View Download
I will add details to the above:

As an admin, the issue occurs 100% of the time if I click "edit" and then "save" on any article on the home page at http://www.screamandfly.com/content.php.  If required, I can provide credentials to duplicate.  


Comment 6 Deleted
Comment 7 Deleted
Our cloud-based EDI service has a few thousand ad-agency customers and we've just started having a rush of complaints for a very similar issue. We have the agencies upload their EDI text files to our translation server and we encourage them to use the Chrome Browser. In the last couple of weeks they are all starting to get the "Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards)." message. The file transfer goes through, but the users don't realize the transfer is happening anyway and call in thinking they've been blocked by Chrome. Because the command line workaround to suppress this feature is too complicated for our non-computer-savvy user base, we're being forced to have them use another browser. We'd love to stop doing this and continue directing them to use Chrome, but this bug makes that impossible.

Upload_Error.GIF
349 KB View Download
We are getting this also when trying to modify reports in our Oracle based CRM system. It is cloud based also and I have no idea what OS they are running. I am surprised this bug is classified "unconfirmed." I am running the beta version of 58 and therefore do not have the problem. My users do not have that luxury as they are running on VDIs that are all using V57 and updates are synchronized. I do not know when you plan to release V58, but hopefully soon.
The bug is "Unconfirmed" insofar as the reproduction cases listed so far are all entirely different (and the root causes are likely different) and no workable reproduction steps have been provided to Google thus far.

A site can opt-out of XSS Auditor scanning by sending an "X-XSS-Protection: 0" response header.
We can reproduce the problem 100% of the time.
 ljfabiano3@: Are you able to provide step-by-step instructions (URLs, credentials) that would allow us to see what you're seeing?
Absolutely.

Warmest regards,
Joe Fabiano
AdCore Local, LLC
678.689.0146
*Read our latest newsletter:* http://news.adcorelocal.com
I am also able to reproduce this error 100% of the time by going into edit mode for an article and clicking 'save'. This is in vBulletin 4.

I began receiving many emails from users asking if out site was 'hacked' or if we were trying to install malware on their computers. To the non-computer savvy user, that error message could look pretty frightening. 

This began suddenly with the latest version of Chrome. Our online magazine is quite large, with over 80,000 registered users and many more non-registered readers. We've had to put up messages recommending the use of Firefox or... bite my tongue... Internet Explorer. to mitigate the issue. 

Last night I added the 'protection "0"' header to the site which seems to have remedied the issue for now, but I'm also seeing this problem on other sites I visit. Right now I installed Firefox and am using that.  I hope Chrome gets fixed, since that's my preferred browser, and the browser we have always officially recommended to our readers.
Here's your 100% reproduction case in simple form: https://www.gamingonlinux.com/test.php

Just hit the button.

Full code of the example: https://pastebin.com/kTAN3qbB
Project Member Comment 16 by sheriffbot@chromium.org, Apr 5
Cc: ranjitkan@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "ranjitkan@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
Cc: tsepez@chromium.org
Components: -Blink>SecurityFeature Blink>SecurityFeature>XSSAuditor
The reproduction case in comment 15 is POSTing a `<script>` tag that's reflected in the landing page. That's more or less exactly what the XSS auditor is looking for. It sounds like the case in comment 8 is similar.

If this flow is essential to your application, and you're confident that you're escaping user generate data correctly, then configuring your server to send `X-XSS-Protection: 0` along with the response from the POST endpoint is the best solution.

Are there cases where Chrome is giving a similar error message in the absence of a POSTed `<script>` or `<style>` element?
Labels: OS-Android OS-Chrome OS-Mac OS-Windows
You shouldn't need to completely turn off a feature just because Chrome picks up "script", that's far too broad and breaks far too many things.
 Issue 709139  has been merged into this issue.
 Issue 710862  has been merged into this issue.
Owner: mkwst@chromium.org
Status: Assigned
I have the same problem which seems to be due to having a you tube link on my web page.
If I try to update the page with Chrome then I get this XSS.Auditor message.

youtube is a Google product!!

Here is the page url
https://www.simmar.ch/catalog/index.php?main_page=product_info&cPath=81_73&products_id=2377&zenid=92e6d366c7b91104bf1e927c0ce2fe34
Is there a better way other than trial and error to determine why exactly XSS Auditor is blocking the page?  Wouldn't it be orders-of-magnitude better for web developers to modify the offending html/javascript code than the disable XSS Auditor via server headers?  The recommendation to disable XSS auditor seems to be in direct contradiction to the reason XSS Auditor was changed to block by default as discussed in "motivation" section here: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/aZsNygF84JM/86EbD_q0CAAJ .  I would expect some kind of information to show up in the javascript console or in the Security tab of Chrome's Dev Tools, and it's even discussed in the forum above that there ARE console errors and therefore we have "effectively already gone through a 'deprecation period' where we've [been] given notice of the problem".  I am not seeing any kind of message in either the console or the security tab.

I was hoping that the issue would be cleared in Chrome ver. 58 but I just got 58 today and it's still there.  Unfortunately, I can't make the page where I'm seeing the issue public, and since I don't know what's causing the issue it would be hard to recreate a test page that I could make public.

As for the particular page where I'm seeing the issue, the page doesn't use iframes and the POST is not sending <script> or <style> tags in the POST'ed form data. It looks like the data is successfully POST'ed to the server, but the result page is blocked.

Would XSS auditor block the page if the page is POST'ing an <a> tag that has an onclick set?  For example, if this(parsed request body data) were part of the POST'ed form data: 

H_FIELD_LINK:<a href="xxx0000$.field_link?fn_item_id=00000" target="popup" onclick="window.open('xxx0000$.field_link?fn_item_id=00000','popup_35','scrollbars=1,width=1000,height=800'); return false;">LV_ERROR</a>

Thanks. 
Is it an issue anytime there is a <script> tag inside the <form> element?  I was looking in the POST request body data instead of just the html source and didn't see any <script> tags.  I suppose I don't understand what was meant by "POSTing a `<script>` tag".
Update - the problem was the <a> tag which had an onclick set and was being POST'ed as form data.  This was being done with the use of a hidden input; the the <a> tag's html was escaped and put inside the value of the hidden input.  After removing the onclick and instead setting an event handler in javascript elsewhere the problem was fixed.  No disabling of XSS Auditor needed! 

I would still really like to some kind of console message to help point developers in the right direction... 
Confirm this bug. It is triggered on submitting post on https://ubuntuforums.org
Comment 28 by monsterm...@gmail.com, May 23 (4 days ago)
Also experiencing this bug in Chrome 58 when trying to administer a legacy zope2 site 

http://www.zope.org/




 
Sign in to add a comment