When you're just an XSS away from an attacker doing:
function encrypt(plaintext) {
$.post(plaintext, ...);
return plaintext;
}
"XSS isn't the only way either." That's about as illuminating as saying "something bad could happen."
No one is saying JavaScript or browser security is perfect, but if you actually know what you're doing, it can be done properly.
The original "JavaScript security is doomed" Matasano article is extremely out of date at this point, and yet people keep referring to it like it's gospel.
Sure, you can set up your app to stupidly do evals everywhere, but you can program a bad app in any language.
> XSS isn't the only way either
That's very, very vague. I asked what the attack vectors are. Saying "others" doesn't really work for me.
Another vector to get rogue JS into a user's browser is cache-poisoning, something the article also brings up.
[1] http://media.blackhat.com/bh-us-12/Briefings/Osborn/BH_US_12...
1. Browsers, at least the ones that matter, provide window.crypto (with a CSPRNG). This makes generating IV's for CBC "safe," makes generating RSA keys "safe," makes generating random keys "safe." Or am I missing something? Assuming the JS crypto code itself is actually sound, the PRNG seems to be the missing link...or at least, it was.
2. Packaging the entire app as an addon (assets, javascript, views, everything) means the app can be signed and verified. No in-app code updates. If you want an update, download the latest extension. The article assumes that people will do what OP is doing: downloading code and running it dynamically. I agree this is a no-no, even if verifying.
Is there some sort of attack vector I'm missing? I think it's fair to assume the browser is an attack vector, just like hardware is, just like the OS is, or whatever language VM you're running on, etc...but that seems tangential to the process of packaging/signing an entire javascript app and distributing it as an add-on. I also know about the unsafe memory stuff, but this just brings browser encryption down to the level of Python/Ruby/etc. I'm not dismissing this concern, I'm saying that if you're attacking javascript for having this vulnerability, you must also attack any GC language (which you do in the article).
How is in-browser encryption so different from any other java/python/etc app when packaged/signed? I'm not talking about replacing SSL, I'm talking about encrypting data via AES/blowfish in a browser extension with a key generated from a password, and if the data leaves the browser, using SSL on top of that.
What makes it impossible to do this and gain the same level of security as any other language/platform?