13

In Firefox I've been using the NoScript extension to protect myself from certain kinds of malware attacks. NoScript is well known as a very powerful extension for Firefox and introduced protection from XSS and clickjacking attacks as far back as '07.

I've been looking for similar protection in Chrome, but the best I found was ScriptNo which does not specifically mention such a kind of protection (it only mentions Cross-Domain XML).

Does Google Chrome protect against cross site scripting (XSS)? (e.g. Is this passively achieved via sandboxing?)

Improve this question

1 Answer 1

Reset to default
13

Chrome has default protection against Reflective XSS attacks. This is not a flaw that sandboxing can address. This protection system works by looking outgoing requests for javascript and preventing that javascript from being executed in the http response. No browser will prevent DOM Based XSS or Stored XSS.

Chrome's protection is the weakest when compared to the others. IE's xss filter isn't very good, but slightly better than Chrome's. From my research I think the NoScript is by far the best. I have bypassed NoScript's XSS filter by exploiting content insensitivity, and they fixed the issue quickly. Chrome and IE still suffer from content insensitivity attacks.

Microsoft says that content insensitivity attacks against IE are "not a vulnerability" and they will never fix these issues. Chrome has had a bug report open for this issue and I haven't seen activity for about 6 months. So chrome might fix it eventually, maybe. Which to be honest both of these are horrible vendor responses. In general I find that NoScript and Mozilla have the strongest responses to vulnerabilities in their software and as a security researcher they are a joy to work with!

Improve this answer
16
  • 1
    @gentmatt I'm not sure to be honest. I think the chrome team has a lot on their hands and they are more concerned with just having a feature that says "protects against reflective xss" instead of making a really solid security feature. Microsoft on the other hand is just notorious for leaving vulnerabilities unpatched. A good example is the IE "drag-and-drop" vulnerability which was a remote code execution vulnerability left unpatched for almost two years. I hate IE so much.
    – rook
    Commented Jun 19, 2012 at 20:44
  • 2
    I would say it's because there is no way to make a 'perfect' XSS filter. There will always be ways to sneak content past a client-side filter that will cause a buggy server-side application to fail. The problem's in the server not the client, so you can't fix it there; the client-side XSS filter is a defence in depth measure that can't ever be watertight. By "fixing" it you would necessarily be adding to its false positives.
    – bobince
    Commented Jun 20, 2012 at 8:07
  • 5
    Personally I consider client-side XSS filtering to be a deeply mistaken idea, that only ever worked, for NoScript users, through obscurity: as long as there weren't too many users with NoScript, it could target the most common attacks and have some success. As soon as you build the filtering into a popular browser (ie: IE), it loses its effectiveness, as the attacks work around the filter.
    – bobince
    Commented Jun 20, 2012 at 8:09
  • 1
    Nowadays, Chrome and Firefox browsers prevent DOM Based XSS.
    – Iratzar Carrasson Bores
    Commented Apr 5, 2018 at 10:27
  • 1
    @Iratzar Carrasson Bores Incorrect, they prevent reflective XSS. Identification of DOM-Based XSS cannot be automated - it is very difficult to identify because it can happen in so many different ways.
    – rook
    Commented Apr 10, 2018 at 23:01

You must log in to answer this question.