JavaScript must die

http://www.jgc.org/blog/2009/09/javascript-must-die.html

by jgrahamc • 17 years ago

16 59 17 years ago

gdp18• 17 years ago

I said as much in the blog comments, but I'll repeat it here too. The issues noted in the presentation, plus the fact that the language is a bit of a dog, is why I suggested proof-carrying code as a replacement for Javascript:

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

(and got pretty well flamed for it, too)

axod12• 17 years ago

Pretty silly really. (NoScript? deprecate js? aint gonna happen thankfully).

Many of the arguments are just arguments of why you don't include arbitrary untrusted javascript in your page. Many of the use cases of including external scripts in a page could be done exactly the same server-side, which would make them far more secure. But, it's extra work for websites to do that, so they often don't.

>> background-image: url('javascript:window.alert(1)')

Some browser seriously executes that js? I have not seen that work anywhere. (Just tested safari, firefox).

Perhaps a better answer would be to have browsers show you a small warning if the website is including js code from external sites, however, it's so common now that most websites would flag up. But it might cause people to rethink things a bit.

(Also as others say, the issues are not with the language javascript, but in the way it is used in browsers. Killing js wouldn't solve anything if you don't address the issues in the browsers).

gdp18• 17 years ago

What is 'trusted' javascript though?

There is no differentiation between 'trusted' and 'untrusted', which I think was the point that the presentation was making.

axod12• 17 years ago

Sure there is (I agree js doesn't know the difference, but we do, and we are the music makers).

trusted: I wrote it / looked over the source code

untrusted: I pasted some <script src=http://gonnaHackU.com/blah.js>; into my page.

Including <script> tags from external entities is always a potential security risk. And it's always better to do it serverside if at all possible.

daleharvey• 17 years ago

internet explorer allow javascript expressions in plain css, it used to be a handy trick to make zebra striped tables, although thats a bad use, its also part of what was behind the png hacks

axod12• 17 years ago

I was aware of expression() when used in css on IE, but didn't know anything would execute url('javascript:

IE7 executes expression() when used in css (inline/style/external css file), but not when you set css from js. Also cannot make it execute url('javascript:

(Safari/Firefox/Opera/Chrome execute none of the above).

gnoupi• 17 years ago

And again a link for which the only interest is the short, attracting and more or less controversial title.

mechanical_fish• 17 years ago

I read the title in the spirit of the classic Unix-Haters Handbook: It is both tongue-in-cheek and brutally honest at exactly the same time.

Though much of the suckage which inspired the the Unix-Haters Handbook has been fixed... or at least finessed [1]... it's still the case that there are aspects of Unix that suck. But of course that doesn't matter. Unix isn't going anywhere fast. It has outlived many of its alternatives, and the remaining alternatives are either worse or have little traction. None of the Unix-Haters were under any illusions about this: They would point out various features that were done better in other operating systems (old-school Mac OS, Windows, OS/2, perhaps even the Commodore Amiga though I don't remember that, and of course the late, lamented Lisp machine) but none of them seriously thought that any of these things had a chance in hell of unseating Unix, just as I suspect that jgc does not seriously think that Javascript will be replaced anytime soon.

Javascript and the DOM, like Unix, isn't something that was designed by a rational committee of experts, but it snuck up on all of us and is now ubiquitous, and the social and economic forces that built it in the first place will not let it disappear easily. To paraphrase Crockford, we should all thank god that JS is as good a system as it is, given the inauspicious conditions that surrounded its birth. But I'm perfectly prepared to hear jgc's argument that its security problems are so dire that you can't really fix them while still calling the result "Javascript". That's important information. The first step in working through a hopeless situation is to understand the size and shape of the hopeless part.

---

[1] Or, let's face it, in some cases we've all just joined hands, smiled, and agreed to love the suckage. It's the industry standard!

borism2• 17 years ago

really? the only interesting part of presentation you found to be the title? it was quite opposite for me - very interesting examples/proposals he has there under inflammatory attention-seeking title...

mahmud2• 17 years ago

It was a very interesting article. My eyes popped approx every 1.5 pages.

rimantas• 17 years ago

Iteresting, how new language will solve problems with have little to do with the language itself?

borism2• 17 years ago

Nowhere does he propose a new language built on the same foundation.

What he actually proposes if you read the presentation is more security for/around JS.

jgrahamc3• 17 years ago

Yes, but I do believe that it would be best to rethink JavaScript. Essentially you could start from a safe subset of JavaScript that remove the global nonsense and rebuilds with a proper object model that restricts how you can get a reference to an object.

Douglas Crockford makes a proposal for this in a recent presentation: http://www.slideshare.net/webdirections/douglas-crockford-aj...

DrJokepu4• 17 years ago

There's a difference between a language and an API. JavaScript is a very powerful language in itself that has features like closures to please professional developers but is also easy to grasp by novice or amateur programmers. This makes it ideal for the role of being a client-side script engine of the web.

There might be issues with the standard JavaScript API (I mean, the DOM) but this could be fixed by correcting the API, there's no need to "kill" the language.

gdp18• 17 years ago

Which API are you talking about?

I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is?

The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).

DrJokepu4• 17 years ago

I was, of course, talking about the JavaScript DOM API: https://developer.mozilla.org/En/DOM

amix2• 17 years ago

If we follow the idea of killing everything that's "insecure" then we will end up killing everything, because nothing is 100% secure. I vote for improving JavaScript, for example, by sourcing external code via Google Caja. We should also improve defense against XSS and CSRF attacks in today's most popular frameworks (because, a lot of the times it's not the JavaScript that's insecure, but the frameworks that developers use - - i.e. making it possible to source arbitrary HTML is a very bad idea, no matter if JavaScript is used or not [e.g. one can do malicious attacks via an image tag as well]).

gdp18• 17 years ago

> If we follow the idea of killing everything that's "insecure" then we will end up killing everything, because nothing is 100% secure

Perhaps, but killing off the stuff that is obviously and demonstrably broken seems like a pretty sensible policy.

amix2• 17 years ago

Killing one of the most popular languages isn't a solution, it's only wishful thinking. The situation with JavaScript isn't that bad, we just needs better tools such as a secure way to source external JavaScript and better protection against XSS and CSRF attacks... If these issues are solved, then 90% of the problems are solved.

scotty792• 17 years ago

There is only one sure way to prevent all kinds of attacks involving javascript.

Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.

If you want your users to post formatted content either don't use html for formatting (use something like markdown) or parse the html to tree, and run it through whitelist filter that will let through only tags you want to pass, only attribute values that you want to pass, and only values of attribute that you want to pass (defined by narrow regexps that dont allow such thing as background:url(javascript:)).

To sum up never mix other data types with html (kept in static places like template files or read-only database tables), unless you are absolutely sure that they contain html you want to display, either by htmlspecialchars-ing them (safe and fast general policy) or by parsing and whitelisting (for cases that you really, really have to allow some html).

gdp18• 17 years ago

> Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.

That seems like one way of using a sledgehammer to needlessly burn server-side CPU cycles.

mooism22• 17 years ago

Compared to the cost of accessing the database, html-escaping plain text is basically free.

scotty792• 17 years ago

Think like that and you will save one dollar in computing power during normal operation and lose over nine thousand when you'll be forced to clean up mess after xss worm attack.

pmichaud• 17 years ago

Sorely lacking from this article, even if we take it at face value, is any workable alternative solution.

themanual• 17 years ago

Javascript is now being used even in remote controllers today. See http://www.webdigi.co.uk/blog/2009/rise-of-javascript/

It certainly is a useful language.

wglb• 17 years ago

So let's presume that we come up with a better alternative, which this article doesn't suggest. By what mechanism do we replace all that is out there and ensure that the current js is not used anywhere by any of the bazillion web sites currently using it?

I think the horse is well out of the barn.

mahmud2• 17 years ago

What reading list do you recommend for a javascript security newb?

makecheck• 17 years ago

Computer security problems aren't that different from "real world" ones: it's a matter of trust. Either you believe that someone will do what you want, or they deceive you. While it's reasonable to have some systemic protections, at some point it is entirely up to the individual.

You might leave someone to watch over your house, and they could decide to trash it; that violates your trust, but it doesn't hurt your neighbor's house. You don't tie up every citizen to make it impossible for anyone to ever trash another house; you simply deal with that one trust violation, and learn from the experience. Also, you should tell others, to minimize how many suffer the same fate.

ammarr• 17 years ago

Why is the language insecure in all of this? What is it, in the ECMAScript Spec, which makes the language insecure? Programmers who do not know how to write secure code will leave security holes when programming in any language.

I find JavaScript to be wonderfully expressive, allowing me a great amount of power.

JavaScript must die

Related Stories