JavaScript: The Evil Parts from JSConf 2010 | Hacker News Reader

JavaScript: The Evil Parts from JSConf 2010

blip.tv

48 pointsvoodootikigod11 comments

Disappointing. Nothing but respect for Billy Hoffman, but this talk has very little to do with Javascript and almost everything to do with the browser security model. Being able to using request timing to sniff things out of someone's email spool is an "evil part" of the browser and of the application architecture of Gmail. It's not a facet of Javascript.

The only thing in this talk that seemed uniquely Javascript-y was his explanation of di Paola's Prototype Hijacking attack (where you override the Ajax calls to sniff requests). But this is an issue in virtually every dynamic language; it's not a specific flaw in Javascript.

I want to be careful here, because I've had to give this talk a bunch of times --- the one security talk at a generalist conference, which is always going to devolve into a survey talk. I'm sure his audience loved it. I'm not sniping at Hoffman. But on HN, when you say "Javascript: The Evil Parts", I'm really wanting to see something about the evil parts of Javascript; like, I don't know, maybe automatic semicolon insertion being exploitable.

I think the whole white-space obfuscation is pretty neat. You could do that elsewhere, but the particular use-cases for JavaScript I guess are more susceptible to this method.

Thomas,

Man, if only there was something negative and bad around semicolon insertion, besides JSLint yelling at you ;-)

I appreciate the props, especially coming from someone of your caliber. The talk was exactly what you said it was, a survey of nasty tricks that people have used. The goal was to review features of JavaScript, the DOM, plug-ins, etc, that seemed like a good idea (getting computed styles, rich error handling around the Image object, window.onerror as a massive TRY...CATCH that can recover syntax errors, runtime modification of code, etc) and how those have been twisted to create some nasty problems. More importantly, nasty problems that we really cannot patch away. If we know how we created design flaws in the past, hopefully we will not do them in the future.

Billy

This presentation was awesome. In particular, the hydration/dehydration explanation at 51:35 was deliciously evil: replacing ones and zeroes with tabs and spaces to not just obfuscate javascript, but actually hide it from human view altogether.

The most disconcerting part for me was about attacking services inside a firewall using JS, starting around 45:00. He explains how somebody once wrote a page that, if you load it, would log in to your wireless router (if it had the default password) and hijack your DNS and all your requests.

But this has almost nothing to do with Javascript! The problem here is that the browser engine to which your Javascript context is attached will make virtually arbitrary HTTP requests based solely on the contents of the DOM.

If you think faking HTTP login and action requests from Javascript and the DOM is bad, Google "samy nat pinning", which you can do without JS, and which will trick many soho routers into directly allowing remote users onto your network.

It doesn't have to be a fault in the JavaScript language for it to be disconcerting or fascinating. That NAT pinning attack is also disconcerting and fascinating. An XSS to your router attack is more elementary and so it's easier to grok for the average JavaScript developer and less interesting to a security expert.

The fact that Hoffman's router attack wasn't XSS is an example of why I'm disappointed in this talk. I grant you that the talk was probably fascinating, especially to generalist Javascript programmers. I'm only disappointed in a "Hacker News" sense. Of course, it's not Hoffman's job to be fascinating to (or appropriately headlined on) Hacker News.

tl;dw

Transcript?

JavaScript often runs in a trusted environment, same origin policy does not save you from accessing certain kinds of information so you can cause mayhem even on private networks, you can overwrite built-in functions to sniff things out, there are CSS exploits (the history exploit for example) which allow you to de-anonymize a user, obfuscating code is easy.

Also, don't implement public key cryptography in JS, because that's stupid.

Don't implement any cryptography in JS, because that's stupid.

Reply on news.ycombinator.com