

JavaScript: The Evil Parts from JSConf 2010 - voodootikigod
http://blip.tv/file/3684946

======
tptacek
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.

~~~
billyhoffman
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

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

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

~~~
tptacek
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.

~~~
apike
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.

~~~
tptacek
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.

------
Kilimanjaro
tl;dw

Transcript?

~~~
IgorPartola
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.

~~~
tptacek
Don't implement _any_ cryptography in JS, because that's stupid.

