[Zachery]

Freddies response

This has turned into quite a project. The issue manifests itself when script references that are used to build the page are used within the title or editor. An example, typical vb page contains:
<script type="text/javascript" src="clientscript/yui/yuiloader-dom-event/yuiloader-dom-event.js?v=418"></script>

Now say we only were to use this in a title or in the editor:
src="clientscript/yui/yuiloader-dom-event/yuiloader-dom-event.js?v=418"

When the page is previewed or submitted Chrome will determine this to be an XSS attack, disabling javascript on the resultant page.

The issue stems from Google's XSS deterrent code not allowing a JS reference submitted with a REQUEST to then be called on the resultant page.
this happens even though we display the code as encoded, so it couldn't be used as an attack vector
I believe these issues to be false positives and Chrome to be at fault.
This should be a rare issue as it does not seem to be just triggered by any JS references but only those that are pre-existing within the HTML that vB calls.

The work around methods, as I see them are:

(a) Send the X-XSS-Protection:0 header which disables the XSS protection altogether.

(b) Obfuscate the submitted data in some manner so that it does not match js references that may be included in the source of the page. The problem is that we have no general way to modify data submitted via title fields via javascript, or even other fields that may appear on some forms throughout vBulletin. For example, the various fields within the User's setting page. Submitting the JS reference as one's biography will generate the Chrome error upon submit. Getting past that hurdle, the data then has to be reverted back to its unaltered form before saving to the database. There is no central method to do this either with hundreds of potential locations.

(c) We don't have to modify data when submitted but could just modify the received data and leave it as is, such that src="whatever" becomes _src = "whatever", which would bypass the problem. Still hundreds of locations that would need to be modified.

(d) do nothing, caveat emptor

vB3 suffers from the same issue.
Easiest fix, send the X-XSS-Protection:0 header to disable Chrome's XSS protection.
I'm open to comments.

I will see about contacting the Chrome team to get their opinion on this.

Response from a Chromium dev

Originally Posted by Chromium dev

We don't have any current plans to resolve this kind of false positive. It seems likely a situation that won't occur very often. I'd expect most users of vBulletin not to copy and paste markup from vBulletin itself.
If you're particularly worried about this issue, you can disable the filter as discussed in Comment #3.