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:

Comments

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:

http://www.plsadventures.com/2009/08/worrying-trends-in-programming.html

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…
John,
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.

Philip
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…
Yes.

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

hardik
PHP developer india
Unknown said…
Yes.

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

hardik
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 last name …

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.0image 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), r, h, floor(m…

Importing an existing SSL key/certificate pair into a Java keystore

I'm writing this blog post in case anyone else has to Google that. In Java 6 keytool has been improved so that it now becomes possible to import an existing key and certificate (say one you generated outside of the Java world) into a keystore.

You need: Java 6 and openssl.

1. Suppose you have a certificate and key in PEM format. The key is named host.key and the certificate host.crt.

2. The first step is to convert them into a single PKCS12 file using the command: openssl pkcs12 -export -in host.crt -inkey host.key > host.p12. You will be asked for various passwords (the password to access the key (if set) and then the password for the PKCS12 file being created).

3. Then import the PKCS12 file into a keystore using the command: keytool -importkeystore -srckeystore host.p12 -destkeystore host.jks -srcstoretype pkcs12. You now have a keystore named host.jks containing the certificate/key you need.

For the sake of completeness here's the output of a full session I performe…