Bug 29278

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.

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>

(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

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.

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.

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.

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

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.

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

<rdar://problem/8281296>

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

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