The prevailing misconception seems to be that having GET and POST variables mixed together is insecure. While this is true under some specific circumstances (see Cross-Site Request Forgeries for a weak example) -- it isn't the main reason why $_REQUEST is insecure. In fact, combining GET and POST data is often a very useful feature. In many cases you don't really care if a variable comes from GET or POST and so using $_REQUEST in those situations can help reduce the verbosity of your code while increasing flexibility.

The real problem is that COOKIE data is also mixed into $_REQUEST. The implications of this may not be readily apparent until you start thinking like a malicious user. Any cookie ever set on a users machine will always override any GET or POST data -- creating "sticky" variable data.

For instance, imagine if your application uses "action=" or "do=" switches to control page commands. If an attacker some how managed to set a cookie -- perhaps through some Javascript injection -- he could set a cookie named "action" and give it the value "logout." Any users that fell victim to the cookie set would never be able to use your application because "action" would be permanently set to "logout."

So to sum it up:

Question: Why is $_REQUEST insecure?
Answer: Because it combines COOKIE as well as GET and POST, and the COOKIE data always takes precedence -- creating the possibility for dangerous "sticky" variables.

Solutions

If you're already using PHP 5.3, then you can edit your php.ini and check the request_order variable -- make sure 'C' removed. This 'C' is removed by default, but if you use a shared host it might've been put back for backwards-compatibility. Make sure to check!

Otherwise, you can easily just create your own $_REQUEST array by merging $_GET and $_POST manually as part of your global initialization routines.

$_REQUEST = array_merge($_GET, $_POST);

And finally, best practice is to abstract your input reading out (see Stop using superglobals!) so you can define yourself exactly how variables are read and from where.

Best Practice: Cast to what you want

The first part of this post is all about how important casting incoming data is. As you know, security rule number one is never trust the user. So if you are expecting an Article ID which is an integer, you should make sure that you actually got an integer.

The most common approch is to cast user input when you get it. So if an attacker tries to supply some arbitrary string, PHP will cast it to an integer which usually results in a harmless 0. Sure, you have precautions in place against SQL injection or XSS but by casting data to a specific type, you can greatly simplify code because you can start working under assumptions ("I know for sure that $id is a harmless integer").

Here are a few examples:

// ID's (the use of max to get rid of negatives; Usually ID's are unsigned)
$article_id = max(0, (int)$_GET['id']);

// Simple strings
$username = preg_replace('#^[a-zA-Z0-9\-_\.]$#', '', $_GET['show_user']);

// Booleans
$show_drafts = (bool)$_GET['show_drafts'];

Note that this isn't really about form validation. If someone is filling out a form, you still need to make sure what they input is valid. For example, the "Simple strings" snippet above is useless to users when they're registering because you're not telling them that their input is invalid.

These strict casts are useful only when you don't expect users to fiddle with values. So things like view.php?id=34 where the URL is generated by your app, or <select> values where the user shouldn't change values etc.

Getting rid of the superglobals

Well, sort of. We obviously can't completely stop using $_GET/$_POST/$_COOKIE for reading incoming data because there's no replacement. What I'm talking about is ridding your code of these superglobals -- pushing them into a special input class. A code snippet is worth a thousand words; here's what I'm talking about:

// Bad
$article_id = $_GET['id'];

// Better
$article_id = $input->get('id');

Why

The above snippet doesn't really show off anything other than the concept. So let's talk about what this mysterious input class is meant to do, and why it's better than using superglobals.

Control

You don't have much control over superglobals. They are simply arrays. You can't do anything special before trying to fetch values. You might be thinking about what kind of processing you would want to do. But think about this for a moment.

How many times have you done something like this:

$article_id = (int)$_GET['id'];

// Or
if (isset($_GET['id']) {
    $article_id = (int)$_GET['id'];
}

Since you control the input class, you can add a bunch of features to make gathering and casting input really easy.

$article_id = $input->getInt('id');
$search_user = $input->getSimpleString('search_user');
$delete_ids = $input->getArrayOfInts('delete_ids');
$article_content = $input->getString('content');

UTF-8 Handling

One place where this sort of functionality is really useful is when you've switched to using UTF-8. As you know, it is possible for UTF-8 strings to be malformed -- and this is a security risk. So every time you read strings you must make sure they're valid. Without an input class, this would be a lot of work. With an input class, you can just modify your 'getString' method to add UTF-8 checking.

Stripping magic quotes

Another common task PHP programmers routinely need to do is handle magic quotes. Most of us simply test to see if magic quotes is enabled, and run the entire superglobal array family through a function that strips the slashes -- basically undoing this devil-feature.

But by doing this, you're affecting the entire app (because, well, you're modifying a superglobal of course!). This might not matter to you, but it gets a bit dangerous if you use third-party libraries.

A friend of mine creates Facebook applications. The Facebook PHP library is clever enough to test for magic quotes and strips slashes out for values it needs. But what if you're a clever PHP programmer, and you stripped out the slashes as part of your "global.php" file? FB doesn't know that, so it just strips them again! This is an example of how modifying global data is a bad idea.

By moving input-reading into your own class, you can do whatever the hell you want to your data and can rest assured knowing you didn't affect anything else.

Abstraction

By creating this new class, you abstract the details of how input is gathered. You might be wondering why this is important -- isn't there just get/post/cookie? No! While the vast majority of your webpages will only use these types of input, there are certainly others. Here are two that jump to my mind.

Command-Line

If you make command-line scripts, getting arguments may be a perfect use for your input class.

Friendly-URL's

$_GET only works for values encoded in the query string. But if you are a creating an app with friendly URL's, values are sometimes embedded right into the URL.

For example: /article/42/edit

This URL might mean to "edit" the article with ID of "42". Most frameworks, like Zend Framework's MVC components, make creating URL's like these very easy. In ZF, you define a route with placeholders of the values:

$router->addRoute('article_action', new Zend_Controller_Router_Route(
    'article/:article_id/:action',
    array('controller' => 'article', 'action' => 'view')
));

The framework provides a way to get the value of 'article_id' and 'action' that you could plug right into your input class. It might look something like this:

$article_id = $input->getIntFromUrl('article_id');
$action = $input->getStringFromUrl('action');

Building an input class

Building your own input class is an excersice you can complete yourself. But I'll get you started.

First of all, what is our goal?

• Ability to clean data
• Ability to get data from multiple sources

I think a well-designed system calls for a handful of classes:

• Cleaner takes values and cleans/casts them to a correct data type. We're using a separate class because it's not directly tied to input -- we might reuse this functionality elsewhere.
• InputSource_* are classes that read raw data from some source. We have one reader for each source. For example, InputSource_Array for reading information from an array (like supergloabls) or InputReader_Url for reading information from a friendly URL.
• InputReader is the main class that ties the Cleaner and the InputSource_* classes together.

Here's how it might work:

$cleaner = new Cleaner();
$input = new InputReader($cleaner);
$input->addSource('req', new InputSource_Array($_REQUEST));
$input->addSource('get', new InputSource_Array($_GET));
$input->addSource('post', new InputSource_Array($_POST));
$input->addSource('cookie', new InputSource_Array($_COOKIE));
$input->setDefaultSource('req');

$input->getInt('id'); // Get from the 'req' source, a default
$input->getInt('id', 'get'); // Get from 'get' source

// $input->getInt() calls a corresponding $cleaner method to
// clean an integer.

CSRF Explained

CSRF is a type of exploit that allows an attacker to send a request to your application with the authority of another user and without that users consent. Sometimes these requests might mean little (i.e., the user is a guest so they can't do any harm) but other times the requests can be very dangerous and destructive (i.e., the user is an administrator).

How It's Done

There are a number of ways that a request can be made against your server without any user interaction. The most basic and probably most often used technique is with a simple HTML image tag:

<img src="http://example.org/somescript.php" width="1" height="1" />

Even though the script handling the request ("somescript.php") might not be a valid image, it doesn't matter. The request is still being made. And by providing a width/height of 1 pixel, we can be certain the user doesn't even suspect anything is wrong.

Other ways might include using an iframe in the same way, or using automatic redirects.

How It's Dangerous

By being able to make requests so easily and without any interaction on the users part leaves services open for attack. As an example say we have an administrators control panel that lets admins delete articles on a website. An attacker might somehow get an admin to visit his website with an image tag on it:

<img src="http://example.org/admincp/delete_article.php?id=42" width="1" height="1" />

The danger comes when the admin happens to have an active session. If the session is controlled by cookies or IP address etc. then this request will be made with all of the authority of the admin. It would be as if the admin made the request purposefully.

You might be thinking that it would be a simple matter to prevent such an attack by using POST data instead of GET data. If you used POST data then the ID in the URL would not be accepted. While it does create another barrier for a potential attacker (which is always good), it doesn't solve the problem. Consider this code fragment:

<form action="http://example.org/admincp/delete_article.php" method="post" id="theform">
<input type="hidden" name="id" value="42" />
</form>
<script type="text/javascript">document.getElementById('theform').submit();</script>

Placing a 1x1 iframe with that code in it would achieve almost the same result as the 1x1 image, but this time using a POST request. Using POST over GET adds little security in this regard.

Protecting Against CSRF Attacks

There are a few general practices you should employ:

• Always use POST for important actions. This doesn't provide much protection (see above) but it does add another small barrier for an attacker to overcome. And it is generally good practice as it prevents users from performing harmful requests too easily (i.e., pasting a URL to a friend, bookmarks, etc). Using POST will also prevent any "fly-by" attacks. For example, consider a BBCode system on a message board. Using BBCode you can easily insert images into forum posts, but it is impossible to insert a hidden iframe (let alone Javascript). With such systems, to use the auto-submitting form above an attacker would have to actually trick an admin to visit a separate site.
• In some languages like PHP, you can get all incoming data in a common way. For example, in PHP you can use the $_REQUEST superglobal to get data from cookies, GET or POST. You should avoid the use of such convenience methods and always specify a specific location for where values should be coming from.
• Don't rely on confirmation forms or confirmation pages. The attacker will simply modify his request to indicate a "confirmed" action. For example, he might only need to add &confirmed=1 to the URL or add a "confirm" hidden field to a form. Confirmation pages are only effective when preventing human error, not for preventing attacks.

Easy: Deny Off-Site Referrers

One easy way to prevent CSRF attacks is to deny all POST requests from off-site domains. But this solution has a problem of its own: Not all users send the referrer header.

Every browser should send a referrer with each request, but there are dozens of hacks, mods or plugins that lets a user turn this feature off (some people see it as a privacy concern). So for these users you have a couple of choices: The first is to deny these users outright (probably not advisable except for special circumstances), and the second is to only enforce the referrer requirement when the referrer was in fact provided.

I choose to use the latter of the two choices. Since most users do provide a referrer, it is a great way to at least prevent the majority of people from falling victim to CSRF attacks. If the user does not provide a referrer, then we can rely on other means of protection (read more below).

Also a problem exists with the so-called dereferer services. There are some services available (and some proxy sites) that intentionally change the referrer of requests that run through them to protect the identity of the people using them (i.e., changes example.org to otherexample.net). Most internet security suites blank out the referrer, but that is easy to handle by just specially handling blank or missing referrers. If a user is using a dereferer service then there's no way for you to know if the request they make is real (and the referrer was modified intentionally) or fake (and the referrer is from an attacker site).

It's up to you to decide if these problems are worth the added security. What I do is to auto-pass all blank or invalid referrers so I can rely on other protection mechanisms (see the next section). The problem with dereferers is small, not many people use them. So I count it as an acceptable risk when important functionality is concerned.

Here is a function you can use in your own applications that will return false when the referrer is invalid. You can optionally supply a whitelist of domains that are allowed, other then the current working domain:

/**
 * Check the users referrer on POST requests to make sure
 * they come from the correct domain.
 *
 * @param array $whitelist An array of domains that should be
 *                         allowed regardless of the current domain.
 *
 * @return boolean True if the referer is allowed, false otherwise.
 */
function check_post_referrer($whitelist = array()) {

	// Only POST requests should be checked
	if (strtoupper($_SERVER['REQUEST_METHOD']) != 'POST') {
		return true;
	}

	$whitelist = (array)$whitelist;

	#------------------------------
	# Get the referrer host
	#------------------------------

	$ref_parts = @parse_url($_SERVER['HTTP_REFERER']);
	$ref_host = false;

	if ($ref_parts AND isset($ref_parts['host']) AND $ref_parts['host']) {
		$ref_host = $ref_parts['host'];
	}

	// No referrer, default to true
	if (!$ref_host) {
		return true;
	}

	#------------------------------
	# Get the current host and add
	# it to the whitelist
	#------------------------------

	$host = false;

	if ($_SERVER['HTTP_HOST']) {
		$host = $_SERVER['HTTP_HOST'];
	} else if ($_ENV['HTTP_HOST']) {
		$host = $_ENV['HTTP_HOST'];
	} else if ($_SERVER['SERVER_NAME']) {
		$host = $_SERVER['SERVER_NAME'];
	} else if ($_ENV['SERVER_NAME']) {
		$host = $_ENV['SERVER_NAME'];
	}

	if ($host) {
		array_unshift($whitelist, $host);
	}

	// If for some reason there are no allowed hosts,
	// default to true
	if (!$whitelist) {
		return true;
	}

	#------------------------------
	# Check the referrer against
	# allowed domains
	#------------------------------

	$valid = false;

	foreach ($whitelist as $check_host) {

		$check_host = trim($check_host);

		// Check with a space on each side to easily
		// anchor it without using regex

		if (stripos(" $ref_host ", " $check_host ") !== false) {
			$valid = true;
			break;
		}
	}

	return $valid;
}

Example usage:

<?php
if (!check_post_referrer()) {
    die('Invalid referrer');
}

// Process form
// ...

?>

A small aside here: Note that the header for the HTTP referrer is spelled incorrectly as "referer" (hence a missing "r"). This somehow made it into the HTTP standard. If you implement your own version of this function be sure you intentionally misspell "referer".

Note that this method is quite effective but is still not the holy grail. Referrer headers can be spoofed by an attacker in a couple of different ways. For example, in Flash the attacker can send a completely custom request to the server including a specially written referrer (though as I understand it, the latest version of Flash does not allow the altering of certain headers including the referrer). Other technologies may be prone to such abuse like Java applets or ActiveX controls.

Effective: Unique Tokens

The referrer check described above is easy to implement on a global scale, but as I explained, has some pitfalls. A more effective way to prevent CSRF is by authenticating each form with a special, unique token. This method is very effective and suffers from virtually no workarounds, but it's takes a bit more work for you as the programmer.

Basically you create a temporary token that is unguessable. Each time the user views a form, you generate another unguessable token. Once the user submits the form, you check the token to make sure it is valid. This makes it very difficult for an attacker to submit a form since there is no way he can get the token correct. If the token provided is incorrect, then you simply do not process the form.

Here's a simple implementation using sessions:

<?php

session_start();

$token = md5(microtime() . mt_rand(0, 1000) . mt_rand(0, 1000) . mt_rand(0, 1000));
$_SESSION['token'] = $token;

?>
<form action="somescript.php" method="post">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<!-- The rest of your form -->
</form>

And when you process the form, you check to make sure the token in the POST data is valid:

<?php

if ($_POST['token'] != $_SESSION['token']) {
	die('Invalid token.');
}

// Process form

There are different ways of saving the token of course. An alternate version might be to insert tokens into a database and then delete them after use. An advantage of this method is that a user can load multiple pages at the same time, all of which can have valid tokens. Using the session script above, the token will be overwritten on each subsequent page load. In todays world of multiple windows and tabbed browsing, it might be worthwhile to allow multiple tokens to co-exist. The only important aspect is to ensure that a token expires (either it can be used only once, or it has a lifetime, or both) and that it is unguessable.

Using the token method of protection does mean you have to create some way of generating tokens on every form and checking the validity of the tokens whenever you process a form. This can introduce some extra work for you, but it is well worth the effort. I'm sure you can think of ways to make an efficient token system that simply plugs right into your template system and form validation scheme.

Conclusion

You've certainly given lots of thought to XSS and SQL injection, the two most talked about vulnerabilities in web software. Today I hope I've either introduced you to a third big security issue or at least provided you with some information you didn't think about before.

Check your apps for CSRF vulnerbilities, they might be a little hard to notice until you really think about them. But even the big guys make mistakes. A while back, the major social news site digg suffered from this kind of attack. The site works by allowing users to "vote" on news stories to decide if the story is popular. Spammers used a CSRF attack to make any user that visited their site automatically vote for their story. Protect yourself! Use the techniques described in this post to add security to potential attack points in your applications.

The first thing you may ask is why? Why shouldn't passwords be stored in plaintext? The answer is pretty simple: security. You should never store anything valuable in plaintext. While your database (or wherever else you use to store this kind of information) is usually secure from prying eyes, you want to secure the information in such a way that it is virtually useless to anyone who happens to see it. This can be anyone from another admin that is snooping through the database, to a cracker that somehow got access to the data. Many people use the same password at multiple sites, so a plaintext password in the wrong hands can really lead to some serious complications.

Storing Passwords

The password you store should be a hashed version of the password. This prevents just anyone from reading the password and is the simplest way to secure your system.

For those of you who do not know what a hash is, I'll take the time to try and explain it simply. A hash function takes some data (for example, a password) and converts it into some fixed-length series of bits usually represented in hexadecimal characters. The result of the function is always the same for the same data. It is irreversible. Unlike a cryptographic algorithm which is designed to be reversed with the correct key, a hash function is only designed to generate this "fingerprint". A hash function is also designed so that any two different pieces of data never produce the same result (this is not entirely true, but close enough).

In PHP there are two popular hash algorithms for you to use: md5() and sha1(). I would recommend the use of sha1() which is a bit more secure. Here are two examples of these functions and the result they produce:

echo md5('devlog'); // f4606349b811ff614a35f1406030eba9
echo sha1('devlog'); // bc4d22b5ce9923f9e52b5636b3dc2e9fd499a187

Combine the attributes of a hash function (unique, irreversible, and nonsensical) and you get the perfect solution to secure passwords. Applying this concept to your applications is dreadfully simple. Where you would normally store a plaintext password, you now store the hashed password:

mysql_query("
	INSERT INTO users SET
		user = '" . mysql_real_escape_string($username) . "',
		password = '". sha1($input_password) ."'
");

Once you do this, there is one other aspect you need to take care of: logging in. Since the user would supply their password in plaintext, you need to hash their password before testing it against the one you have stored. There are usually two different methods programmers use to authenticate a user. The first is to use an SQL query with a WHERE clause so the passwords must match to return any row, the second is to just grab the user row and then compare the passwords in PHP. I will be using the second method.

Here's how your login code might look. Of course, $username and $input_password would filled with form values:

$res = mysql_query("
	SELECT * FROM users
	WHERE username = '" . mysql_real_escape_string($username) . "'
");

if (!mysql_num_rows($res)) {
	die('Invalid username.');
}

$user = mysql_fetch_assoc($res);

if ($user['password'] != sha1($input_password)) {
	die('Invalid password.');
}

As you can see, it's just a matter of comparing the already hashed password from the database with the hashed version of the inputted password. If they don't match, then the user inputted the incorrect password.

Just this small alteration to your save and login code has increased your security substantially, it's is worth the ten minutes of work.

Other Concerns

We already know that a hash function cannot be reversed, but there are still ways to get the original string.

Brute Forcing

A brute for attack is where the attacker has the hash for a password and continually tries one string after the other until he finds one that matches. For example, he might try 'a', then 'b' ... 'ab', 'ac' etcetera for all permutations of the alphabet. This takes a long time for long strings, but a relatively short amount of time for shorter ones. The amount of time is also increased when you introduce more characters (for example if you let users input punctuation characters).

Dictionary Attacks

A dictionary attack is similar to the a brute force attack but instead of trying every single possible combination of characters, the attacker uses a dictionary and only tries the words in the dictionary. This attack can be very useful since the majority of non-tech savvy people will use passwords like 'pussycat99' and these are the kinds of strings good dictionaries will contain. Since the number of strings to test will be dramatically lower then the number a brute force will have to try, this can crack a password extremely quickly if it is not a secure password. Since most web applications are designed to be as user friendly as possible, it is not often that developers enforce good password policies on users so this problem is still something to worry about.

Rainbow Table Lookups

A rainbow table is a huge database of pre-computed hashes. This is where someone hashes every possible string (usually up to a certain length) and saves the hash. When an attacker wants a password, he just checks this massive database for the hash. If the hash is found, he can easily see the corresponding string that made it. These databases are usually really big, but it is not common for a rainbow table to contain records past 8 characters.

The Solution: Use A Salt

The most common solution to all of these problems is to use a salt. Note that a salt only adds security when talking about trying to reverse a hash back into the original string. It is not meant to protect against multiple login attempts from an attacker trying to gain access to a user account (though if the attacker already has the hash then it may be the ultimate goal). For those kinds of attacks, you should enforce an account lock-out feature. For example, only allow 3 consecutive incorrect login attempts before locking the account for an hour or emailing the administrator with details.

A salt is basically a random string that you append to the users password. The salt is stored separately and is used purely to prevent the aforementioned attacks. The salt itself doesn't need to be secret, just the fact that it is appended to the password thwarts most password attacks. To generate a salt, you simply get random characters. For example, here's an example generate_salt() function:

/**
 * Generates a random salt from ASCII characters 33-126. These
 * characters include all letters, numbers and punctuation.
 *
 * @param integer $len How long you want the salt to be
 * @return string The generated salt
 */
function generate_salt($len = 8) {

	$min = 33;
	$max = 126;

	$salt = '';

	for($i = 0; $i <$len; $i++) {
		$salt .= chr(mt_rand($min, $max));
	}

	return $salt;
}

Now when you save a password you append the salt and save both the salt and the salted password. Our save code above might be altered like this:

$salt = generate_salt();

mysql_query("
	INSERT INTO users SET
		user = '" . mysql_real_escape_string($username) . "',
		password = '". sha1($input_password . $salt) ."',
		salt = '" . mysql_real_escape_string($salt) . "'
");

In doing so, a password mypass effectively becomes mypasscGdZPSEj. The random bit at the end means any attack is much much slower if not impossible. A brute force attack will become almost impossible with a long salt. A rainbow table lookup will most likely fail since there are certainly no databases that contain more then 10 character strings (most only go up to 8). A dictionary attack will be slowed down substantially when an attacker is trying to crack multiple passwords since each password will have a different salt and thus will need to be hashed separately.

Authentication With A Salt

If you are storing salted passwords, you once again have to change the way you authenticate. Just like how a plaintext password had to be hashed to be compared with the stored password, you need to hash and salt the inputted password before comparing. The above authentication code could be written like this:

$res = mysql_query("
	SELECT * FROM users
	WHERE username = '" . mysql_real_escape_string($username) . "'
");

if (!mysql_num_rows($res)) {
	die('Invalid username.');
}

$user = mysql_fetch_assoc($res);

if ($user['password'] != sha1($input_password . $user['salt'])) {
	die('Invalid password.');
}

Notice how on line 12 the salt is appended to $input_password.

What About 'Lost Password' Forms?

When you don't store the plaintext version of a password, it becomes impossible to send a user their password if they ever loose it. That's just the way things are. But that doesn't mean the user has no hope, you just have to take another approach. Instead of Lost Password forms, create Reset Password forms. Instead of sending the user an email with their password, send them a link with a special code that will reset the password and then send them the newly generated one. After they have logged in again with the new password they are free to go and change it to whatever they want.

Conclusion

I hope you've learned something today. I have seen many applications that still store passwords in plaintext, and it scares me a bit. I myself use a program on my Macintosh called info.xhead that stores all of my passwords for important things. Most of my passwords are 18 random characters, even I don't know what they are. But there are some common websites that I still use one password for (shame on me, I just can't be bothered to log into all of those old sites). It scares me because if an attacker gets hold of my one password, I sometimes wonder what other websites he will be able to gain access to. The Priate Bay, a torrent website, was recently hacked and the attacker gained all of the user information. Fortunately all of the passwords were hashed, but what if they weren't? I wonder how many users signed up with the same password as the password they used for their email account. Imagine how many compromised email accounts the attacker could have had access to. So do the world a favor: hash your passwords, and add in a dash of salt to make everything that much better.