"Secondly, I can't take your rant seriously. At all. "
That's because you don't understand cross-site scripting vulnerabilities. At all.
Even if you made a perfect browser without vulnerabilities that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, 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); 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. Microsoft's version of JavaScript is worse due to the insecure functionality (see http://www.quirksmode.org/js/intro.html) 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: http://www.phoneboy.com/node/6 ; original article at http://www.spidynamics.com/spilabs/education/artic les/JS-portscan.html). It's not surprising to me -- hostile code is much more powerful than hostile data (see below).
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.
When a javascript trojan is able to modify any of the registry keys or install new ones, I call that a boiler explosion. Whenever a worm or spyware installs itself through javascript, I call that a boiler explosion. Lookup the national vulnerability database (nvd.nist.gov); as of today there are 345 entries related to Javascript. Of course most vulnerabilities are not "boiler explosion" level but there are lots of malware (including spyware) that installs itself through Javascript issues; few vulnerabilities are needed for a host of malware to prosper. Client-side scripting in general is a huge security headache. It's like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link while you have scripting enabled. I don't like to play russian roulette. You may think that you know a web 2.0 app, so it's safer, but there are two issues: one is that it's a pain to manage javascript permissions on a site-by-site basis (the noscript firefox extension helps a little here, but it's far from perfect) so once you force someone to turn on Javascript, it's on for all sites, and second, your app itself can become a vector for attacks through XSS vulnerabilities. People tend to dismiss XSS vulnerabilities but it's a mistake, as a single one may allow an attacker to exploit a more serious issue. The NVD bears testimony on how hard it is for the average coder to write a web application without any XSS vulnerability. Web 2.0 apps aren't an exception.
As long as these "web 2.0" apps rely on Javascript, they can't be trusted because Javascript is an exploit vector and a security headache. As far as I'm concerned, I'd prefer if Javascript didn't exist. Either a real security framework for Javascript needs to be invented (with access control policies), or Java needs to somehow be made as appealing as Javascript while remaining reasonably safe, or a new browser scripting language invented. The current situation with Javascript resembles the beginning of steam power, with boiler explosions. It's just unsafe.
Please have a look at the free Cassandra system: https://cassandra.cerias.purdue.edu
You can create any number of profiles, and you get emails daily about new CVE entries in ICAT (icat.nist.gov) or Secunia advisories (Secunia) that relate to the software or keywords you select.
You can use the freeware KeyAudit to scan your systems:
Windows KeyAudit: http://www.sassafras.com/restricted/keyaudit/keyau dit.exe
Mac KeyAudit: http://www.sassafras.com/restricted/keyaudit/keyau dit.sit
Sassafras just stopped maintaining KeyAudit, so I'm looking for an alternative application scanner to replace KeyAudit, as well as a Linux/UNIX equivalent (I'm the author of Cassandra).
I'm aware that it's not perfect, and the html and presentations are rather basic. However, it's free, it has been working for a few years now, and I'm listening for suggestions and open to criticism. I'll try to improve it as time allows.
Cheers
Pascal Meunier
Slashdot Mirror
"Secondly, I can't take your rant seriously. At all. " That's because you don't understand cross-site scripting vulnerabilities. At all. Even if you made a perfect browser without vulnerabilities that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, 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); 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. Microsoft's version of JavaScript is worse due to the insecure functionality (see http://www.quirksmode.org/js/intro.html) 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: http://www.phoneboy.com/node/6 ; original article at http://www.spidynamics.com/spilabs/education/artic les/JS-portscan.html). It's not surprising to me -- hostile code is much more powerful than hostile data (see below).
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.
When a javascript trojan is able to modify any of the registry keys or install new ones, I call that a boiler explosion. Whenever a worm or spyware installs itself through javascript, I call that a boiler explosion. Lookup the national vulnerability database (nvd.nist.gov); as of today there are 345 entries related to Javascript. Of course most vulnerabilities are not "boiler explosion" level but there are lots of malware (including spyware) that installs itself through Javascript issues; few vulnerabilities are needed for a host of malware to prosper. Client-side scripting in general is a huge security headache. It's like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link while you have scripting enabled. I don't like to play russian roulette. You may think that you know a web 2.0 app, so it's safer, but there are two issues: one is that it's a pain to manage javascript permissions on a site-by-site basis (the noscript firefox extension helps a little here, but it's far from perfect) so once you force someone to turn on Javascript, it's on for all sites, and second, your app itself can become a vector for attacks through XSS vulnerabilities. People tend to dismiss XSS vulnerabilities but it's a mistake, as a single one may allow an attacker to exploit a more serious issue. The NVD bears testimony on how hard it is for the average coder to write a web application without any XSS vulnerability. Web 2.0 apps aren't an exception.
As long as these "web 2.0" apps rely on Javascript, they can't be trusted because Javascript is an exploit vector and a security headache. As far as I'm concerned, I'd prefer if Javascript didn't exist. Either a real security framework for Javascript needs to be invented (with access control policies), or Java needs to somehow be made as appealing as Javascript while remaining reasonably safe, or a new browser scripting language invented. The current situation with Javascript resembles the beginning of steam power, with boiler explosions. It's just unsafe.
Why can't they do this with a nice little laser printer (Mac compatible)? I'd buy *that*.
Now we just need to get gopher-enabled email clients!
Please have a look at the free Cassandra system:u dit.exeu dit.sit
https://cassandra.cerias.purdue.edu
You can create any number of profiles, and you get emails daily about new CVE entries in ICAT (icat.nist.gov) or Secunia advisories (Secunia) that relate to the software or keywords you select.
You can use the freeware KeyAudit to scan your systems:
Windows KeyAudit: http://www.sassafras.com/restricted/keyaudit/keya
Mac KeyAudit: http://www.sassafras.com/restricted/keyaudit/keya
Sassafras just stopped maintaining KeyAudit, so I'm looking for an alternative application scanner to replace KeyAudit, as well as a Linux/UNIX equivalent (I'm the author of Cassandra).
I'm aware that it's not perfect, and the html and presentations are rather basic. However, it's free, it has been working for a few years now, and I'm listening for suggestions and open to criticism. I'll try to improve it as time allows.
Cheers
Pascal Meunier