|False positives with ERR_BLOCKED_BY_XSS_AUDITOR|
|Reported by liamd...@gmail.com, Mar 17 2017||Back to list|
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:
Mar 17 2017,
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?
Mar 20 2017,
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.
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.
There is a related bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=706038
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.
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.
Thank you for providing more feedback. Adding requester "firstname.lastname@example.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
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?
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.
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 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".
Confirm this bug. It is triggered on submitting post on https://ubuntuforums.org
Also experiencing this bug in Chrome 58 when trying to administer a legacy zope2 site http://www.zope.org/
Hi, Any update on this bug? Thanks!
Hi, We have a customer who's experiencing this issue on a Windows 10 PC that has Chrome Browser v60 installed. Preview has never worked on this machine before But it is working fine from another Windows 7 PC that has Chrome Browser v58 without any problem. Any update on this bug? Thank you!
I confirm the workaround for triggering this bug by sending a "X-XSS-Protection: 0" response header fixes this here.
Issue 717707 has been merged into this issue.
|► Sign in to add a comment|