Why I block Javascript.

This subject surfaces from time to time, especially when I’m conversing with the bleeding-edge web design community. “You do WHAT?” followed by a lot of strange looks and laughter is the typical reaction. Then I’m told all about how JavaScript has been “modernized” and “browsers are sandboxed” and other nice things.

I run a variety of browsers; the current desktop has Firefox (with NoScript); Chrome; IE 4; IE 6; IE 8; and Lynx. Most of the time I browse with Firefox/NoScript. Yep, it slows me down, and there’s the minor annoyance of having to set temporary JavaScript execution privileges. This post will attempt to explain why I do things the way I do. Standard disclaimers apply.

First two-word explanation: Zeus Trojan.

The Zeus Trojan is a password-stealer which is usually deployed via JavaScript malware which was introduced to the victim by way of an infected website. As JavaScript has “matured” it also allows for much-improved obfuscation and cross-linking and all sorts of nice ways to operate an attack vector dynamically (to the point where most Zeus variants check location data and refuse to infect systems in certain countries).

For US-based small business (and local government) there is no protective cap on money stolen via identity fraud – and this is the standard use of Zeus. Once the credentials are acquired the thieves can empty a bank account in a matter of hours – and there is no legal recourse against the bank. The money is gone; the victim is not going to get it back.

A part of my professional practice deals with security – no, I’m not going to enter a forum with all the scripts executing. I only look foolish.

…and as I’m writing this post, in over the transom flies this notice – Google has awarded $60,000 as a prize in the Pwnium competition, for a method to overcome Chrome’s “sandbox” feature and run code on a fully-patched Window 7 system. All that is necessary is for someone to browse to an infected website – viewing the page is sufficient to load and execute the payload. A little bit of JavaScript acts as an enabler – there’s no need to bother with an exploit attempt if the browser is something else.

Another reason not to automatically run JavaScript is a common Facebook malware attack – the click-jacking survey scams which pop up several times a day. Click-jacking is a specialized attack vector on Facebook which work by having the victim click on a link – which leads to a survey – and also “spams” the link as a status post from the victim. If you run with JavaScript enabled you’re usually taken straight over to the payload page – which is typically a survey… but it might be something worse.

By not running JavaScript I get stuck on the interstitial dispatch page; this is where the Facebook click-jack link leads; and this page contains various JavaScript functions to identify the victim. Typical contents of these pages include a bit of geolocation which is used to decide which survey to play. From time to time, I see ones where the dispatch code includes a mechanism to reject the entry if location appears to be in .ru, .ua, .by or .ge  – authorities in these countries only track cybercrime if local users are affected. Generally speaking, if the interstitial page contains the ru-ua-by-ge code, the payload page is loading something other than a simple survey.

But security isn’t the only reason to avoid JavaScript.

Second two-word answer: Existing Investment.

This probably comes as a shock to many web designers – but companies don’t rush right out and buy the latest technology just because it got a great writeup on reddit or slashdot or wherever, or even if it’s the best seller on Amazon or the Apple store. There are a lot of systems out there with no capacity to execute JavaScript (embedded devices) or where internal policies discourage its use. I’ve been writing web-apps for more than a decade which require no JavaScript or even cookies on the browser in order to maintain state… and I know that some of these clients are not going to change those devices or policies for at least several years. Have you discarded your car simply because its OBDC works at a glacial 1200 bits/sec on a serial port?

Not executing JavaScript allows me to see how these clients perceive the “outside world” and thus better understand their mindset. It is very interesting to see which major companies’ websites are still functional without JavaScript (although not all the bells and whistles may work).

Advertisements

4 thoughts on “Why I block Javascript.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s