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?

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.

Deleted: chrome-error-1.jpg 39.2 KB

	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.  

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.

Deleted: Upload_Error.GIF 349 KB

	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?

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

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

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 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

Also experiencing this bug in Chrome 58 when trying to administer a legacy zope2 site 

http://www.zope.org/




 

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.

Issue 780116 has been merged into this issue.

 Issue 812255  has been merged into this issue.

 Issue 79014  has been merged into this issue.

I have had this issue reported to me by a user and was able to recreate the issue. Developer Tools screenshot attached. 

URL:https://go8.pcgeducation.com/easyiep.plx?op=alt_authenticated&CustomerName=ncwcpss&SessionID=51FB1234-6C9D-1014-A732-DC4146784B6C&FromAggregate=0

Please fix this issue. I will have other users running into this problem and it will cause significant disruption to users.

Deleted: EASI system Bug in Chrom 2.15.18.PNG 25.8 KB

	EASI system Bug in Chrom 2.15.18.PNG 25.8 KB View Download

rknox, the link you provided requires some sort of login ... what I'll need from you is a view-source of the page where the issue is happening along with the complete url (plus post body, if a post).

The reference URL in C40 doesn't seem reasonable as some sort of punctuation [<>'"] is required to engage the auditor in the first place.

Comments on this issue will be closed if they do not contribute to resolving any issue.

In all cases thus far, this feature is working as expected. If you believe you've found a false positive issue in the XSS Auditor, please provide the information requested in Comment #41 above.

> Is there a better way other than trial and error to determine 
> why exactly XSS Auditor is blocking the page? 

If you choose "View Page Source" on the page that triggers the XSS Auditor, Chrome will highlight the offending reflection in red, as shown in the attached screenshot.

If you'd like to learn more about this feature, see https://www.chromium.org/developers/design-documents/xss-auditor

Deleted: ViewSourceXSS.png 175 KB

	ViewSourceXSS.png 175 KB View Download

I get this error when embedding YouTube videos in a web form. The text posted is e.g. "<iframe width="560" height="315" src="https://www.youtube.com/embed/V9Gay1CZ8TM" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>"
If I don't embed this code, the error does not occur. The error has the following text: "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"
After getting the error message and reloading the browser, the form is actually updated with the embedded video, so the only problem is an extra button click, but if my collaborators don't think to reload the browser, they can't post the content,
My Chrome version is "Version 65.0.3325.146 (Official Build) (64-bit)".
When I view the page source I don't see any red highlighting, but I suspect the problem is in this snippet: "<tr>
<td valign='top'>Video&nbsp;<a href='#sternchen' title='Fields with a star (*) are only visible for club members after registration'>*</a></td>
<td valign='top'><iframe width="560" height="315" src="https://www.youtube.com/embed/V9Gay1CZ8TM" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></td>
</tr>"
I can recreate the error every time.

Neither of these are helping resolve the issue, and have been removed.  Please provide the information requested in Comment 41 and Comment 47 if you would like to help move the process forward.  Otherwise, the XSSAuditor can be disabled, as is pointed out in https://www.chromium.org/developers/design-documents/xss-auditor per the X-XSS-Protection header.

I am pretty sure I had replied to this claim:

> In all cases thus far, this feature is working as expected

which is bullshit.

@tsepez did you delete also comments of mine (or by any other people for that matter) in reply to that claim? Those DO help resolve the issue, so they shouldn't be deleted. I see a lot of deleted comments but I don't think I can even know which ones or how many were mine (unless I deleted them myself) because of how pathetic this bugtracker is, so unfortunately I cannot check whether I'm correct or if I'm getting confused with other related reports.

I didn't do the prior deletions, but I expect they were not useful.  If you have additional details we would like to see them.

I would also advise that you are getting close to violating the terms of service with regards to respectful communication, which could result in the account being blocked. 

To be clear, reports lacking a view-source of the page where the issue is happening plus the complete url (and post body, if a post), aren't going to be considered.

C58 adds no useful information to the bug.

Have a reproducible case: http://locutus.sorcerer.co.uk/crbug702542/

Open the above link and click Save (which posts the form back to the server), and it will trigger what I believe is a false positive XSS error.  The response from the server is exactly the same content it returned in the first place, nothing is changed, and it allowed it in the first place but not in response to a POST request.

If the [ Edit ] button is removed or changed to call a function to navigate, it works fine.  

http://locutus.sorcerer.co.uk/crbug702542/works.php

The problem is the combination of the Edit button

  <button onclick="location.href = 'index.php'">Edit</button>

and the template content

  <input onclick="location.href = '1_workorderslist.asp'" type="button" value="Cancel" />

Change either of those and the XSS BLOCKED error goes away.

Just to add to my comment 60, clicking the Edit button (which does a GET request not a POST) also triggers the XSS BLOCKED error.

To workaround, change

<button onclick="location.href = 'index.php'">Edit</button>

to

<script>
function go(where) {
  location.href = where;
}
</script>
<button onclick="go('index.php')">Edit</button>

Why are people being told to change HTTP headers?  That is done on the web server, and is therefore NOT helpful.  Users CAN NOT change the HTTP headers of web sites they are visiting!  Thousands of web sites across the web are receiving false positives because of Chrome's changes.

How do you expect users to change YouTube's HTTP headers?

How does one DISABLE the XSS-Auditor on the client?  (Not on the server, which users obviously do not have access to).  Specifically on the Android client.

C63 - Yes, contacting the site owner is required.
C62 - Thanks, that is indeed a false positive.  Will investigate getting a better match.

C67 - Word Press - Plugin settings page...

html php within a textarea is being edited for the plugins settings...
But I cannot save the content, as this issue prevents the updates being saved...

plugin: User Post Gallery
Layout Editor
Post Form File...

Nothing special, standard word press admin pages, but this causes the settings to be un editable?

This has been well over a year. Is there any plan to fix this, please?

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

This is still a problem. An example to reproduce the problem is described in  Bug #706038  which, for some reason, has been marked WontFix.

Yes it is till a bug.

go here http://locutus.sorcerer.co.uk/crbug702542/
click Save

Refer to comment 60 and comment 62 above for more details

Yes, definitely still a bug. We gave up and disabled the x-xss auditor for our EDI site. Just re-enabled the auditor and uploaded an EDI file and immediately got the false positive. Turned it back off. This has been a problem for a very long time now, ever since version 57 first came out.

I just encountered this bug in one of my own applications. Whether or not the block was warranted, what I consider a bug is that View Page Source does not highlight in red what it considered was the cause of the block, despite what the Chromium XSS Auditor documentation claims should happen. This can also be confirmed with the test page linked in Comment 70. Therefore, a bug of some sort exists -- either the block was unwarranted, or the cause was not indicated.