JavaScript Injection Attacks

Don't Get Pinched by JavaScript Injection Attacks

Don't Get Pinched by JavaScript Injection Attacks

A little over a week ago, I described Cross-Site Request Forgery attacks and how they can damage your site with just a simple website request using any modern browser available today. This time, I’ll describe another type of JavaScript attack that can cause equal harm to your site.

Lots of sites, including blogs, accept user input. Visitor are invited to enter values into fields and click a button to submit the web form. This might be a simple as leaving a comment on a blog or purchasing a t-shirt with a stolen design.

The fundamental rule in website development is to NEVER TRUST USER INPUT. To say that another way, you should always assume the data on a web form is intended to harm your site. The bad guys have some clever ways of doing this with a plain ordinary browser; they don’t need elaborate tools to try this type of attack. Furthermore, you only need to fail in one spot on your website and you’re done. The shared computer at the local coffee shop will do just fine for their attack vehicle.

Let’s take a look at a simple blog comment. Imagine that your blog contains a form that takes a name and a comment. You’re expecting visitors to enter a value in both fields and click a button. You might even implement some validation to make sure that both fields have a value before the form can be posted.

Now let us put the fundamental rule described above into play: You should never trust user input. While the form will warn the user when the field is missing, visitors can still enter gibberish and there’s little you can do to stop them. It’s a web form, they’re on the website you gave them, and that’s why you moderate comments on a blog. While it’s healthy to see comments from people who agree and disagree with you, you still try to keep the signal-to-noise ratio at a reasonable level.

JavaScript injection attacks are one of the primary reasons should never trust user input. Let’s suppose the blog saves the web form fields to a database. When subsequent visitors request the blog page, all of the comments are shown in chronological order under the blog post. Pretty typical so far, right?

Herein lies the rub: suppose instead of a comment, our nefarious visitor entered the following JavaScript:

<script>alert('hello world');</script>

Everyone who visits the blog page containing the previous JavaScript is going to see a message box that say’s “Hello World”. This is an example of one of the most dangerous attacks on the web today. The attack is easy to try and you only need to miss one place on your entire web site to be vulnerable.

helloworld

If a visitor is able to get your web page to execute the their JavaScript, they can do some really bad stuff. For example, they could write a JavaScript that let’s them impersonate you and perform every task you can do on the website. All you need to do is visit the page (on your own website) that contains their JavaScript. You’re likely to read the comments on your blog, so that part is fairly easy, right?

Here’s how they do it: After you sign in, lots of web sites will issue a temporary token to you in the form of a cookie. Your browser sends this cookie along with each page request in order to validate who you are. If you close your browser, you might have to sign in again and get a new cookie. Alternatively, the website might have issued a more durable cookie. In this case, the website might have instructed the browser to store the cookie for several days. This is how Google keeps you signed in for several days.

Since JavaScript has access to cookies, the JavaScript written by the bad guys can be written in such a way that it sends your cookie to their website. They’ll be waiting for cookies to come in and looking for a juicy one that has a lot of authorization. Once they have it, there’s nothing much you can do, short of turning off the web server. They own your site. Furthermore, there’s no email notification of this event. You won’t know about it.

Scary stuff huh?

You need to protect your site from these types of attacks. The best practice is to process every byte from a visitor. You should never show raw content provided by an untrusted user. In this case, untrusted users are everyone but you. Since your at it, why not protect the site from yourself too, just to be sure.

One way of implementing this best practice is to encode fields before they are displayed on the web page. Encoding text will convert turn a “<” character into to safer eqivalent of “&lt;”. The JavaScript example above will appear like this:

&lt;script&gt;alert('hello world');&lt;/script&gt;

This encoded JavaScript will not execute in the browser. If you’re aware of the potential danger here, you’ll delete the comment immediately and review your website for holes. Again, you only have to forget to plug one hole and they’ve got you.

JavaScript injection attacks are a nasty threat to any website that accepts input from visitors. The bad guys already know this, so training the good guys is how we’re going to plug these holes. No doubt they’ll come up with more clever ways of bring down you’re site, so keep you’re skills up to date and spread the knowledge.


2 Comments on JavaScript Injection Attacks

  1. <script>alert(‘OMG’);<script>

  2. <script>alert(‘hello world’);</script>