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:


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.

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

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

Unknown 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!

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.

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


Larry said...

A lot of the code in the slides have small bugs in them and most of the security can be safely dealt with, but overall it's a good presentation.

I'm surprised there was nothing on Javascript and Flash interaction, HTML5 WebSocket, Webworkers or Ajax.

Here are a few quotes from that I disagree with.
"The language itself has no security awareness."
What about closure?
(function(e){ var privateObj = {}; })(window);

"Oh and it's the most important language for all web sites."
Web site can work without Javascript, but not without HTML.

daytonn said...

I agree with Garren. This exposes the real problem with JavaScript, it's profoundly misunderstood. Why is it that we're always judging languages by how easy it is for inexperienced developers to get into trouble. We hear this all the time regarding the static vs. dynamic languages. If you don't spend the time to fully grasp the language, any language will let you do bad things. Security is a developer's concern. It's humans who exploit code so it has to be humans who protect it. If we replace JavaScript, are we not going to have to be concerned about security? I doubt it.

Unknown said...


You are write at your thesis, but without javascript web is nothing, anyone can prove it.

PHP developer india

Unknown said...


You are write at your thesis, but without javascript web is nothing, anyone can prove it.

PHP developer india

eirikma said...

Sounds like you sugggest we could put and end to burglaries if buildings stopped having doors and windows. Interesting, from a theoretical point of view, but the main reason to use web browsers in the first place is to access functionality built on top of javascript, just like the main reason to build a house is to have a place that you can enter and leave.

glazou said...

No, JavaScript is not in CSS (slide 10). This is *NOT* CSS. This is a proprietary extension to CSS implemented by Microsoft and that other browser vendors refused to standardize and implement.

Daniel Glazman
W3C CSS Working Group, Co-chairman

Jamie Stewart said...

Thanks for this presentation I think it's a great compilation of security issues developers face. I am concerned however that the name will put devs off reading what is valuable information and instead of using this to kill JavaScript we should be using it to educate JavaScript developers and focus the conclusion more on the techniques used to battle such security loop holes.

Maybe the death of JavaScript is the way to go, who really is in a position to declare that? But what I would say is, as it stands, it's an excellent language when used properly and we should focus our immediate attentions on ensuring future JavaScript devs are well educated instead of suggesting they drop JavaScript and wait until something else comes along, which will have other flaws and we return to our cycle of waiting for this silver bullet to solve all our problems.

Unknown said...

People who hate javascript dont know jack's sh*t about it.
People who love javascript are wise enough to separate it from it's surroundings...

Making an old USB printer support Apple AirPrint using a Raspberry Pi

There are longer tutorials on how to connect a USB printer to a Raspberry Pi and make it accessible via AirPrint but here's the minimal ...