Bug 29278 - XSSAuditor bypasses from sla.ckers.org
: XSSAuditor bypasses from sla.ckers.org
Status: RESOLVED WORKSFORME
Product: WebKit
Classification: Unclassified
Component: WebCore Misc.
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
http://sla.ckers.org/forum/read.php?1...
: InRadar, XSSAuditor
Depends on: 29306 29511 29523
Blocks: 66579
  Show dependency treegraph
 
Reported: 2009-09-15 13:33 PDT by Adam Barth
Modified: 2011-08-31 13:35 PDT (History)
7 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2009-09-15 13:33:02 PDT
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 Daniel Bates 2009-09-15 15:06:11 PDT
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 Mario Heiderich 2009-09-15 16:25:04 PDT
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 Mario Heiderich 2009-09-15 16:32:09 PDT
(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 Daniel Bates 2009-09-15 18:21:02 PDT
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.
Comment 6 Mario Heiderich 2010-08-06 07:47:39 PDT
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 Adam Barth 2010-08-06 09:57:16 PDT
Does this work with a nightly build?  We no longer support self-closing script tags.
Comment 8 Mario Heiderich 2010-08-06 10:03:54 PDT
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 Adam Barth 2010-08-09 15:47:09 PDT
*** Bug 43751 has been marked as a duplicate of this bug. ***
Comment 10 David Kilzer (:ddkilzer) 2010-08-09 15:52:37 PDT
<rdar://problem/8281296>
Comment 11 Adam Barth 2011-08-19 13:37:24 PDT
We should close this bug and replace it with specific bugs about the remaining false negatives.
Comment 12 Thomas Sepez 2011-08-31 13:35:17 PDT
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