John Squibb
Using Tokens to Thwart Cross-Site Request Forgeries
A Cross-Site Request Forgery (CSRF) occurs when an attacker supplies a link or script that causes a user to access a page on another site where that user is presumed to have been logged in. For example, an attacker could provide a link for a social network site to an unsuspecting user logged-in at that site, causing that user to add the attacker to their friends list. Another scenario could cause the user to transfer funds from their bank account to the account of the attacker.
CSRF issues surface when the destination website blindly trusts that the authenticated user intends to perform the action the attacker commands. There are several methods for thwarting such exploits. Today, we'll cover the use of tokens to safeguard against CSRF.
Implementing Single-use Tokens
When generating links that require a user action, we can attach a token in the following manner:
http://example.com/action?token=abcdefg
The format of the token isn't important, so long as it is random, hard to guess, and temporary. The following code demonstrates how to generate a randomized token:
<?php
// Generate a randomized token
$token = md5(microtime(TRUE) . rand(0, 100000));
// Save the token to session
session_start();
$_SESSION['token'] = $token;
// Add an expiration date to prevent fixation.
$_SESSION['token-expires'] = time() + 1800;
In this example, we generate the randomized token, store it in the session for comparison later, and for extra security, set an expiration time for the token of 30 minutes. After that amount of time, we won't honor the token any longer. This can help prevent token fixation in the event that an attacker somehow acquires access to a tokenized link intended for the user.
When processing the action for the supplied link, we can check for the required token as follows:
<?php
// Get the form token.
$supplied_token = $_GET['token'];
// Ensure that a token has been previously set.
session_start();
if (!isset($_SESSION['token'], $_SESSION['token-expires']))
{
die ('token is required!');
}
$token = $_SESSION['token'];
$expires = $_SESSION['token-expires'];
// Clear the tokens, they are single use.
$_SESSION['token'] = NULL;
$_SESSION['token-expires'] = 0;
if ($expires < time() || $token != $supplied_token)
{
die ('Invalid or expired token!');
}
else
{
print 'Token good!';
}
This snippet examines the visited page for the required token, checks the session, and ensures that the token matches, and that it has not expired. Also, we immediately wipe the token, as it is single-use only.
Using POST instead of GET or REQUEST
Another angle for CSRF exploitation can involve form data. If a particular form accepts GET or REQUEST data on the server side, then a malicious attacker could provide such data in the form of a link, image tag, etc. This could potentially emulate a user filling out and submitting the form on-site. There are two ways to thwart this behavior:
- Only use POST to process forms. This prevents the attacker from supplying links to an unsuspecting user.
- Include a token with all form submissions. This ensures that the user is on-site when posting the form, and has the added benefit of expiring a form submission after the initial submit, presuming that the token is wiped each time. This can help reduce multiple form posts when a user accidentally/intentionally refreshes the page after submit.
Including a token with a form is easy. Simply generate the token in the same fashion as previously explained, and supply it as a hidden input field in the form. On submit, check that the token matches the stored token, erase it, and redirect/error as appropriate.
Checking Referrers
Another way to thwart CSRF is to ensure that the page from which the user arrived is the expected origination for an action. For example, if we know that a user must always come from the http://example.com/profile page to affect the http://example.com/profile/edit page, then we can reasonably detect this from within our code by checking the HTTP referer. The downfalls to this are as follows:
- The application is forced to know all entry points. For actions expected to derive from emails, external links, etc., this can be impossible to work around.
- Referrer checking is vulnerable to Referrer spoofing.
- Attacks aren't always limited to off-site links. Many websites have chat rooms, message boards, forums, or other mechanisms for displaying user-generated content, which could contain On-Site Request Forgeries. Checking the referrers may not always catch this type of attack.
Use your best judgment when deciding which mechanisms to employ, and don't be afraid to use a combination of checks where appropriate.
Read More
This article is one in a several-part series on PHP security. View all the articles
Suggested Reading
PHP Objects, Patterns, and Practice
by Matt Zandstra
Suggested Reading
Mastering Regular Expressions
by Jeffrey E.F. Friedl
Tags: Security, Tokens, CSRF, Cross-Site Request Forgery
Short URL: http://sqb.in/z2tQ