Bug 79154 – [chromium] XSS Auditor bypass via javascript url and control characters

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Thomas Sepez]

Reported by masatokinugawa, Today (10 hours ago)
VULNERABILITY DETAILS
The vector is:

?xss=1&body=%3Ca%20href=%22ja%09vascript:alert(1)%22%3EClick%20here%3C/a%3E

Safari is OK.

Also Reported by kuzzcc, Yesterday (32 hours ago)
Chrome 19.0.1041.0 dev-m window xp sp3

?q=%3Ca%20href=%22%26%231;javascript:alert(0)%22%3Etest%3C/a%3E
data:text/html,<a href="&#1;javascript:alert(0)">test</a>

[Thomas Sepez]

Created attachment 128061 [details]
Patch.

[Adam Barth]

Comment on attachment 128061 [details]
Patch.

This isn't the right approach...  There should be a function already that does this work called something like protocolIs or protocolIsJavaScript...

[Adam Barth]

Take a look at allowSettingJavaScriptURL in JSHTMLFrameElementCustom.cpp, for example.

[Adam Barth]

allowSettingSrcToJavaScriptUrl

[Thomas Sepez]

allowSettingFrameSrcToJavascriptUrl() does the check:

    if (protocolIsJavaScript(stripLeadingAndTrailingHTMLSpaces(value))) { ...

If I'm reading this right, stripLeadingAndTrailingHTMLSpaces() [HTMLParserIdioms.cpp] doesn't remove control-characters or internal HTML spaces.  protocolIsJavaScript()  [KURL.cpp] uses protocolIs() which asserts on c <= 0x20 in DEBUG builds but nothing otherwise.  So it looks like this check is hosed in the same was as XSSauditor if the (specific to chromium, right?) code allows &#1; and the like --  Unless there is a higher-level check.

Flipping to component security while I cobble together an example see if there's actually a  hole here.

[Thomas Sepez]

Ah.  KURL vs. KURLgoogle again.   KURLgoogle's protocolIs() will handle the ctrl characters, so no UXSS hole on setting frame.location.    Good.  

So we can use protocolIsJavascript(), but test will need to be chromium-only.

[Thomas Sepez]

Created attachment 128349 [details]
Patch.

Patch using Adam's suggested function.  Also, the test now uses an <a href=""> rather than an <iframe src=""> since iframe src currently isn't exploitable.  It flunks an origin test on chromium -- which is why this needs to be href in an a tag.  Still waiting full testing completion.

[WebKit Review Bot]

Comment on attachment 128349 [details]
Patch.

Clearing flags on attachment: 128349

Committed r108653: <http://trac.webkit.org/changeset/108653>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.