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.

• Search Forms

  Search forms generally re-display the search term entered by the user. These terms are quite frequently not properly encoded, either, leading to Cross-Site Scripting (XSS) attacks.

• Jobs and Events

  Jobs and Events pages frequently utilize a database behind the scenes to manage job postings and event listings. Further, they’re usually pretty easy to check as they have the job or event id in the URL for page rank, etc. I’ll commonly look for these for easy injection vectors.

• Cookies

  Utilizing the fantastic Web Dev extension, I’ll take a quick look at the cookies. If I see anything more than a session ID, I’ll start modifying and manipulating the cookies to verify that server-side checks are in place. Cookies can also frequently lead to XSS.

• Hidden Form Fields

  If there’s a contact page with a form, the first thing I do is look for hidden form fields to see what parameters the web developers might have thought that a user wouldn’t see by putting them in a “hidden” field. I’ve come across everything from spam gateways to arbitrary file access due to simple issues like this.

• Typical Directory Structures

  Finally, I’ll commonly poke around in typical directory structures to see if I get lucky. Things like /admin/, /logs/, and /config/, among others, often are not intended for public consumption or linked to, but are present on the site.

There you go – those are generally the first places I look if I need to take a quick look at a web site. Beyond that, I start digging into more complex input locations within the application, logic happening behind the scenes, and potential user authorization issues.

As App Engine does not automatically escape output, you need to do this yourself.

As an example, here’s a very simple snippet:
Welcome, {{ firstname }}!

If “firstname” is not properly sanitized when stored in the database or escaped on output, I could easily make my first name the following:
damon<script>alert('hi!')</script>

And then we would have stored JavaScript code execution, aka Cross-Site Scripting, as the <script> tag would get interpreted by the browser when echoed out.

The solution?

Simple, just |escape your output when coding in Google App Engine:
Welcome, {{ firstname|escape }}!

You can also sanitize data prior to storing it in the database, but as an additional layer it’s good to escape it on output as well.

I’m not sure if this is a derivative of the fact that GAE utilizes Django 0.9.7, but I guess we’ll see when they upgrade to Django 1.0 as it autoescapes all output by default (thank you, Django!).