29278 2009-09-15 13:33:02 -0700 XSSAuditor bypasses from sla.ckers.org 2011-08-31 13:35:17 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All RESOLVED WORKSFORME http://sla.ckers.org/forum/read.php?13,31377 InRadar, XSSAuditor P2 Normal --- 29306 29511 29523 66579 1 abarth webkit-unassigned abarth ap dbates ddkilzer mario.heiderich sam tsepez oldest_to_newest 147368 0 abarth 2009-09-15 13:33:02 -0700 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. 147391 1 dbates 2009-09-15 15:06:11 -0700 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. 147411 2 mario.heiderich 2009-09-15 16:25:04 -0700 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> 147416 3 mario.heiderich 2009-09-15 16:32:09 -0700 (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 147443 4 39628 dbates 2009-09-15 18:21:02 -0700 Created attachment 39628 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. 147623 5 abarth 2009-09-16 14:25:00 -0700 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. 261250 6 mario.heiderich 2010-08-06 07:47:39 -0700 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. 261314 7 abarth 2010-08-06 09:57:16 -0700 Does this work with a nightly build? We no longer support self-closing script tags. 261320 8 mario.heiderich 2010-08-06 10:03:54 -0700 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. 262366 9 abarth 2010-08-09 15:47:09 -0700 *** Bug 43751 has been marked as a duplicate of this bug. *** 262372 10 ddkilzer 2010-08-09 15:52:37 -0700 <rdar://problem/8281296> 454035 11 abarth 2011-08-19 13:37:24 -0700 We should close this bug and replace it with specific bugs about the remaining false negatives. 459863 12 tsepez 2011-08-31 13:35:17 -0700 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 39628 2009-09-15 18:21:02 -0700 2009-09-19 14:53:48 -0700 temp. workaround with test case for IFrame JavaScript URL issue workaround_iframe_javascript_url_double_encode.diff text/plain 2072 dbates SW5kZXg6IFdlYkNvcmUvbG9hZGVyL0ZyYW1lTG9hZGVyLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJD b3JlL2xvYWRlci9GcmFtZUxvYWRlci5jcHAJKHJldmlzaW9uIDQ4NDAyKQorKysgV2ViQ29yZS9s b2FkZXIvRnJhbWVMb2FkZXIuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC03NDMsNyArNzQzLDggQEAK ICAgICBjb25zdCBpbnQgamF2YXNjcmlwdFNjaGVtZUxlbmd0aCA9IHNpemVvZigiamF2YXNjcmlw dDoiKSAtIDE7CiAKICAgICBTdHJpbmcgc2NyaXB0ID0gZGVjb2RlVVJMRXNjYXBlU2VxdWVuY2Vz KHVybC5zdHJpbmcoKS5zdWJzdHJpbmcoamF2YXNjcmlwdFNjaGVtZUxlbmd0aCkpOwotICAgIFNj cmlwdFZhbHVlIHJlc3VsdCA9IGV4ZWN1dGVTY3JpcHQoc2NyaXB0LCB1c2VyR2VzdHVyZSk7Cisg ICAgU2NyaXB0VmFsdWUgcmVzdWx0ID0gbV9mcmFtZS0+c2NyaXB0KCktPnhzc0F1ZGl0b3IoKS0+ Y2FuRXZhbHVhdGVKYXZhU2NyaXB0VVJMKHVybC5zdHJpbmcoKS5zdWJzdHJpbmcoamF2YXNjcmlw dFNjaGVtZUxlbmd0aCkpPyAKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhlY3V0ZVNjcmlw dChzY3JpcHQsIHVzZXJHZXN0dXJlKSA6IFNjcmlwdFZhbHVlKCk7CiAKICAgICBTdHJpbmcgc2Ny aXB0UmVzdWx0OwogICAgIGlmICghcmVzdWx0LmdldFN0cmluZyhzY3JpcHRSZXN1bHQpKQpJbmRl eDogTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9zZWN1cml0eS94c3NBdWRpdG9yL2lmcmFtZS1qYXZh c2NyaXB0LXVybC11cmwtZW5jb2RlZC1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0 VGVzdHMvaHR0cC90ZXN0cy9zZWN1cml0eS94c3NBdWRpdG9yL2lmcmFtZS1qYXZhc2NyaXB0LXVy bC11cmwtZW5jb2RlZC1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9o dHRwL3Rlc3RzL3NlY3VyaXR5L3hzc0F1ZGl0b3IvaWZyYW1lLWphdmFzY3JpcHQtdXJsLXVybC1l bmNvZGVkLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzIEBACitDT05TT0xF IE1FU1NBR0U6IGxpbmUgMTogUmVmdXNlZCB0byBleGVjdXRlIGEgSmF2YVNjcmlwdCBzY3JpcHQu IFNvdXJjZSBjb2RlIG9mIHNjcmlwdCBmb3VuZCB3aXRoaW4gcmVxdWVzdC4KKworCkluZGV4OiBM YXlvdXRUZXN0cy9odHRwL3Rlc3RzL3NlY3VyaXR5L3hzc0F1ZGl0b3IvaWZyYW1lLWphdmFzY3Jp cHQtdXJsLXVybC1lbmNvZGVkLmh0bWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvaHR0cC90 ZXN0cy9zZWN1cml0eS94c3NBdWRpdG9yL2lmcmFtZS1qYXZhc2NyaXB0LXVybC11cmwtZW5jb2Rl ZC5odG1sCShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9zZWN1cml0eS94 c3NBdWRpdG9yL2lmcmFtZS1qYXZhc2NyaXB0LXVybC11cmwtZW5jb2RlZC5odG1sCShyZXZpc2lv biAwKQpAQCAtMCwwICsxLDE1IEBACis8IURPQ1RZUEUgaHRtbD4KKzxodG1sPgorPGhlYWQ+Cis8 c2NyaXB0PgoraWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikgeworICAgIGxheW91dFRl c3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKKyAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5zZXRY U1NBdWRpdG9yRW5hYmxlZCh0cnVlKTsKK30KKzwvc2NyaXB0PgorPC9oZWFkPgorPGJvZHk+Cis8 aWZyYW1lIHNyYz0iaHR0cDovL2xvY2FsaG9zdDo4MDAwL3NlY3VyaXR5L3hzc0F1ZGl0b3IvcmVz b3VyY2VzL2VjaG8taW50ZXJ0YWcucGw/cT0lM0NpZnJhbWUlMjBzcmM9amF2YXNjcmlwdCUzQSUy NzElMjUyNTI1MSUyNyUzQmFsZXJ0JTI4ZG9jdW1lbnQuZG9tYWluJTI5JTNFIj4KKzwvaWZyYW1l PgorPC9ib2R5PgorPC9odG1sPgo=