Why is it important to sanitize user input?

If you’re not careful with user input your website might be open to code injection, directory traversal or similar attacks. Information supplied by users can never be assumed safe.

Examples of user input are submitted forms (e.g. comments), URL parameters (?q=example) and server-side scripts pulling in third-party data, such as an RSS feed importer.

HTML and JavaScript

To make strings safe for HTML (without breaking Unicode text) use htmlentities().

1

<?php $safe = htmlentities($unsafe, ENT_QUOTES, 'UTF-8'); ?>

This will encode all special HTML characters. This method is better than black-listing specific elements such as <script> or just opening tags (<). Do not use strip_tags(), str_replace() or regular expressions to filter HTML and JavaScript, it is easy to miss obscure vulnerabilities and leave them exploitable.

When automatically parsing a URL to display a clickable link, check if URL starts with a protocol like “http://” (regex: /[a-z]:\/\//i) and make sure javascript: links never work. Also be careful with quotes and closing angle brackets as they can break HTML.

These examples demonstrate how unfiltered links can be dangerous:

1
2
3
4
5
6
7

<?php
$url = 'javascript:alert(\'XSS\');';
$url = 'http://example.com" onclick="alert(\'XSS\');';
$url = 'example.com"><script>alert(\'XSS\');</script>';
?>
 
<a href="<?php echo $url ?>">Click here</a>

URLs

To pass values as a parameter to a URL, use rawurlencode().

1

<?php $url = 'http://example.com/?k=' . rawurlencode($v); ?>

This function is nearly identical to urlencode() but follows the RFC 1738 specification.

MySQL database queries

When storing strings in a MySQL database, use mysql_real_escape_string().

1

<?php $safe mysql_real_escape_string($unsafe); ?>

Often addslashes() is used instead but this is not enough to prevent SQL injection attacks. If you want to learn why I recommend reading this blog post by Chris Shiflett and the third chapter of the guide to PHP security by Ilia Alshanetsky (PDF, 130KB).

This function requires a MySQL connection.

Magic Quotes

If your web app suffers from unwanted backslashes appearing in content this is probably due to double escaping (e.g. “today\’s weather”). This is likely caused by PHP’s now deprecated Magic Quotes.

Magic Quotes is a feature automatically escapes user input, intended to help beginners write more secure code. Because it’s not always on or needed this affects portability and requires excessive use of stripslashes() to undo.

To recursively undo the affects of Magic Quotes use this function at the beginning of your scripts:

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
function undo_magic_quotes($v)
{
    return is_array($v) ? array_map('undo_magic_quotes', $v) : stripslashes($v);
}
 
if ( function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc() )
{
    $_GET    = array_map('undo_magic_quotes', $_GET);
    $_POST   = array_map('undo_magic_quotes', $_POST);
    $_COOKIE = array_map('undo_magic_quotes', $_COOKIE);
}
?>

Directories

And finally, be careful with including files using user input.

1
2
3
4
5
6
7

<?php
// Don't do this
require($_GET['file']);
 
// And especially not this
echo file_get_contents($_GET['file']);
?>

This is dangerous because a user can request any file from the server and execute or view the code (e.g. “?file=../../config.php”, this is called a path traversal attack). One solution is to use basename() which strips off the path of a file name.

These were just a few basics, there is a lot more to web application security. OWASP is a great resource if you want to learn more.

Do not store password as plain text

This should be obvious. If someone gains access to your database then all user accounts are compromised. And not only that, people tend to use the same password on different sites so those accounts will be compromised as well. Your site doesn’t even need to be hacked; a system administrator could easily browse your database.

Do not try to invent your own password security

Chances are that you’re no security expert. You’re better off using a solution that has been proven to work instead of coming up with something yourself.

Do not encrypt passwords

Encryption may seem like a good idea but the process is reversible. Anyone with access to your code would have no trouble transforming the passwords back to their originals. Security through obscurity is not sufficient!

Do not use MD5

Storing password hashes is a step in the right direction. Cryptographic hashing functions like MD5 are irreversible which makes it difficult to figure out the original password. To validate a hashed password, simply hash the password again when a user logs in and compare the hashes.

1
2
3
4
5

<?php
$password = 'swordfish';
 
$hash = md5($password); // Value: 15b29ffdce66e10527a65bc6d71ad94d
?>

Note that this makes it impossible to retrieve a password from the database. If a user forgets his password, simply generate a new one.

So why not MD5? It is quite easy to make a list of millions of hashed passwords (a rainbow table) and compare the hashes to find the original passwords (the same goes for other hashing functions like SHA-1).

MD5 is also prone to brute forcing (trying out all combinations with an automated script) because of collisions. This means that different passwords can have the same hash, making it even easier to find one that works.

MD5 collision demo: mscs.dal.ca/~selinger/md5collision

Do not use a single site-wide salt

A salt is a string that is hashed together with a password so that most rainbow tables (or dictionary attacks) won’t work.

1
2
3
4
5
6

<?php
$password = 'swordfish';
$salt = 'something random';
 
$hash = md5($salt . $password); // Value: db4968a3db5f6ed2f60073c747bb4fb5
?>

This is better then using just MD5 but someone with access to your code can find the salt a generate a new rainbow table.

What you should do

• Use a cryptographically strong hashing function like SHA-1 or even SHA-256 (see PHP’s hash() function).
• Use a long and random salt for each password.
• Use a slow hashing algorithm to make brute force attacks near impossible.
• Regenerate the hash every time a users logs in.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?php
$username = 'Admin';
$password = 'gf45_gdf#4hg';
 
// Create a 256 bit (64 characters) long random salt
// Let's add 'something random' and the username
// to the salt as well for added security
$salt = hash('sha256', uniqid(mt_rand(), true) . 'something random' . strtolower($username));
 
// Prefix the password with the salt
$hash = $salt . $password;
 
// Hash the salted password a bunch of times
for ( $i = 0; $i < 100000; $i ++ )
{
    $hash = hash('sha256', $hash);
}
 
// Prefix the hash with the salt so we can find it back later
$hash = $salt . $hash;
 
/* Value:
 * e31f453ab964ec17e1e68faacbb64f05bccceb179858b4c482c1b182ff1e440e
 * f1e10feb5b86c6d367e4eb8f90f2cde5648a7db3df8526878f20a77eed00c703
 */
 
?>

In the above example we turned a reasonably strong password into a 128 characters long hash that we can store in a database. The next time the user logs in we can validate the password as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php
$username = 'Admin';
$password = 'gf45_gdf#4hg';
 
$sql = '
    SELECT
        `hash`
    FROM `users`
        WHERE `username` = "' . mysql_real_escape_string($username) . '"
    LIMIT 1
    ;';
 
$r = mysql_fetch_assoc(mysql_query($sql));
 
// The first 64 characters of the hash is the salt
$salt = substr($r['hash'], 0, 64);
 
$hash = $salt . $password;
 
// Hash the password as we did before
for ( $i = 0; $i < 100000; $i ++ )
{
    $hash = hash('sha256', $hash);
}
 
$hash = $salt . $hash;
 
if ( $hash == $r['hash'] )
{
    // Ok!
}
?>

A few additional tips to prevent user accounts from being hacked:

• Limit the number of failed login attempts.
• Require strong passwords.
• Do not limit passwords to a certain length (remember, you’re only storing a hash so length doesn’t matter).
• Allow special characters in passwords, there is no reason not to.

That’s it, happy coding!

• A hacker creates a page with a form that submits data to example.com.
• An administrator from example.com is tricked into visiting the page, the form is submitted using JavaScript.
• The data is handled by example.com as if it came from the administrator (because it did).

This allows a hacker to perform administrative tasks on example.com like editing pages or deleting users.

Solution

Probably the best solution to this problem is using a security token. This is a code (usually a hash) that is send with the form in a hidden field and is only valid for a specific user and a certain period of time.

I recommend using a SHA1 hash created from these components:

• Information about the user (IP address, user agent, username).
• Information about the server (hostname, software version).
• Information about the website (database name, table prefix).
• Information that expires (user’s session id).

This will result in an unpredictable and seemingly random hash that is still verifiable by the server and difficult to fake.

After the form is submitted the hash is re-created and compared to the token that was send with the form. Only if the hashes match the form is processed, otherwise an error message is displayed. This way even if a hacker manages to find the user’s token the request will fail.

Example (PHP/HTML):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<?php
$authToken = sha1(
  session_id() .
  phpversion() .
  $dbName .
  $_SERVER['REMOTE_ADDR'] .
  $_SERVER['HTTP_USER_AGENT']
  );
 
if ( isset($_POST['submit']) )
{
  if ( isset($_POST['auth_token']) && $_POST['auth_token'] == $authToken )
  {
    // Process form
  }
  else
  {
    // Display error message
  }
}
?>
 
<form id="form" method="post" action="./">
  <fieldset>
    <label for="name">Name:</label>
    <input type="text" name="name" id="name" value=""/>
  </fieldset>
  <fieldset>
    <input type="hidden" name="auth_token" value="<?php echo $authToken ?>"/>
 
    <input type="submit" name="submit" value="Submit"/>
  </fieldset>
</form>

Note that this only really works for POST requests. For this reason GET (regular links) should never be used to pass information that is used for administrative tasks. AJAX requests should also always use POST.