
JavaScript must die - jgrahamc
http://www.jgc.org/blog/2009/09/javascript-must-die.html
======
amix
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]).

~~~
gdp
> _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.

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

~~~
gdp
We're entitled to wishful thinking. Wishful thinking gives us something to aim
for, and then we can evaluate in realistic terms how far towards that goal we
can get.

~~~
thismat
Indeed, everyday I'm using this wishful thinking thing in hopes they won't
give me a COBOL project that day. :(

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

~~~
gdp
What is 'trusted' javascript though?

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

~~~
axod
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>](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.

~~~
gdp
Right, but that's just a social distinction. It does nothing to protect users
from careless web developers, and it does nothing to help web developers be
less careless.

Please, somebody think of the users!

There are obvious technical solutions to this, but people seem unwilling to
acknowledge that they might even be necessary.

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

~~~
gdp
> _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.

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

~~~
gdp
'basically free' * lots of users = not free.

~~~
mooism2
"basically free compared to the cost of something way more expensive" * lots
of users = still "basically free compared to the cost of something way more
expensive"

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

~~~
gdp
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).

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

~~~
jgrahamc
The DOM is unrelated to JavaScript's global variable/function/everything
oriented nature, the ability to do stuff like redefine the Object constructor,
the fact that there's no real protection between objects (e.g. guess the name
of a variable or function and you have access).

~~~
axod
The issue isn't that js has a global namespace, it's that scripts included on
the same page all use the _same_ global namespace.

This could easily be changed/fixed in browsers without changing anything about
js.

It'd be nice to be able to specify in a <script> tag if you want a new js
execution context setup, and also what access you want to give that script to
your own execution context.

For example, maybe:

<script src=<http://widgetmaker.com/wm.js> newContext=true
permissions="modifyDom:false,readNamespace=false,passMessages=true">

<script src=<http://hitcounter.com> newContext=true permissions="NONE">

With such a scheme, everything is executing in completely separate contexts,
with clear permissions about their interactions. Some script messes with the
Object constructor? only affects its own execution context.

Saying a blanket "js must die" isn't really understanding the issues, as they
are actually in browsers, not js.

It's like saying python/perl/etc is an insecure language and must die, because
it usually shares the same filesystem between processes.

~~~
jgrahamc
The would help, but it doesn't eliminate the problems. For example, the JSON
Hijacking attack would still work because the attacker would control the
'permissions' attribute in your proposal and allow himself access to the JSON
object via modification of the Object constructor.

It also adds a layer of decision making on the part of a web designer. I
believe it would be better to alter the language so that these global problems
are eliminated at the language level. Because any decision making about the
execution context are likely to cause problems themselves because people make
all sorts of mistakes and they would have to understand what it means.

~~~
axod
>> "because people make all sorts of mistakes and they would have to
understand what it means."

I think this sums it up really. People make mistakes and make insecure
software. Whatever language it is. I fail to see how swapping out js for
anything else would solve anything. It's all pretty moot also, since it'd
never happen.

The JSON attack again, isn't any inherent insecurity in the language, just in
the way it is used within browsers.

Lets improve browser security rather than focusing on a language which has
pretty much nothing to do with security issues. None of the examples you give
had anything to do with the core javascript language. They were all about how
it is used in the context of browsers.

Just to get this straight, one of your arguments is that since some browsers
apparently execute the javascript inside css "url('javascript:...", the
solution is to change javascript for some other language? Do you understand
how ridiculous that seems?

~~~
gdp
Given that I object to the use of Javascript outside of browsers, you've
basically negated (for me) any reason to treat the issue of language security
versus browser security separately.

~~~
axod
>> "Given that I object to the use of Javascript outside of browsers"

Fine. You seem to have something odd and bizarre against the language. Good
luck to you and your quest.

You also don't seem to realize that swapping out js for some other language
would mean exactly the same security issues, unless you actually fixed those
security issues where they are - in the BROWSER.

If you would like to learn about the language, I'd recommend "O'Reilly
Definitive Javascript". Also checkout Rhino.

~~~
gdp
> _You seem to have something odd and bizarre against the language._

It's not "odd and bizarre" - it's a belief that the language is fundamentally
unsuitable for the things that people insist upon using it for, and reasonably
well supported by my own experiences of the language, as well as the reported
experiences of others.

> _You also don't seem to realize that swapping out js for some other language
> would mean exactly the same security issues, unless you actually fixed those
> security issues where they are - in the BROWSER._

I take it you didn't read my reasonably concrete proposals for the use of
proof carrying code? It becomes a largely mechanical process to verify that
the browser _and_ the language implement "security" in a sensible way at that
point.

> _If you would like to learn about the language, I'd recommend "O'Reilly
> Definitive Javascript". Also checkout Rhino._

Thanks. If you would like to learn about Horse and Pony care, I recommend "BHS
Complete Horse and Pony Care".

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

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

~~~
jgrahamc
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...](http://www.slideshare.net/webdirections/douglas-crockford-ajax-
security-presentation)

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

------
gdp
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...](http://www.plsadventures.com/2009/08/worrying-trends-in-
programming.html)

(and got pretty well flamed for it, too)

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

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

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

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

~~~
mechanical_fish
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!

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

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

