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.
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.
A summary of it: A worm used a linear congenital generator to generate its randomness. It used this generator to pick which IPs to try to infect, which hard drives to write data to, and what to write. These researchers used a /8, and were able to use that to count, exactly, the bandwith of all infected machines, how many hard drives machines each had, the time they started up, and locate the exact machine which initially spread the worm. It's really quite amazing that you can get all of this from just packet captures, before you think about it.
You have a very severe security vulnerability on your site. Please provide an email address in your info I can contact you at. (The email field is hidden to others.)
Edit: interwho has fixed the vulnerability. There was a CSRF allowing you to take over someone else's account if they visited your site.
Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1]
Web applications make state-changing operations on GET requests. You might not like it, but they do.
CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests.
Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it, there is no good way for the browser to fix the CSRF issue. You can ask the user, which is what's suggested, but that never really works. They'll do one of two things: click "okay" every single time, or stop using your browser.
I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window.
The proposed "solution" to CSRF stops ALL of these use cases. The user would have to manually approve each and every one of them. Given that well under 1% of alerts would be true attacks, the user would almost definitely "okay" on the attacks as well: they would have been trained by thousands of other alerts that this is an acceptable thing to do.
There was a paper by Barth and Jackson on CSRF defenses where they propose an Origin header, but that's the extent to which security is implemented in the browser. It is fundamentally up to the web application for verifying the user did in fact initiate the request. No amount of code in the web browser can get around this fact.
Researchers at UC Berkeley studied this exact question. About 40% of extensions contain at least one injection vulnerability. Some really popular extensions were vulnerable -- even a couple Google authored ones.
Suggestion: It is very hard to allow HTML but remove JavaScript. Write a method called something like isJSPresent() and then after you've done your filtering, check if JavaScript is on the page. If it is, return a HTML-encoded version of the page. Then, the security of your page will rely only on the correctness of that single method, and not on the correctness of your rewriter (which is much more complex).
Please don't use this for passwords. Security is very hard to get right.
Do they do a secure delete of the contents of the webpages? Who knows.
Do they have strong physical protection around the server? Who knows.
Do they run up to date software so the machine can't get taken over? Who knows.
Can you even trust them not to log all your passwords? Who knows.
This is an interesting service for some things, but I would never use it for sending passwords (or anything equally sensitive) back and forth.
Even if you let me "encrypt" the information before uploading it with a password, if this encryption is done in javascript sent by the server then as soon as the server is taken over you can't trust the encryption.
If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access.
However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?
Each Telex Station has it's own private key which it uses to decrypt the 224 bit tag. If one Telex station loses its private key, then the user will just use another.
They have an XSS on https://secure.trust-guard.com/ (enter a username like <img src=g -- yes, it won't work with chrome's XSS filter)... somehow I'm inclined to believe they are not so great.
(An attacker could exploit that in a number of ways. Here's a simple one: create a site with a domain name that looks really similar. http://secure.trustt-guard.com or something, it doesn't matter. When a user visits, autosubmit a form to https://secure.trust-guard.com with the malicious payload; the first thing it does is hide the error message and incorrect username. The user then enters username/password and attacker reads the values and sends it back to his site.)
What's worse, I can't find any way to report this. Does anyone see a link?
The current implementation uses an iframe and so they can't read the data out of the iframe (same-origin policy).
This would require injecting javascript on to news.ycombinator.com. It wouldn't be so bad, but it would require user interaction to do that. If it requires user interaction then it'll be less used.
Granted, they could make an extension which does that -- but now you have to download something just to use chat. That's a big barrier to entry.
The problem with captchas is they have to be readable to humans.
Sure, a captcha of "lI0Ol1o" would would probably be unreadable to a computer ... but it would be to a human too.
We're quickly approaching the point that image recognition is getting as good at solving image captchas as humans are, and when we do, we'll need to find some other way to do it.
First they say that they "generate around 1 petabyte of data per second"
Then they say "ATLAS produces up to 320M bytes per second, followed by CMS with 220M Bps. The data from ALICE amounts to 100M Bps and LHCb produces 50M Bps." only that sums up to 690M Bps ... definitely not 1 petabyte per second. (That is, assuming that 1M Bps means 1 million bytes per second, or just under 1 megabytes per second.)
And then, later on, they talk about a different mode in which "more data is produced by the four experiments, about 1.25G Bps in total." which is still not 1 petabyte per second.
If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt. There is no reason to separate the salt from the hash, and, in fact, there are no implementations which do that.
However, if I can't convince you of that, then if you ever make a website that takes passwords, please use bcrypt. You can do your super-special-salt-separation-scheme, but just use bcrypt instead of SHA-1.
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.