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.
> 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.
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.
Awesome! This right here is the best example of social media in action -- a suggestion for improvement was made, and the author liked it and implemented it.
This is not social media in action, this is HN in action :-) browsing comments here is more tolerable for authors and makers than practically anywhere else on the internet (basically because the discussion is better), hence why getting feedback here is more likely to happen.
I'll agree that the conversation here tends to be better, but there are still pockets of reddit that have the same high quality and have the same potential for authors. It is always made me happy when this type of interaction would happen.
It would nice if Chrome separated 'DOM write' permissions from 'DOM read' permissions. AFAIK, today extensions can't request only 'read' permissions.
Yes, I understand that it's a pain for new Chrome developers to have to understand the permission system among other things. I liked the easy ACLs of Chrome when I started.
So maybe they could allow permissions to be written in two different ways in the manifest file? Today's quick-and-dirty coarse-grain permission system would co-exist with a fine-grain permission system that would use new directives.
I'd love to prove to my users that my extension is in fact not malicious.
> Yes, I understand that it's a pain for new Chrome developers to have to understand the permission system among other things. I liked the easy ACLs of Chrome when I started.
That's a good thing IMO. Anyone who doesn't understand permissions and how to handle them, shouldn't be able to release anything in any app store.
You probably knew this, but you can write and distribute Chrome extensions without having to upload them to the chrome app^Wweb store.
Second, I've tried to work twice with Doing-It-Right (i.e., fine-grain) permission systems. Once with apparmor and earlier with SE Linux. With AppArmor, I wanted to set up rules to prevent Skype from reading any except a couple of directories. The sheer number of permissions I had to configure was exhausting and I gave up. Maybe I missed something simple, but that's why I'm not clamoring for the current simple, but coarse-grain permission system to be abandoned.
Well yes, grown-over-time permission systems are also at fault when it comes to the lack of security in third party extensions/apps. IMO unix is still the standard in terms of simplicity and power of permissions - if the system architect separates concerns correctly into different base entities ('files'), the permission system just falls into place. You know what other system did this pretty much perfectly? Lotus Notes. Yes, I'm serious - it's a document based DBMS with per-document permissions where everything is a document, including the application design, contacts, logs, calendar entries. Too bad its UI is still stuck in the early 90ies.
Mozilla has a submission process for Firefox extensions wherein the extension is manually reviewed by a Mozilla developer before being allowed in the add-on marketplace. I know from experience that extensions with XSS vulnerabilities fail inspection and are not hosted in the market until the code is fixed.
As far as I can tell, Chrome lets you upload pretty much whatever you want into the Chrome webstore.
I'd be curious whether Firefox extensions have these issues in even close to the same proportions as Chrome extensions.
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...