Far back in the days of GeoCities and Tripod, JavaScript was a cool little scripting language you could use to make some awesome rollovers on your links and take your site to the next level beyond the blink tag. Today, JavaScript drives what many call Web 2.0 – a user experience that has made it possible to put desktop applications (email, office) on the web.

The evolution of JavaScript and its place in security perfectly parallels the transition from server-side security to client-side security.

~History~

Before network firewalls were commonplace, the juiciest targets to go after were servers. In what is now unthinkable, it was common for systems to be deployed directly on the Internet with no firewall whatsoever. This is part of the reason that Code Red, Nimda, and Slammer were so successful. The opposite is true now. Network firewalls are commonplace, Windows XP has the firewall turned on by default, and Server 2008 will be the first Microsoft Server OS to be deployed with the firewall enabled by default. As such, attackers moved on to the next target – client workstations and the primary way users interact on them.

~/History~

So why should you, as a startup, care about all this? Two reasons.

  1. Protect your site from common attacks
  2. Protect yourself from being a victim

To address the first one, there’s a common attack known as Cross-Site Request Forgery. I’ll get into it in more detail in another post, but effectively it allows one site to take action on another if that target site has not put effective controls in place. A common mitigation is ensuring that all data modification methods occur via POST requests (per HTTP standard). However, if you don’t have tokens associated with those POST requests, another site could utilize javascript to craft and submit fake POST requests to take actions on a logged-in users behalf. Does your site have a “remember me” checkbox? Do user sessions not time out? This could be a problem for you. This issue has been widely known for at least four years (Chris Shiflett on CSRF), but it’s only recently been gaining a lot of attention. I’m surprised more frameworks don’t have protection for this enabled by default, but it could likely impact development testing. The general approach to fixing this is by utilizing some sort of server-generated token that’s inserted as a hidden form field and verified on user submittal.

To address the second, an example is necessary. JavaScript, for the most part, is fairly essential to a number of sites that you may visit on a regular basis. The danger however, is malicious JavaScript that may get executed without you even knowing it. That script could be on that site and trying to take action on a different site, or sourced from a remote site altogether. Take, for example, poor David Airey who lost his domain due to a GMail CSRF vulnerability. The basics behind the attack are as such: At one point, David visited a page that had a malicious JavaScript. That script posted back to his GMail account, reconfiguring it so the attacker could hijack emails. That reconfiguration including forwarding and deleting all domain-related emails. Once David went on vacation, the attacker went to work and David lost his domain.

So how can you protect against this second attack? I personally make use of the Firefox extension NoScript. This handy extension prevents JavaScript code from automatically executing when you visit a web page, unless you’ve previously whitelisted that site. While it can be a little annoying, it’s much better than unknown JavaScript executing in the context of my browsers…where I spend a good majority of my day.