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