Bug 29278 – XSSAuditor bypasses from sla.ckers.org

• Component: WebCore Misc.
• Status: RESOLVED WORKSFORME

[Adam Barth]

The good folks at sla.ckers.org are pouring over the XSSAuditor in this thread:

http://sla.ckers.org/forum/read.php?13,31377

So far, they've found two bypasses:

http://eaea.sirdarckcat.net/xss.php?html_xss=<iframe+src="javascript:'1%25251';alert(document.domain)">
http://eaea.sirdarckcat.net/xss.php?html_xss=<img%20src=ä%20onerror=alert('ä')>

The first one is a nice double-encoding issue.  I think we're only decoding once.  I don't quite understand the second one yet.  Something tricky with unicode.

Feel free to create spin-off bugs for fixing each issue.  I just wanted a central place to write them down for now.

[Daniel Bates]

The second attack is blocked with r46250 with proposed patch 1 of bug #27895 (*).

(*)This is my working copy on one of my machines. I will look into doing a clean checkout to confirm.

(In reply to comment #0)
> The good folks at sla.ckers.org are pouring over the XSSAuditor in this thread:
> 
> http://sla.ckers.org/forum/read.php?13,31377
> 
> So far, they've found two bypasses:
> 
> http://eaea.sirdarckcat.net/xss.php?html_xss=<iframe+src="javascript:'1%25251';alert(document.domain)">
> http://eaea.sirdarckcat.net/xss.php?html_xss=<img%20src=ä%20onerror=alert('ä')>
> 
> The first one is a nice double-encoding issue.  I think we're only decoding
> once.  I don't quite understand the second one yet.  Something tricky with
> unicode.
> 
> Feel free to create spin-off bugs for fixing each issue.  I just wanted a
> central place to write them down for now.

[Mario Heiderich]

Reduced copy of the recent post with the UTF-7/ISO filter circumvention:

<copy>
Charset conversions are not handled right as it seems - and can be used to init the real payload. Will I get a cookie for this? ;)

<img%20src=ä%20onerror=alert('ä')> // alerts ä on a ISO-8859-1 encoded site

http://sla.ckers.org/forum/read.php?13,31377,31440#msg-31438
</copy>

[Mario Heiderich]

(In reply to comment #2)
> Reduced copy of the recent post with the UTF-7/ISO filter circumvention:
> 
> <copy>
> Charset conversions are not handled right as it seems - and can be used to init
> the real payload. Will I get a cookie for this? ;)
> 
> <img%20src=ä%20onerror=alert('ä')> // alerts ä on a ISO-8859-1 encoded site
> 
> http://sla.ckers.org/forum/read.php?13,31377,31440#msg-31438
> </copy>

Sry - UTF-8

[Daniel Bates]

Created attachment 39628 [details]
temp. workaround with test case for IFrame JavaScript URL issue

For the IFrame JavaScript URL example:

Notice the source code portion of the JavaScript URL is URL decoded on line 745 (*) of FrameLoader.cpp <http://trac.webkit.org/browser/trunk/WebCore/loader/FrameLoader.cpp#L745> before it is passed to FrameLoader::executeScript which eventually passes it to the XSSAuditor.

Consider the example URL: http://eaea.sirdarckcat.net/xss.php?html_xss=<iframe+src="javascript:'1%25251';alert(document.domain)"> which echos in the HTTP response the string <iframe src="javascript:'1%251';alert(document.domain)">. Looking at the source code portion of the JavaScript URL: '1%251';alert(document.domain) and applying (*), we see that |script| is set to the string "'1%1';alert(document.domain)".

The XSSAuditor compares this to the URL-decoded URL of the page <http://trac.webkit.org/browser/trunk/WebCore/page/XSSAuditor.cpp#L274>, which is: http://eaea.sirdarckcat.net/xss.php?html_xss=<iframe+src="javascript:'1%251';alert(document.domain)">.

Another issue, since the FrameLoader reuses the same pipeline for JavaScript URLs as JavaScript scripts, we are losing information on the origin of the script code (that is, was it extracted from a JavaScript URL or an inline JavaScript script).

The workaround calls the XSSAuditor::canEvaluateJavaScriptURL on the string source code portion of the JavaScript URL (i.e. url.string().substring(javascriptSchemeLength)) before it is decoded. So, XSSAuditor will be comparing "'1%251';alert(document.domain)" to http://eaea.sirdarckcat.net/xss.php?html_xss=<iframe+src="javascript:'1%251';alert(document.domain)">.

I am not happy with this workaround, because it calls the XSSAuditor twice (via XSSAuditor::canEvaluateJavaScriptURL and via FrameLoader::executeScript) and I have not fully vented it to my satisfaction.

[Adam Barth]

Here are some more examples:

http://eaea.sirdarckcat.net/xss.php?html_xss=%3Cimg+src=%220%22+onerror=%22/%80/;alert(document.domain)%22%3E

http://eaea.sirdarckcat.net/xss.php?html_xss=%3Cimg+src='%80'+onerror=%27alert(document.domain)%27

The poster thinks these might be dups of https://bugs.webkit.org/show_bug.cgi?id=29306.  In any case, we might as well add test cases for them.

[Mario Heiderich]

I am not sure if this ticket should be resurrected but there's a new bypass on Safari 5 I just stumbled upon: 

urlencoded:
%22%3E%3Cscript%20src=%0adata:%01;base64,YWxlcnQoMSkNCg==%20/%3E

canonical:
"><script src= data:;base64,YWxlcnQoMSkNCg== />

The problem seems to be that Safari 5 automatically deals with self-closing script tags - which for example Chrome doesn't. 

"XML self-closing tag syntax used on <script>.  The tag will be closed by WebKit, but not all browsers do this.  Change to <script></script> instead for best cross-browser compatibility."

I am not sure if this is a WebKit issue or a Safari only problem.

[Adam Barth]

Does this work with a nightly build?  We no longer support self-closing script tags.

[Mario Heiderich]

I just tested again - it bypasses the filter with a regular closing script tag too

%22%3E%3Cscript%20src=%0adata:%01;base64,YWxlcnQoMSkNCg==%20%3E%3C/script%3E

"><script src=
data:;base64,YWxlcnQoMSkNCg== ></script>

The script execution is being blocked as soon as the %0A before data: is being left away. Maybe that helps to locate the filter bug.

[Adam Barth]

*** Bug 43751 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

<rdar://problem/8281296>

[Adam Barth]

We should close this bug and replace it with specific bugs about the remaining false negatives.

[Thomas Sepez]

I'm no longer reproducing any of these with chrome 14 or later.  Cases like this are covered by the new bugs:
https://bugs.webkit.org/show_bug.cgi?id=67134
https://bugs.webkit.org/show_bug.cgi?id=67134