My main topic will be this blog post http://www.jgc.org/blog/2009/09/javascript-must-die.html which was featured in grc.com's latest SecurityNOW! podcast/radioshow (i usually stick to the PDFs for it).
I read through the radioshow where John Graham Cumming and the 2 from GRC were talking about how javascript's security is horrid and needs to be fixed now. John was the one with the idea and most of his talk was about how dynamic ad providers' in-line javascript is very dangerous because of the way that all javascript can access all other javascript in any web page, and there is currently no way to protect against it.
Well to me this just shows how truly incompetent these "security research" firms really are. John, the one that did the "thesis" on this problem, does not even refer to himself as an expert, and did not even seem to realize that javascript actually CANNOT access all other javascript in a page, unless the variables are defined globally outside of a function. It was another researcher who told him this. Yet he made a presentation at the Virus Bulletin Conference in Geneva, I guess it's a big deal.
Anyway, most of his talk about how you should use noscript in firefox or just disable javascript entirely sounds like the paranoid ramblings of a middle-aged IT office worker who knows little to nothing about security and is the type of person who would turn off their modem at night for fear that virii might infect them while their computer is turned off.
First i will look past the fact that many of his ideas are based on website admins' continued usage of dynamic ad providers and tracking websites, which are a bad idea in the first place, if you can't get enough traffic to actually sell adspace, putting in these providers' ads are not going to get you enough revenue to offset the security holes they open up.
He talks about how there is no way to track if the javascript has been modified at the other end. this is simply not true. If anyone who is running a website is using any sort of server-side scripting language (php, cgi, .net, asp) there is actually a very simple way of tracking and checking the javascript that is provided by these companies, you need only put a function AFTER the inline script tag that can simply do a quick message digest of the script to verify if it has been changed, and if it has, remove it from the HTML before it gets a chance to be run.
You could even go so far as to put the in-line script tag INSIDE a php function so that if the URL that holds the javascript does not return as OK, it is never even inserted.
The next point he wants to make is that perhaps we should put the links through an SSL session so that if the domain is modified or the code changed, an invalid certificate will pop-up, well that puts the security load on the end-user to do the checks, and even your average college IT graduate might not be able to tell the difference between a properly forged certificate and a good one, that's just not a good plan.
I usually hear people scream SSL/HTTPS as a fix-all for security only when they do not know what they are talking about. But instead of all that malarky, just do as above, as any site admin should be able to, and if not, then don't put in ads.
Then he goes on to talk about how all javascript can access other javascript. If you have ever read the javascript bible or i'm sure any intro to javascript, they will tell you that this is only true of the global variables that the DEVELOPER creates. So when you see these in-line site addon scripts that have the variables listed inside a <script> tag, those can be modified by an XSS attack very quickly and easily, but if they are put inside a function (which you can even do and still get the same functionality as you would otherwise) then they are no longer accessible by other functions (unless they are attacking your site directly and have studied your code)
personally i'll stick to reading, researching and learning on my own before i trust other researchers, i have to be honest i had high hopes for grc's security now, but after that reading and the fact that the two from the site didn't have a clue as to the other side of the argument, or the fact that most of John's "ideas" were just plain not true except in certain contexts, just confirms my belief that most security "researchers" are nothing more than pseudo-intellectual copy pasters in a search for fame.
Now my question for the darksiders is this......do you trust these "good guys" that seem to only be in the security industry for money and fame? or will you put your trust in yourselves, maybe learn a thing or two, and make up your own damn mind (to quote the oracle from matrix of course) before you worry about anything?
P.S. i just had a look at his presentation, which can be found on his blog post (i didn't take the time to look before i read the security now posting) and most of his exploit examples are first and foremost, not his work. second, the blame of these "javascript exploits" are not on the javascript security model or the designers of javascripts shoulders, but on the site developers shoulders:
1) Twitter should watch URLs,
2) myspace....well it's myspace.
3) If you are giving your <script> tag an ID, you deserve to have it modified. end of story.
4) A security hole in the implementation of a javascript engine is not the fault of the language of javascript, but that of the developers of the browser.
5) A security hole in a router is not the fault of javascript. and you can't fix javascript to fix that hole, someone will just craft a link to do the work. (bthomehub)
6) portscanning using javascript just shows ingenuity, not a lack of security, you can't make a language that is used on the internet NOT use the internet
7) DNS attacks (namely the wone kaminsky talked about) are not as prevalent or dangerous as most of these "researchers" think, and are not a problem with javascript, it would take 1000s of tries before you even poison a DNS to only hold on to it for a few minutes anyway, and if you do that, it would be far smarter for the attacker to direct the user to a crafty php/javascript page than to try and get them from a modified ad-script.
near the end he just got off topic and didn't even cover the real low-level security of javascript and it's problems, javascript was never meant to be server-side, it is a user level language, which is why it is secured at the user level and not at the server level, if you can't protect your server it is YOUR fault, not javascripts.
