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.

Thanks. Will do.

edit: support email sent

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.

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.

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.

No.

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?

Fine. Assume it's one bit per voxel.

512 petabits = 2 petabytes.

So only 2 petabytes of data. I'd like to see the server that processed those 2 petabytes.

Notch also points out that even still, 8m is quite a small height. Take it to 16m and now you need 4 petabytes of space.