Thanks for filing the issue.
Tested in chrome # 57.0.2987.110 and Canary #59.0.3047.0 on win 10.0 & 7 and Unable to access the provided URL(https://xenforo.com/bugs/chrome-xss-base/target-with.html?x=%3Ca+href%3D%22https%3A%2F%2Fxenforo.com%22%3E).Please find the screen cast for your reference.

@Reporter: Could you please let me know if i have missed anything and if possible, provide us with a valid URL and expected behaviour of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 703093.mp4 551 KB

	703093.mp4 551 KB View Download

Your screencast is essentially demonstrating the issue: the page is blocked by the XSS auditor unexpectedly, essentially by the query string having an href that matches the page's base tag. On that blocked page, view the page source and you'll see what should be displayed (and that the <base> tag is listed as an XSS vector).

The expected result is that the page displays rather than being blocked.

This demo is essentially the same link, except the target page does not have a <base> tag: https://xenforo.com/bugs/chrome-xss-base/target-without.html?x=%3Ca+href%3D%22https%3A%2F%2Fxenforo.com%22%3E

Both examples are linked from here: https://xenforo.com/bugs/chrome-xss-base/

Thank you for providing more feedback. Adding requester "rbasuvula@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

Able to reproduce on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome stable M57-57.0.2987.110.

Bisect Information:
=====================
Good build: 57.0.2931.0
Bad Build : 57.0.2933.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/7fa3a9ec199292a46257054e8c30b19e77fa75c7..46b2f19290555de613e09226348ae711db179f58

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2524013002

mkwst@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Since this issue got regressed on chrome M-57 adding RB-Stable, please feel free to edit or remove if this is not the case.

Thanks!

Mind taking a look, Tom?

Forgot to add RB-Stable in comment #5.

I don't see a way to avoid the issue. This is exactly what a base href injection would look like.   Note that in the past, we'd silently strip the base tag, so the page was likely broken either way. They may need to turn the auditor off. 

I'm going to reluctantly wontfix this for now.  

I have encountered a similar issue when editing a xhtml template containing various urls and scripts in our cms. Strangely, it only occurs after posting the edited template, not loading it. The POST is submitted and the data is processed by the server, but the page is blocked by "ERR_BLOCKED_BY_XSS_AUDITOR" afterwards, even though the content is the same is in the initial GET request.
I think this is a rather sensitive issue which should be taken seriously. Why is `<textarea>` content not ignored at all?

Note (maybe not relevant): Removing the <base...> tag from the template does not prevent the issue.

HTML editors and the like are one case we know of where the auditor is likely to get tripped up.  You'll want to add the headers to disable the auditor on these kinds of pages.

I am encountering this now in our Vbulletin site when editing or submitting replies.  I reproduced it on three machines thus far, all with the latest version of Chrome.  Is there any way to revert this to the way it was previously?

I just don't know what to do for a fix.

You can disable the xssaudito by sending an X-XSS-Protection: 0 header.

Thank you @tsepez@chromium.org.  I can just add this to my website header so no users would be affected?

Exactly.

Thank you very much, I will give this a try right away.  I am most grateful for your fast reply!

This is causing chaos with our users. Same domain, same origin, slightly different path, is blocked.
E.g. from
http://www.typepad.com/site/blogs/blogid/post/postid/edit 
user invokes preview, which does a new window.open at
http://www.typepad.com/site/blogs/blogid/compose/preview/post
and they get the gray screen of xss death.
Is that expected behavior? Do not see how this is an XSS security risk given same origin etc.
As you note, we can not add header to the window.open function.
If not a bug, any other suggestions for how we can deal with this? (aside from having the user invoke chrome with --disable-xss-auditor)
Thanks

I'm not sure what you mean by "Can not add header to window.open()".  The header would be supplied by your server when rendering your /compose/preview/post page.  Or are you somehow avoiding a round-trip via window.open() to a data url or a document.write into that window? 

Just after I pushed Save Changes, I'm all like wait, there's gotta be a way.
So, yep, down the rabbit hole there, seeing about adding the header.
This really flared up for our users, so, was a lot of noise coming in.
Still not sure how this is an XSS threat given all the same same.
But, there it is.
Thanks for come back.

Same problem here, trying to edit a post within a xenforo forum software and chrome detects it as a bad behaviour when on the previous versions all always worked without a single issue.
Attached, screenshot as a proof

Deleted: Schermata del 2017-11-24 13-06-30.png 34.7 KB

	Schermata del 2017-11-24 13-06-30.png 34.7 KB View Download

This happens both on
Chrome Version 59.0.3071.104 (official build) (64 bit) that on
Chromium Version 62.0.3202.89 (official build) (64 bit).