Comment by Xk | Hacker News Reader

Comment by Xk | Hacker News Reader

Parent Full thread

There's been a lot of research about this recently (I've brought this up on HN previously). A team from Berkeley broke 50% of the 50 most popular extensions last year [1]. Some other researchers looked at explicitly malicious extensions [2].

One thing the authors don't mention (wich is brought up in the first paper): things can be much worse than this. If you inject untrusted content to the innerHTML of the extension itself, you've given an attacker the full privileges and permissions of the entire extension. This can be very serious if the extension has access to lots of data (e.g., many Chrome extensions have arbitrary access to all http and https webapges -- a bug in one of your extensions could give an attacker XSS on a user's bank).

The Google team has taken steps to mitigate this [3]. If you write a Chrome extension, you're being negligent if you don't implement a strong CSP. That will prevent the previous issue entirely, but not the issue brought up by OP.

[1] http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...

[2] http://profsandhu.com/zhang/pub/ndss12-chrome.pdf

[3] http://blog.chromium.org/2012/02/more-secure-extensions-by-d...

> That will prevent the previous issue entirely, but not the issue brought up by OP.

Hmm, shouldn't even a normal CSP prevent the issue brought up by the OP? I haven't actually written a CSPed extension, so I may be missing a key problem, but my understanding is that no inline scripts will execute (only scripts from whitelisted domains), which would prevent an injection like that.

You would think that it would. But the way Chrome has implemented CSP, it doesn't. When you specify a CSP in a Chrome extension, it applies to the core extension (the background page) and all content scripts. It does not, however, apply to webpages you are running on.

So, if your CSP is set to deny all images, you can still add an image to a webpage. You just can't add an image to the core extension itself. Similarly, if you block eval() with a CSP, you can still eval() from the context of a webpage.

Ah, yeah, thanks :)

It seems like it would be difficult for the browser to prevent extensions from ever suffering from that kind of attack. "any script tag that wasn't there before this function call is not executable" isn't too bad of a start, but even a moderately complicated web app likely has places where you can inject content that will be operated on by javascript from the site itself, which then transforms it into an XSS attack. For example, many sites will sanitize any user input, but will trust the content of dom elements created by themselves, without thinking about the case where the contents have been replaced by an extension which hasn't been properly sanitizing its own output.

It should still be covered by any CSP that a site has enabled, though. That (and this article) is a good argument for everyone to strongly consider adding a CSP to their sites, so that inline scripts can't be executed, even if an otherwise well-meaning extension slips up.

Reply on news.ycombinator.com