Leaky Sand Boxes
The Real Dangers
The best known of these other issues is Cross Site Scripting (often called XSS). The idea here is that an attacker injects JS code into a site which then effectively phones home to the attacker with users personal data when they visit the infected site. This is a potential issue on any site where users can add their own content. In the Web2.0 world that’s effectively every site. All blogs, all bulletin boards, YouTube, MySpace, Bebo …. the list is endless. The only way to protect against XSS attacks is for the site itself to properly validate all inputs and remove any nasty JS that an attacker may try to insert. This is completely outside of your control, you simply have to have faith that the developers who wrote the site knew what they were doing. Bottom line, if you have JS turned on in your browser you are powerless to protect yourself from XSS vulnerabilities and it leaves your personal data vulnerable. (you can learn more about XSS vulnerabilities here)
There are other dangers too, and probably more that will be found in the future. One that particularly scared me is the JS portscanner developed by SPI Labs as a proof of concept. I decided to check this out for myself so I ran the proof-of-concept and was very disturbed by the amount of information it picked up about my private network. Generally everything that is behind a NAT router (like the vast vast majority of broadband routers out there) is completely hidden from the internet and hence genuinely private. People take this for granted yet this proof of concept allows a server out on the internet to penetrate your private LAN using your web browser as an intermediary. You can try it for yourself here.
The most important thing to note about this scanner is that it does not exploit any vulnerabilities, it uses only official spec JS feature. No browser patch can protect you from this. If you browse the web with JS turned on your browser can be used to penetrate your private network and share what ever information it finds with the author of any malicious code you browser to! If you’re wondering if this really is dangerous then allow me to give you two scenarios as a demonstration.
Scenario 1 – The Home User
Imagine the following, you got a new router and you just plugged it in. Everything worked so you didn’t bother messing with the settings. Had you read the manual you would have known that your router comes with a default password which you should change. But since you didn’t read it and everything worked you left it at that. You also have an old Windows machine lying around and you know it’s a not up-to-date with Windows updates but since it’s in your home network and protected from the nasty people on the internet by your NAT router you don’t really care.
You get an email from a friend with a link to a cool Flash game. It’s a very addictive game so you stay on that page for a long time. What you don’t know is that the page has been scanning your network using JS while you were playing. It has found your router, tried the default password for your model of router, and gotten in and re-configured it so that the management interface now also listens on the WAN (Internet) side of your router. This allows anyone on the net to access the interface. The JS has now phoned home with the IP address of your router and left a message for the attacker. The attacker has picked up the message, logged into your router, opened up some ports and successfully attacked your un-patched Windows machine which is now acting as a web server for pirated music and emailing out spam by the gallon. All this happened while you were happily playing your game. You won’t notice any of it till next week when a nasty letter from the RIAA’s lawyers will land on your doorstep.
This is just one example of how allowing attackers to see into your private network leaves you exposed. Without JS in the loop no outside attacker could have gotten at your router’s interface so the whole chain of events could not have unfolded. People set up their network based on the assumption that everything behind their router is truly private. That assumption is nullified if you browse the web with Java Script turned on.
Scenario 2 – The corporate user
You are the IT manager at a company. Like many companies you have deployed an internal web server where private documents that your employees need access to can be stored. You’ve done things well. Your corporate firewall stops all traffic coming in to your network and only allows outgoing traffic via proxy servers. You’re also running a NAT router so all your employees are using private IP addresses and you’ve set up your internal web server with a private IP. You are confident that your companies precious secrets are safe and only accessible from within your private network.
You sit down at your desk one Monday morning and open an email from a colleague. It has a link to a cool flash game. You follow the link, and since it’s a good game, you waste an hour playing it. You don’t notice that while you’re enjoying the game your browser is off scanning your private network looking for web servers. After 15 minutes it has found the private web server where you’re keeping your secret documents. Your browser then spends the next 45 minutes passing all the data it can find on your server out to the person who put up the flash game. You don’t think anymore about this till you get a phone call a few days later. A shady sounding person is on the other end of the phone and wants to know how much you’ll pay him not to pass on your confidential data to your rivals.
Again, this is just one example of how JS could be used to cause real trouble in a business. By allowing an attacker into your supposedly private network via JS on your web browser you are providing attackers with a potential back door around your security. You think you’ve just letting people browse the web but in reality you are also letting attackers enter your private network via your employees web browsers.
So what does this mean for the average web user? It means that if you care about your safety on the web you should only run JS on trusted sites. Then it just comes down to using common-sense and only enabling JS on sites that need it and that you trust. If you do that you should be safe to continue experiencing the web to it’s fullest.
If people start doing this there will be a knock-on effect on web developers though. It will mean not being able to develop with the assumption that everyone visiting your site will have JS enabled. You will have to write your site in such a way that it works without JS. Sure, you can make it work better with JS but you will still need to make it functional for visitors with JS turned off. If you are running a website selling a product or service you will not want to drive away potential customers just because they are browsing the web in a security conscious way!
I think it will take a few more high-profile JS problems like the MySpace worm before regular users will start to worry about JS, but I believe it will happen, it’s just a matter of time.