Miscellaneous Hacks - Disable Webkit Browser XSS Protection

The Chrome Xss prevention feature can trigger false positives on some vBulletin boards.

This occurs when people make posts that contain references to JS files that vbulletin uses.

Chrome detects that the content of the post contains the same scripts that the resulting page intends to run and disallows the load (this occurs even if the post escapes the scripts properly so they cannot be interpreted as code).

Chrome are aware of the problem, but do not intend to provide a fix. The only workaround is to disable the Xss prevention feature in Chrome, which can be done via a HTTP header.

Since the actual occurrence of this problem appears to be quite limited, this is considered to be too drastic of an action for general use.

We have therefore decided to make this small product available that causes vBulletin to emit the header (for admins who are affected).

Simply download an install as you would for any product.

While released for the 4.x series, this should also work on vB 3.6, 3.7 & 3.8.

For reference see ;

http://tracker.vbulletin.com/browse/VBIV-13539
http://tracker.vbulletin.com/browse/VBIV-13499

[OldSchoolDSL]

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.[1] Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

http://en.wikipedia.org/wiki/Cross-site_scripting


So adding this could in theory, make your site less secure?!

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

[Alfa1]

The response from the chromium dev seems utter nonsense. Offcourse vbulletin users copy content from vbulletin. Its called quoting. The guy must live under a rock.

[zascok]

wow. wasn't aware of that. Thanks