JavaScript must die
jgc.org
jgc.org
Perhaps, but killing off the stuff that is obviously and demonstrably broken seems like a pretty sensible policy.
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).
There is no differentiation between 'trusted' and 'untrusted', which I think was the point that the presentation was making.
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.
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.
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).
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).
That seems like one way of using a sledgehammer to needlessly burn server-side CPU cycles.
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.
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).
Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context.
<script> tags are not part of the js language.
It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
<script>
var a = "hello, world";
</script>
<script>
doSomething(a);
</script>
Once again, I (recursively) refer you to this comment:
You're well aware we're talking about <script> tags when used to load external source from other domains, so your example above is pretty irrelevant.
Good luck on your quest to rid the world of javascript!
Really, I don't understand the hostility here. Surely this is a worthwhile discussion to have? Either we can establish that it's not a problem that needs fixing, or we can establish that something needs fixing, and identify where it is.
Implying that I'm on some kind of vendetta just because I disagree with you about the source and nature of the flaws in javascript seems a little bit juvenile. These are genuinely-held opinions, and I'd appreciate it if you would not assume that I'm being disingenuous just because I disagree with you.
I, for one, remain totally unimpressed by these accusations of insecurity. They don't seem like a big deal at all.
Lazy and/or incompetent programmers will always find a way to write insecure code.
Why? Just have them in a separate execution context, and give them specific permissions... eg you can mess with the DOM, but only within this specific element, you can pass me messages, you can't access my execution context etc etc.
Such fine grained permissions would allow everything that goes on already, and disallow things you don't want to happen.
I agree though, the 'brokenness' is being vastly overplayed here. js isn't "broken", browsers aren't "broken", they just need improving, which is happening.
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.
It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.
No, it's not, because well-formed, valid Javascript code is permitted to depend on this execution model.
The decision to combine 20 <script> sources into the same execution context is the BROWSERS decision. NOT javascripts.
It's the BROWSER that doesn't have any concept of allowing <script> fine grained permissions within the execution context, or specifying you'd prefer if the browser put that script in a separate execution context.
It's the BROWSER that needs fixing here, not js.
JavaScript in a browser runs in the global namespace of the WINDOW, which is defined by the DOM API. Remember that JavaScript, on its own, is a headless language, with no I/O of any kind. It relies on the runtime environment to provide it with scope, context, and i/o, among other things.
Moreover, you can easily "fake" private members/functions/etc by using closures. (Yay!)
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.
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?
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.
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".
What he actually proposes if you read the presentation is more security for/around JS.
Douglas Crockford makes a proposal for this in a recent presentation: http://www.slideshare.net/webdirections/douglas-crockford-aj...
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.
http://www.plsadventures.com/2009/08/worrying-trends-in-prog...
(and got pretty well flamed for it, too)
I think the horse is well out of the barn.
I find JavaScript to be wonderfully expressive, allowing me a great amount of power.
It certainly is a useful language.
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!