Comment Re:Javascript means no dice (Score 1) 153
If you want to engage my argument — by all means; but unless you want to look childish, please avoid the ad-hominem attacks (you have no idea what I do or do not understand).
Even if you made a perfect browser [...] that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable...
This is the point I was trying to make! The vulnerabilities are NOT the fault of the JavaScript language!
... because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this,...
No, as you just admitted just a sentence ago, "the design of JavaScript" does NOT enable XSS!
In all three types of XSS (DOM Based, Reflected, and Persistent) the fault is with the programmer (writing browser-side JavaScript code in the DOM Based case and writing server-side code in the other two cases) not validating data they are using to manipulate the DOM (DOM Based) or generate the HTML returned by the server (Reflected, Persistent). The fact that HTML allows a <script> tag is the very root of what allows this to exist at all; where the real fault lies is with the lazy programmer who is not validating the data. Neither the existence of the tag in HTML or the laziness of the programmer is the fault of the JavaScript language.
because the separation between code and data is flimsy (you can insert JavaScript almost everywhere in HTML, with "on..." events -- you don't even need a script tag);
OK.... let's look at some JavaScript
var b = {x:'y', i:'z'};
doSomething(b);
Well, what's "code" and what's "data" seems pretty clear to me, b is holding some "data"; there's a function getting called as part of some "code", etc; but I imagine you are trying to refer to something along the lines of:
<html>
<head>
<script>var a = 1;</script>
</head>
<body onload="alert(a);">
</body>
</html>
The problem with referring to that though, is that's HTML, not JavaScript. (And you didn't title your comment thread HTML means no dice.) (Your assertion that you can "insert JavaScript almost everywhere" is flatly wrong too, btw; you can only insert it in <script> elements or in event hander attributes (onload, etc). You can throw <script> elements just about anywhere, but with JavaScript only existing in those two places, it's really not that hard to identify it as being "code".)
you couldn't do it unintentionally with a web browser that only understood Java, and a Java web application. JavaScript makes it very easy, just like C makes it easy to mishandle pointers and fixed length buffers. If C gets criticized for that, it's fair to criticize JavaScript for making XSS vulnerabilities easy.
More of the same... There is no reason someone couldn't (though plenty of reasons someone wouldn't) write a web browser that supported interpreting Java source code instead of JavaScript source code. And if that browser exposed the same host objects (like document) you'd have about an identical number of vulnerabilities, and the exact same XSS vulnerabilities.
Furthermore, mishandled pointers arise directly out of a the design of the C language, for the about fifth time in this post: XSS does not arise out of the JavaScript language's design!
Microsoft's version of JavaScript is worse due to the insecure functionality (see [...]) added *by design*. People keep getting surprised by the nasty stuff that standards-conforming, but malicious JavaScript can do, from simple stuff like undying windows (JavaScript spawns a new window every time it detects the closing event) from taking over your desktop, including exploiting intranet applications (recent example: [...] ; original article at [...]).
I surmise from you comment that by "Microsoft's version of JavaScript" you don't mean JScript (which is what you should be referring to when you say that), but instead mean how Microsoft has embedded their JScript interpreter into the browser (once again: the hosting environment is not the same thing as the language!).
Outside of additional vulnerabilities added by a hosting environment, I can only think of two ways someone could do something malicious using JavaScript:
- Write a loop that doesn't terminate to bog down the end user's machine
- Write code that allocates lots and lots of memory (which, unlike in say, C, can't be done directly)
(Count an endless recursion example to be sort of a combination of both of these)
It's not surprising to me -- hostile code is much more powerful than hostile data (see below).
I won't disagree that "hostile code is more powerful than hostile data" but the problem here isn't hostile code; it's exploitable host objects.
You also don't understand how much more difficult it is to process hostile code than hostile data. You point out vulnerabilities in handling data as proof that there are other dangers. Given these, and how much more difficult it is to safely handle code than data, you should agree that it is reasonable to highly distrust a browser's handling of JavaScript. The more ignorant people are, the quicker they are to mock people pointing out security issues.
(Ignoring your ad-hominem non-arguments...) I drive my car on a pretty much daily basis. Cars are dangerous. But, the benefit I get from using my car is enormous. I don't deny there are serious security risks with using a modern web-browser — both when JavaScript is enabled and even when it's disabled. But I'm not going to stop using a web browser or all of "Web 2.0" because there are vulnerabilities; because, just like using my car, the benefits of a JavaScript enabled browser, for me, vastly outweigh the risks.
What I really want to stress though is that your thread title, "Javascript means no dice" is absolutely specious. There is nothing (or to be safe, let me say, very little) inherently insecure about the JavaScript language.
If you want to tell people you won't use "Web 2.0" because you don't trust how available modern browsers have set up their hosting environment for JavaScript, that's a perfectly rational and understandable argument; but "Uses JavaScript = Insecure!" is not and "XSS vulnerabilities are inherent in the JavaScript language" is even worse (and even more wrong)!