

Building a browser extension? Be careful not to XSS the whole internet - borski
http://blog.tinfoilsecurity.com/building-a-browser-extension-be-careful-not-t-17787

======
Xk
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...](http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf)

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

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

~~~
magicalist
> 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.

~~~
Xk
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.

~~~
magicalist
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.

------
jedberg
The most important thing in this article, which should be H1 bold at the top,
is:

 _If you didn't create the data, assume it is malicious_

~~~
borski
Completely agreed. Updated. Thx for the feedback.

~~~
jedberg
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.

~~~
Mahn
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.

~~~
jedberg
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.

------
luser001
Interesting.

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.

~~~
DeepDuh
> 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.

~~~
luser001
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.

~~~
DeepDuh
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.

------
TravisLS
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.

