Why you can't just disable JavaScript

Web Browser Security

Article from Issue 101/2009

As ugly and hard to secure as JavaScript is, it could be worse – we could be using ActiveX.

JavaScript – can't live with it, can't live without it. The modern web is amazing; I can pay my bills, buy a laptop, and order hot pizza all from my web browser. To do all these activities, I must have a web browser with JavaScript enabled. If I disable it, I can't read my email, pay my bills, buy anything, or view approximately half the websites on the planet. But if I enable JavaScript, the bad guys can:

  • track who I am with tracking code, such as Google Analytics;
  • exploit security vulnerabilities in Firefox (120+ and still going);
  • redirect me to hostile websites; and
  • hijack actions, such as keyboard and mouse clicks.

Did I just say 120+ security vulnerabilities in Firefox that are exploitable via JavaScript? Yup. And that's not counting the ones that haven't been officially categorized or fixed yet. A perfect example of one of these is CVE-2009-0253; using the onmouseover action to position a 2 by 2 pixel box over a clickable link, an attacker can redirect you to an arbitrary website [1]. Any mouse click event (i.e., clicking on what looks like a legitimate link, image, etc.) over a link results in an onmouseover event that redirects you to, well, wherever the attacker wants:

<div id="mydiv"
function updatebox(evt) {

With this exploit code (and Firefox 3.0.5), when you mouse over the link, the status bar will show the link in the web page (because the link itself hasn't been modified in any way), but this is not the link you will be taken to if you click on it.

Hard to Secure

In a nutshell, JavaScript is a Turing complete language, which means it can accomplish pretty much any calculation you can imagine. Add to this a huge standard library of methods that can interact with the web browser (such as onmouseover) in potentially unexpected ways and you have a recipe for disaster. Attackers can also use tricks, such as placing the JavaScript code in a file hosted on another web server and then calling it with the document.write method to load the file remotely. Again, this is a legitimate feature that can be heavily abused by attackers.

On the side of good, you have sites such as Google. If you want to use their web Analytics or ad serving, you simply place a small snippet of JavaScript code into your pages, which in turn calls much larger JavaScript programs from Google's websites. Advantages include the ability of clients to cache the JavaScript because it all comes from the same URL (meaning pages load faster), Google can update their JavaScript programs centrally, people using it don't have to update their web pages, and so on. The downside is that attackers can include JavaScript in web pages and serve it from remote locations. Depending on the document.referrer, document.location, and location.href variables, they can serve custom code for each site or no code at all. Thus, if you try to copy and examine the hostile web page in a sandbox, the hostile code isn't loaded, or a harmless version is sent.

Turn It Off

I hope you don't like online banking, shopping, or any "Web 2.0" sites, including Gmail, Facebook, or StackOverflow.

Turn It On, Selectively

Not a bad idea. The use of add-ons for Firefox, such as NoScript [2], makes this a relatively painless experience (at least once you get all the common sites you use white-listed). After you install NoScript, when you go to a page that tries to load JavaScript (either from its own server or from a remote server) you will get a warning in the bottom right of your web browser (Figure 1). When this happens, you can click on the Options button and allow that site to load scripts temporarily (until you restart Firefox) or forever, or you can block them entirely (Figure 2).

Figure 1: This shows the NoScript warning when JavaScript tries to run.
Figure 2: The NoScript options panel allows you to determine how scripts are loaded.

However, you can't selectively allow certain scripts within a domain and block others very easily. If an attacker manages to conduct a cross-site scripting attack against a site you trust, such as your bank, they will be able to execute their hostile JavaScript on your machine with no warnings.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More