Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I notice that Chrome does not execute scrips that are part of the web request,

http://vulnerable_site?pageTitle=<script>alert('xss')</script>

With such links since the script is as part of the web request, Chrome does not execute the script. Does that prevent all kinds of Reflected XSS attacks with Chrome browser ?

Edit: I've already read this thread, tough the title seems similar the contents are different

share|improve this question

4 Answers 4

up vote 4 down vote accepted

No, because the XSS filter only looks whether it sees XSS code in the input back in the HTML outputted by your server.

For example, if Chrome sees your web page is accessed with an URL that contains the following:

?q=<script>alert("XSS!")</script>

and if the HTML returned by the server contains this:

<p>You have searched for <b><script>alert("XSS!")</script>

it knows that this code is most likely the result of it being included in the request, and neutralizes it.

However, if the code is not found in the request, for example if the application accepts input that is encoded in some way, the filter may not be able to figure out that the code is the result of some XSS code embedded in the request.

As seen in the commit log for WebKit, until it was forked recently the rendering engine in Chrome, they are trying to address the most common bypasses, where the XSS-code in the URL and the resulting XSS-code in the HTML look slightly different.

If none of these rules for special cases apply, the XSS will be left through. For example, if they aren't decoding Base64-encoded data in the URL, if the web application were to accept input encoded with Base64, it may be possible to XSS a web application.

An example:

?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+

(PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+ is <script>alert("XSS!")</script> encoded in Base-64), if not filtered, would result in response HTML like this:

<p>You have searched for <b><script>alert("XSS!")</script>

Additionally, it won't stop XSS occurring with data that is not embedded in the HTML unencoded, but is treated in an unsafe way by JavaScript.

For example, consider a page which contains the following JavaScript:

eval(location.hash.substring(1))

This will execute any code trailing the # in the URL, but it is not filtered out by Chrome.

You can see this example in action here

Another example, which uses Base64

share|improve this answer

XSS prevention is not the responsibility of the browser, XSS holes arise because of flaws in a website, and it is up to the owners of websites to prevent such flaws.

Some browsers have implemented attempts at mitigating XSS and CSRF holes in websites, but these are heuristics looking for typical patterns of attacks. They are in no way complete.

There is infinitely many ways to implement an XSS hole, and there is no sure way of distinguishing between a hole and intended behaviour. There is no way a browser filter can ever be a replacement for site owners knowing about, caring about, and addressing the issue of XSS and CSRF holes.

I do wonder if these filters do more harm than good by creating a false sense of security.

share|improve this answer
    
Any examples would be great ... –  vikkyhacks Mar 17 at 5:48
    
+1 Sometimes XSS filters can be used against a website. e.g. adding ?<script>... to the URL where ... is some code you want filtered from the page output. –  SilverlightFox Mar 17 at 11:43
    
@vikkyhacks Take the W3Schools tryit editor for instance, it is basically a completely raw reflected XSS implementation, though it is intended behaviour, and a nice feature. But then again, it does actually allow one to forge a request that does whatever the hell one wants on thier domain, including pushing malware. (The W3Schools folks could and should make a token system that prevents code not being input through the form from being echoed.) The browser filters don't catch it for some reason, and whether or not they should is an open question. –  eBusiness Mar 17 at 18:54

Nope. See https://github.com/WebKit/webkit/commits/master/Source/WebCore/html/parser/XSSAuditor.cpp?page=1 and find the word "bypass". You will see Auditor bypasses that researchers have found over the period of time ...

share|improve this answer

chrome protects against all known reflected xss attack vectors. If you could find a way around this filter, goog will give you a bounty. That said, reflected xss is still a vulnerability on the website

share|improve this answer
    
@Totmaxx any link to support this answer would be great ? –  vikkyhacks Mar 17 at 5:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.