Web Application Security, Part 1

Application-level web security is of increasing concern among web developers. This article outlines some types of security threats to your web application and how to solve those threats.

This is Part 1 of the Web Application Security article, geared toward the material covered in Module 2. For material covered in Module 3 (MySQL), see Web Application Security, Part 2. For material covered in Module 4 (JavaScript), see Web Application Security, Part 3.

Introduction to Application-Level Web Security

Every day, computer hackers around the world penetrate web applications, often for personal profits. You may find it hard to believe, but even high-profile web sites (banks, social media, even computer security companies) are vulnerable to application-level attacks!

Not only is it embarrassing to be the programmer who wrote the vulnerable code, but it could also cost you your job. As a prudent web developer, it is imperative that you take precautionary measures to make your application difficult to penetrate. Indeed, most of the time, if your site is well-written, hackers will just move on.

Here's the golden rule: Anything in your site that accepts user input, whether via a form, an AJAX request, a file upload, or even malformed links, can be used as an attack vector. NEVER TRUST USER INPUT!!! This can be summarized in the acronym FIEO, or Filter Input, Escape Output.

Cross-Site Request Forgery

A cross-site request forgery (CSRF, pronounced sea-surf) involves a victim, who is logged in to the targeted site, visiting an attacker’s site. The attacker has code on his site that forces the victim to unwittingly perform actions on the targeted site.

For example, suppose Mother Goose visited Dr. Evil's blog. Dr. Evil had the following tag embedded in his bloc:

<img src="http://www.bank.com/transfer.php?dest=dr-evil&amount=5000" />

This would cause Mother Goose to authorize a $5000 transfer to Dr. Evil, completely without Mother Goose's knowledge!

Worse yet, Dr. Evil could just send an e-mail to Mother Goose with this image tag. All Mother Goose would need to do to be attacked is open the e-mail! (Now you know why sometimes your e-mail client turns off images from suspicious sources.)

Solution

The first precautionary measure is to always use POST requests (as opposed to GET requests) for actions that change something on your server. This will fend off all except the most hard-core CSRF attacks.

However, fully preventing CSRF attacks is not difficult. To do this, you can use a CSRF token. A CSRF token is a known string of text that is submitted in all of the forms on your site. If the string is not what you expect, then you can assume that the request was forged.

For example, consider this form:

<form action="transfer.php">
<input type="text" name="dest" />
<input type="number" name="amount" />
<input type="submit" value="Transfer" />
</form>

We can easily add a hidden CSRF token field like so (as well as making the form POST rather than GET):

<form action="transfer.php" method="post">
<input type="text" name="dest" />
<input type="number" name="amount" />
<input type="hidden" name="token" value="<?=$_SESSION['token'];?>" />
<input type="submit" value="Transfer" />
</form>

This assumes that $_SESSION['token'] contains an alphanumeric string that was randomly generated upon session creation. We can now test for validity of the CSRF token on the server side (in transfer.php):

<?php
$destination_username = $_POST['dest'];
$amount = $_POST['amount'];
if($_SESSION['token'] !== $_POST['token']){
	die("Request forgery detected");
}
$mysqli->query(/* perform transfer */);
?>

Now, if Mother Goose were to view a page containing the malicious <img/> tag, the transfer would not take place.

Real-Life Examples

• Weibo (the Chinese Twitter), June 2011
• Gmail, June 2011
• Hotmail, May 2011
• Facebook, May 2010

Denial of Service

Denial of Service (DoS) is probably the most widely used attack vector to date, and the one employed by hacktivist groups like Anonymous. The concept is simple: flood a target server with more requests than it can possibly handle, resulting in server downtime.

A Distributed Denial of Service (DDoS) attack is a special kind of Denial of Service attack that involves multiple, unrelated machines sending requests to the server simultaneously. DDoS attacks are more powerful than "un-distributed" DoS attacks because there are dozens, hundreds, even thousands of machines, all with different IP addresses, all requesting data from your server at the same time; in DoS attacks, there is only one computer doing the attacking. Hacking groups are known to have millions of machines around the world ready to perform a DDoS attack on command. It's a very interesting topic to Google about, but beware that you might spend several hours reading web sites if you start!

There are two flavors that a DoS attack can take:

• Bandwidth-based: Saturate the connectivity link.
• Packet-based: Saturate the processing capability of the equipment.

Mitigating DoS Attacks

Unlike the other types of attacks we've discussed (or will soon be discussing), DoS attacks cannot usually be prevented by good coding practices. Here are some tips that should help:

• Always keep the most up-to-date software on your server and firmware on your router (if applicable).
• If you represent a firm with a lot of resources, anycast may be an option. Rather than having your site hosted in just one server, the load of your site will be shared between many different servers. Anycast systems are expensive, but they help fend off non-hardcore DoS attacks.
• You can set up a constellation of reverse proxy nodes. You might also benefit from using a web server like Nginx instead of Apache. For more information on constellation reverse proxy nodes, see: http://blog.unixy.net/2010/08/the-penultimate-guide-to-stopping-a-ddos-attack-a-new-approach/
• Limit things like file upload size and CGI scripts. These are known to be easy targets for DoS attacks.

In short, DoS attacks are not pretty, and there's not any sure-fire way to prevent them. Just do your best and hope that you don't get attacked by DoS.

Real-Life Examples

• Indian CERT, May 2012 (DDoS)
• Chicago Police Department, May 2012 (DDoS)
• Pirate Bay, May 2012 (DDoS)

Packet Sniffing

HTTP Packet Sniffing is a fundamental web attack that has been known for a long time, but it was never widely exploited. Essentially, the attacker can listen on his current WiFi connection for packets going in and out, then either act as a "man in the middle" to either perpetuate a Content Spoofing attack or just hijack the victim's session. (This is when user agent testing would prove helpful.) The Firesheep plugin for Firefox makes it easy to perform Packet Sniffing attacks yourself: just go to Starbuck's, open up Firesheep, and you can hijack anyone's session who is on the same public WiFi. Scary.

Solution

The best and easiest way to prevent packet sniffing is to secure your site with an SSL certificate (https). This will cause each request to perform handshakes, preventing Man-in-the-Middle attacks. Unfortunately, SSL certificates are not free; you can expect to pay around $100 per year for a small web site. Because of the handshakes, they also consume slightly more resources. However, if your site controls sensitive data from users (e.g. credit card information), an SSL certificate is a must.

Real-Life Examples

Any web site that does not use the HTTPS protocol is vulnerable to packet sniffing attacks. After the release of applications like Faceniff and Firesheep, high-profile sites have switched to using the HTTPS protocol by default:

• Gmail, January 2010
• Facebook, January 2011
• Twitter, March 2011

Server Configurations

Sometimes hackers attempt to penetrate your application from the server side rather than the application side. Server-side security is beyond the realm of this course, but here are some things you should keep in mind.

• Use a highly secure root password, and it should be one that you don't use anywhere else. Seriously.
• Use a firewall system to block unnecessary ports from public access. SSH and Web Server should really be the only ports you need. You should keep the web serve on port 80, but you have the option of moving SSH to a port other than 22 to make it slightly more secure.

Real-Life Examples

• Independence Hall Tea Party PAC, May 2012 (their root password was "p9ssw0rd")

TODO: Get video from http://fileice.net/download.php?file=r426