The XSS auditor isn't able to detect injections into script contexts. Sometimes it will catch these sorts of injections "by accident", but often there's a way to bypass the auditor in these scenarios. The auditor is much better at catching injections in attribute values and between tags.
The IE folks have a nice write-up about what sorts of vulnerabilities are in scope for their filter. We should probably create a similar write-up for our filter. Originally, we wrote <http://www.adambarth.com/papers/2010/bates-barth-jackson.pdf>, which explained some of these issues, but we've redesigned the filter since that paper was written, so not everything in the paper is accurate anymore. (By the way, this isn't the best forum to talk about potentially security-sensitive topics. Generally the best way to do that is to file a security bug <https://bugs.webkit.org/enter_bug.cgi?product=Security>. That us track the issue and lets us disclose the issue responsibly.) Adam On Sat, Mar 31, 2012 at 5:36 AM, Prasad Shenoy <[email protected]> wrote: > [ If this is not the right forum for the following question, please let me > know ] > > > Hello, > > I am new to the list and am looking for advice on something I observed > during a recent engagement. The issue mostly looks like a potential > XSSAuditor bypass but I am unsure if the behavior is by design or is > actually a bug. > > To start with, here is the scenario: > > 1. Chrome sends an HTTP POST request with user provided input, the > input is a simple XSS string as shown in the request log below: > > -- sample request -- > > POST /filter_params HTTP/1.1 > Host: xx.xx.xx.xx > Connection: keep-alive > Content-Length: 589 > Origin: https://xx.xx.xx.xx > X-Prototype-Version: 1.6.0.3 > X-Requested-With: XMLHttpRequest > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ > 535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11 > Content-type: application/x-www-form-urlencoded; charset=UTF-8 > Accept: text/javascript, text/html, application/xml, text/xml, */* > Referer: https://xx.xx.xx.xx/tools/1 > Accept-Encoding: gzip,deflate,sdch > Accept-Language: en-US,en;q=0.8 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 > Cookie: user_credentials=abcd > > filter_params=&filter_params_set_name=%3Cscript%3Ealert(566656)%3C > %2Fscript%3E&filter_params_ngrams=&commit=Submit&filter%5Bname%5D= > %3Cscript%3Ealert(566656)%3C%2Fscript%3E&_= > > 2. The server responds with HTTP 200 OK. The response is as shown > below: > > -- sample response -- > > HTTP/1.1 200 OK > Content-Type: text/javascript; charset=utf-8 > Connection: keep-alive > Status: 200 > X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.7 > X-Runtime: 81 > Content-Length: 420 > Cache-Control: private, max-age=0, must-revalidate > Server: nginx/1.0.0 + Phusion Passenger 3.0.7 (mod_rails/mod_rack) > > var opt = document.createElement('option'); opt.text = > '<script>alert(566656)</script>'; opt.value = '435'; opt.selected = > true; $('filter_params').options.add(opt) > $('scenarios_container').insert('<span id="435"><script>alert(566656)</ > script><small class="edits">o</small><small class="closes">x</small></ > span>') > $('new_filter_params').hide() > $('filter_params_set_name').value = ''; $ > ('filter_params_ngrams').value = '' > > 3. The result is a prompt with 566656. The above code is supposed to > dynamically populate a drop-down list with options provided by the end > user. > > XSSAuditor is enabled at this point so my am wondering if the > JavaScript code in the response is not filtered because it is part of > a script and not a normal HTML response body? > > Any insight or reasoning for this behavior is appreciated :) > > Thanks > Prasad > > Thank you, > Prasad N. Shenoy > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
