Skip to main content

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

Popular posts from this blog

Your last name contains invalid characters

My last name is "Graham-Cumming". But here's a typical form response when I enter it: Does the web site have any idea how rude it is to claim that my last name contains invalid characters? Clearly not. What they actually meant is: our web site will not accept that hyphen in your last name. But do they say that? No, of course not. They decide to shove in my face the claim that there's something wrong with my name. There's nothing wrong with my name, just as there's nothing wrong with someone whose first name is Jean-Marie, or someone whose last name is O'Reilly. What is wrong is that way this is being handled. If the system can't cope with non-letters and spaces it needs to say that. How about the following error message: Our system is unable to process last names that contain non-letters, please replace them with spaces. Don't blame me for having a last name that your system doesn't like, whose fault is that? Saying "Your

All the symmetrical watch faces (and code to generate them)

If you ever look at pictures of clocks and watches in advertising they are set to roughly 10:10 which is meant to be the most attractive (smiling!) position for the hands . They are actually set to 10:09.14 if the hands are truly symmetrical. CC BY 2.0 image by Shinji I wanted to know what all the possible symmetrical watch faces are and so I wrote some code using Processing. Here's the output (there's one watch face missing, 00:00 or 12:00, because it's very boring): The key to writing this is to figure out the relationship between the hour and minute hands when the watch face is symmetrical. In an hour the minute hand moves through 360° and the hour hand moves through 30° (12 hours are shown on the watch face and 360/12 = 30). The core loop inside the program is this:   for (int h = 0; h <= 12; h++) {     float m = (360-30*float(h))*2/13;     int s = round(60*(m-floor(m)));     int col = h%6;     int row = floor(h/6);     draw_clock((r+f)*(2*col+1), (r+f)*(row*2+1),

The Elevator Button Problem

User interface design is hard. It's hard because people perceive apparently simple things very differently. For example, take a look at this interface to an elevator: From flickr Now imagine the following situation. You are on the third floor of this building and you wish to go to the tenth. The elevator is on the fifth floor and there's an indicator that tells you where it is. Which button do you press? Most people probably say: "press up" since they want to go up. Not long ago I watched someone do the opposite and questioned them about their behavior. They said: "well the elevator is on the fifth floor and I am on the third, so I want it to come down to me". Much can be learnt about the design of user interfaces by considering this, apparently, simple interface. If you think about the elevator button problem you'll find that something so simple has hidden depths. How do people learn about elevator calling? What's the right amount of