Friday, September 25, 2009

JavaScript must die

I've just completed my presentation at Virus Bulletin 2009 which was entitled JavaScript Security: The Elephant running in your browser.

My thesis is that the security situation with JavaScript is so poor that the only solution is to kill it. End users have very little in the way of protection against malicious JavaScript, major web sites suffer from XSS and CSRF flaws, the language itself allows appalling security holes, and as data moves to the cloud the 14 year old JavaScript security sandbox becomes more and more irrelevant.

Here are the slides:



Blogger Gian said...

Nice presentation. I'm reasonably ignorant about Javascript security issues, because I never got past the fact that the language is a bit of a dog.

Which is why I was advocating proof-carrying code to replace JS:

The logistics of such a thing are still a little vague, but it appears to me that fine-grained security control needs to be done in a way that is largely invisible to most users, so that proof guarantees are checked against a standard set of things that should or shouldn't be allowed, where it becomes obvious pretty quickly if someone is trying to do something malicious.

10:48 AM  
Blogger Mark C said...

Rather than replace, how about "fix?" One basic functionality that could drastically improve the situation is adding an attribute to the script tag that creates a custom global (window) object and/or gives them permissions to the page (e.g. rights="global,dom"). Not the only answer, but JavaScript isn't necessarily "broken." The concept of including from remote sites is in itself a bit broken.

1:53 PM  
Blogger said...

Nice presentation; but I think it can't be killed; all languages have security issues.

We just fix these holes or create the new JavaScript language :D

12:45 AM  
OpenID Garren said...

Just a couple of comments:

Quite a bit of what you're describing really falls on the shoulders of the developer. Ex. xss, csrf - these don't really demonstrate a deficiency in the language itself and are instead examples of developer responsibilities.

"DSN attacks" - what about arp cache poisoning, mitm attacks and ip spoofing? Real concerns, to be sure, but again not really language issues. In fact any one of these would suggest a level of sophistication far above simple script injection and phishing. In other words, you've got bigger problems. Also, you mention a "cloud attack", can you give an example?

Finally, your actual critique of the language seems is interesting.

"Variables/Functions have global scope" - not necessarily. Both can be grouped into a namespace like construct (think JQuery) or defined as a method or property off a class or instance. It's really up to the developer. In fact this is true of most mainstream languages: C, C++ (the latter is only really OO if the developer decides to follow an OO design philosophy). Further C# and Java can be coded up in such a way the you're dealing with a single monolithic class with monster 1kloc methods, effectively functioning as a global environment. These are developer concerns not language problems.
"Objects inherit from a global object" - again, common in many mainstream languages and frameworks (C# -> Object, Java -> Object, Ruby -> Object, C++/MFC -> CObject, etc). Hardly a language problem.
"Scripts can re-define each others functions" - This is actually an interesting and useful characteristic that is finding its way into quite a few languages. This is both very powerful and useful, but, like anything else, can be abused. Hardly a language deficiency. Any OO language would allow one to compose a class and supply an alternate method implementation with the same signature, not necessarily giving the same type/interface, but effectively doing the same thing. C# even allows for the "override" keyword that allows for something similar. Again, not a language issue.

I agree that there are concerns that need to be addressed but the idea of deprecating javascript is absurd. I suggest an alternative: convince developers that a site should function entirely without javsscript. Javascript should supplement functionality not define it. Done.

11:57 PM  
Blogger Mike T. said...

Slide 8 has some problems, I'll help you fix them.

Remove the first point "JavaScript is inherently a 'global' language"--it's false.

The next two points can be fixed by adding the word global: "Global variables have global scope," as well as "Global functions have global functions."

Now it's fixed and your reader won't be mislead!

4:32 PM  
Blogger tz said...

Here are the slides:

[NoScript icon indicating javascript starting up flash].

Should we just move all to ActiveX and be done with it :).

Let he who is without script press the first delete key.

I remember seeing a caption "why americans don't understand Irony" below a picture of a Gym accessed by escalators.

But this is MUCH better.

Actually java might be an alternative. Part of the problem is trying to do active-content light, in something like BASIC.

6:38 AM  
Blogger Phil said...

Loved your appearance on SecurityNow! with Leo and Steve talking about how to better secure JavaScript; it seems if we don't wake up, JavaScript may well turn into SkyNET! :)

Great podcast.


4:36 AM  

Post a Comment

Links to this post:

Create a Link

<< Home