New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner: ----
Closed: Apr 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
Security: Google Chrome Anti-XSS bypass through HTTP Parameter Pollution
Reported by, Mar 18 2012 Back to list

Google Chrome Anti-XSS bypass through HTTP Parameter Pollution


HTTP Parameter Pollution (HPP) describes the behavior of different servers
when accepting Query, Path or Post parameters, specifically when a user
sends a request that has two or more instances of the same parameter.

For example, when considering the following URL:

Most web servers will either use the First or last instance of the given
A few servers however, create either a collection or a concatenated string
the include all of the instances for any given parameter.

The IIS server in particular concatenates all of the values into one large
string, using the Comma (',') char as a delimiter.

For example, when browsing to the URL:

The returned value will be 123,456

Vulnerability details

Using HPP, an attacker can bypass the Chrome Anti-XSS filtering by
splitting the XSS payload into two or more parts.

For example, the Following URL:
http://localhost/Default.aspx?a=<script id=x x='1&a= 1'">alert(2)</script>

Will result in the following Response snippet (Considering there is no
server side filtering)
<script id=x x='1, 1'">alert(2)</script>

Google Chrome fails to detect the response as malicious and therefore does
not block the script from running.


Most XSS issues that are found on servers running IIS can be escalated
using this technique to allow exploitation on Google Chrome browsers.

Chrome Version: 17.0.963.79 m
Operating System: windows 7

Comment 1 by, Mar 18 2012
Status: WontFix
Thanks for your report, but the XSS Auditor is not designed to detect injection split across multiple parameters.

@tsepez, @abarth - Do we have the XSS Auditor behavior documented somewhere yet, so we can easily point people to it?
Comment 2 Deleted
Comment 3 by, Mar 18 2012
Thank you for your response. However I would like to point that the method described here is not splitting the payload across multiple parameters, it is splitting the parameter itself into two instances.
Comment 4 by, Mar 18 2012
Labels: -Pri-0 -Area-Undefined Pri-2 Area-WebKit
Status: Available
Yeah, we might want to figure out of there's a way we can handle this case.  There's already a WebKit bug filed on this topic with some more discussion:
Comment 5 by, Mar 18 2012
Labels: SecSeverity-None
Comment 6 by, Mar 18 2012
I don't have permissions to view the link you mentioned.
Regarding a way to handle this case I would suggest applying the sameAuditor logic on the merging of the two instances while considering the different concatenation-delimiters (" , " in our case)
Comment 7 by, Apr 17 2012

Its been a while now and I was wondering if there are any updates regarding this issue. 

Adi Cohen
Comment 8 by, Apr 17 2012
Status: Fixed
It looks like @tsepez landed a WebKit change to catch this case about two weeks ago. So, you should expect to see it in Chrome 20 (around three months).
Comment 9 by, Apr 17 2012
That's great to hear.
By the way, is this bug eligible to the bug bounty program?

No, XSS auditor bypasses don't constitute Chrome security vulnerabilities (which is why this bug is flagged SecSeverity-None). You can find our severity guidelines here:

To clarify a bit more, the XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can't catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.
I understand completely and it seems like the right approach for this component.
In any case, I'm glad this issue has been fixed :)
Project Member Comment 12 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 13 by, Mar 10 2013
Labels: -Type-Security -Area-WebKit -SecSeverity-None Cr-Content Security-Severity-None Type-Bug-Security
Project Member Comment 14 by, Mar 13 2013
Labels: Restrict-View-EditIssue
Labels: -Restrict-View-EditIssue
Labels: -Restrict-View-SecurityTeam
Project Member Comment 17 by, Mar 21 2013
Labels: -Security-Severity-None Security_Severity-None
Project Member Comment 18 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Labels: -Type-Bug-Security Type-Bug
Bulk unrestriction of Severity-none bugs.

Sign in to add a comment