A couple of months back I wrote two articles singing JavaScript’s praises from a programmer’s point of view (JavaScript – Much more than Java’s Mini-Me & Hidden JavaScript). In the last one I hinted that there would be a follow-on article showing a darker side to JS. This is that article, just a few months later than I’d planned. Unlike the previous two articles this one is not really aimed at programmers, it’s aimed at anyone who surfs the web.

JavaScript (JS) can be used to really enhance usability on the web. We all like having drag and drop capability on the web, we like the way AJAX lets pages only refresh the bits that need to change instead of whole pages, and we even like those cool JS transitions and graphic effects. A lot of people refer to these things as Web2.0, but I’m not going to. I prefer to think of Web2.0 as being about community involvement rather than any particular technology. It’s a frame of mind not a software version! You can have Web2.0 without JS or AJAX. The key point is that we are all getting used to the enhancements JS can bring to the web environment. But there is a cloud on the horizon and it is growing.

The sometimes controversial security expert Steve Gibson has been warning us about the dangers of browsing with JS turned on for years now. In the beginning people ridiculed him, but his views are gaining more and more acceptance as the dangers start to become real rather than theoretical. I think the recent MySpace JS worm and the release of proof-of-concept code for a JS port-scanner by SPI Labs have really started to focus people’s minds on the dangers of JavaScript.

[tags]JavaScript, JS, XSS, Security[/tags]

Leaky Sand Boxes

Since this is not an article for programmers I’m not going to go into detail on what JS does or how it works. I just want to draw your attention to one key point. JavaScript is code that is delivered to your computer when you visit a web page that then runs on your computer. When you have JS enabled on your browser and you visit a web page that page can send your computer code which it then executes. This is inherently dangerous and would be totally suicidal if there were no limits on what JavaScript can do. To protect you JavaScript runs inside what techies call a ‘sand box’. The sandbox limits what JS can do and in theory confines it’s realm of influence to the browser. This is perfect in theory, but if there is a problem with the sandbox JS can break out and do real damage. This has happened before and it will happen again. Your only chance of protecting yourself is to keep your browser up-to-date. This is a little scary but not really a show-stopper. However, there are other security problems with JavaScript which are much much scarier because there is nothing you can do to protect yourself short of disabling JS, they are completely out of your control!

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

Most network devices these days have web-based interfaces for convenience. Every home broadband router I haver ever seen does, most NAS boxes do as do many printers and Wireless Access Points. This is generally not a problem because these web interfaces are only visible from within your home network and not from the web at large. However, as this scanner shows, your private network is no logner private if you browse the Internet with JavaScript turned on.

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 Is This the End of JavaScript?

At first glance you might think all this should be sounding the death knell for JS and AJAX. The dangers are very real after all! There is one very obvious defense against XSS and JS LAN scanning, turn off JavaScript. This means no AJAX goodness, no fancy transitions and no drag and drop anymore. If you want 100% security then this would be your only option. However, even Steve Gibson considers this an over-reaction. The solution is to switch off JS except when you are visiting a site you trust. In Internet Explorer you can do this with internet zones. You turn off JS in the regular internet zone, turn it on in your trusted zone, and then add all the sites you trust to that zone. FireFox doesn’t have zones but there is an excellent plugin available to give you the same sort of opt-in setup.

Conclusions

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.