6 Answers
6

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.

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.

+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.
– SilverlightFoxMar 17 '14 at 11:43

2

@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.
– aaaaaaaaaaaaMar 17 '14 at 18:54

To clarify a bit more, the XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can't catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.

which shows how the Chrome team itself doesn't expect it to be completely secure (which is probably impossible).

Those wouldn't execute in the context of the page, and so wouldn't actually constitute an XSS vulnerability, would they? (edit: see this bug -- it looks like this approach might work in Firefox, but not in Chrome, as is being discussed.)
– Jeremy BanksApr 18 '16 at 20:50

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