Register Members List Search Today's Posts Mark Forums Read

Mod Options
Disable Webkit Browser XSS Protection Details »
Disable Webkit Browser XSS Protection
Mod Version: 1.00, by Internet Brands (Member) Internet Brands is offline
Developer Last Online: Mar 2012 I like it Show Printable Version Email this Page

vB Version: 4.x.x Rating: (4 votes - 4.75 average) Installs: 21
Released: 30 Dec 2011 Last Update: Never Downloads: 75
Not Supported Uses Plugins Translations  

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 ;

Download Now

Only licensed members can download files, Click Here for more information.

Show Your Support

  • To receive notifications regarding updates -> Click to Mark as Installed.
  • This modification may not be copied, reproduced or published elsewhere without author's permission.
Old 31 Dec 2011, 18:04
OldSchoolDSL OldSchoolDSL is offline
Join Date: Oct 2010
Real name: Adam H.
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.

So adding this could in theory, make your site less secure?!
Reply With Quote
Old 31 Dec 2011, 19:54
Zachery's Avatar
Zachery Zachery is offline
Join Date: Jul 2002
Real name: Zachery Woods
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:

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.
Looking for ImpEx?
Reply With Quote
Old 31 Dec 2011, 22:40
Alfa1's Avatar
Alfa1 Alfa1 is offline
Join Date: Dec 2005
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.
Reply With Quote
Old 05 Aug 2012, 10:40
zascok zascok is offline
Join Date: Jul 2010
wow. wasn't aware of that. Thanks
Reply With Quote

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Mod Options

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

New To Site? Need Help?

All times are GMT. The time now is 13:04.

Layout Options | Width: Wide Color: