Bug 29278 - XSSAuditor bypasses from sla.ckers.org
: XSSAuditor bypasses from sla.ckers.org
Status: RESOLVED WORKSFORME
: WebKit
WebCore Misc.
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://sla.ckers.org/forum/read.php?1...
: InRadar, XSSAuditor
: 29306 29511 29523
: 66579
  Show dependency treegraph
 
Reported: 2009-09-15 13:33 PST by
Modified: 2011-08-31 13:35 PST (History)


Attachments
temp. workaround with test case for IFrame JavaScript URL issue (2.02 KB, patch)
2009-09-15 18:21 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-09-15 13:33:02 PST
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.
------- Comment #1 From 2009-09-15 15:06:11 PST -------
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.
------- Comment #2 From 2009-09-15 16:25:04 PST -------
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>
------- Comment #3 From 2009-09-15 16:32:09 PST -------
(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
------- Comment #4 From 2009-09-15 18:21:02 PST -------
Created an attachment (id=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.
------- Comment #5 From 2009-09-16 14:25:00 PST -------
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.
------- Comment #6 From 2010-08-06 07:47:39 PST -------
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.
------- Comment #7 From 2010-08-06 09:57:16 PST -------
Does this work with a nightly build?  We no longer support self-closing script tags.
------- Comment #8 From 2010-08-06 10:03:54 PST -------
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.
------- Comment #9 From 2010-08-09 15:47:09 PST -------
*** Bug 43751 has been marked as a duplicate of this bug. ***
------- Comment #10 From 2010-08-09 15:52:37 PST -------
<rdar://problem/8281296>
------- Comment #11 From 2011-08-19 13:37:24 PST -------
We should close this bug and replace it with specific bugs about the remaining false negatives.
------- Comment #12 From 2011-08-31 13:35:17 PST -------
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