What is CSRF?

May 7, 2010, by | Start Discussion


A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The attack basically uses the session of an authenticated user and is also known as Session riding.

The CSRF name was given to them by Peter Watkins in a June 2001 posting to the Bugtraq mailing list.

CSRF outlined

First of all to understand what are forged cross-site requests (CSRF)? Cross-site request forgery is a Compromised end -users currently log in at the Web application to perform the operation of non-intention of attack methods. As long as the attacker with some social engineering tricks, such as by e-mail or chat software to send the link, the attacker will be able to force a Web application user to perform the selection operation of the attacker.

For example, if users log in internet banking go to view their deposits, he did not quit the network banking system go enjoy their own forum go irrigation, if the attacker at the forum carefully construct a malicious link and to induce the user clicks on the link, then the user at the network bank account funds may be transferred to the attacker specified account. 

When CSRF attacks against ordinary users, the data will be the end-user and operational directives pose a serious threat; when attacks by the end user with an administrator account when, CSRF attacks will threaten the entire Web application.

What kinds of applications are vulnerable?

Pretty much all of them. Any application using HTTP GET, HTTP POST, HTTP PUT etc. without ensuring that the request came willfully from the authenticated user and not by some trick are vulnerable.
Web applications with bad architecture

Any web application which allows some change purely based on GET requests is violating the RFC. According to the HTTP RFC #2616 section 9.1.1 Safe Methods; GET should not have the significance of taking an action. They shouldn't be allowing GET requests to take actions.

Automating POST requests

Using AJAX techniques this can be achieved without any active user intervention and with complete stealth. Either using iframes with embedded forms or the favourite of Web2.0 XHR also known as AJAX it is trivial to automate POST requests without any user intervention whatsoever.

Any web page which is allowed to run javascript is capable of doing this. Using a very strict ruleset of Mozilla Firefox extension noscript might help you a bit. But it increases the pain of browsing immensely.

Mozilla

<script>
  var post_data = 'name=value';
  var xmlhttp=new XMLHttpRequest();
  xmlhttp.open("POST", 'http://url/path/file.ext', true);
  xmlhttp.onreadystatechange = function () {
  if (xmlhttp.readyState == 4)
  {
  alert(xmlhttp.responseText);
  }
  };
  xmlhttp.send(post_data);
</script>

 
Anatomy of a CSRF attack

Imagine you are logged into your web mail in one tab while browsing other websites in other tabs. Your web mail has a logout link which is simply a HTTP GET request. This is what the request look like.

GET http://example.com/logout.php HTTP/1.1

Now a malicious person adds an image tag to a website you regularly visit. Rather than pointing to the URL of the actual image this is what he/she does.

< http://example.com/logout.php” />

When your browser encounters that part of the HTML it will make a HTTP GET request on your behalf and try to download the image from the URL mentioned. As soon as the HTTP GET request is made your web mail will log you out.

So what is the big deal?

What if rather than logout it pointed to adding a mail filter forwarding all mails to another account?

< http://example.com/addfilter.php?src=*&[email protected] />

Or what if the URL pointed to adding/modifying your DSL router

http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub/

Maybe initiating money transfer using your bank website.
 

Example Exploit

The simplest example exploit uses an image. To understand the exploit, it is first necessary to understand how a browser requests images. Consider a very simple page:

<html>

<p>Here is ANY sample image:

< http://example.org/example.png" /></p>

</html>
 

When a browser requests this page, it cannot know that the page has an image. The browser only realizes this once it parses the HTML within the response. It is at this point that the browser requests the image, and it uses a standard GET request to do so. This is the important characteristic. It is impossible for the target site to distinguish between a request for an image and a request for any other resource.

When requesting an image, some browsers alter the value of the Accept header to give a higher priority to image types. Resist the urge to rely upon this behavior for protection – I show you a more reliable approach at the end of this article.

Now, imagine that the image in a page is the following:

< http://example.org/buy.php?symbol=SCOX&shares=1000" />

Every user that visits this page sends a request to example.org just as if the user clicked a link to the same URL. Because the sample application uses $_REQUEST instead of the more specific $_POST, it cannot distinguish between data sent in the URL from data provided in the proper HTML form.

This is an intentional mistake that I want to highlight. Using $_REQUEST unnecessarily increases your risk. In addition, if you perform an action (such as buying stocks) as a result of a GET request, you are violating the HTTP specification.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

POST requests can also be forged, so do not consider a strict use of $_POST to be sufficient protection.
Example of CSRF

CSRF is a malicious attack that transmits unauthorized commands to a website from a trusted user. Let’s take a simple example to understand this:
 

  1. Sheetal is checking her email on a very safe    computer (totally patched, fire-walled, with the latest updated antivirus etc etc) using a very safe browser.
  2. Because she is logged in to Gmail, the Gmail authentication cookie is present on her machine.
  3. She receives an email from Deepali containing a really funny joke. The email contains a link to a site which promises her lots more funny stuff. She clicks on the link and is very happy with the site that opens up.
  4. What she does not realize is that this joke site has forged a POST request to the Gmail “Create Filter” wizard. This creates a filter that forwards a copy of all emails coming into Sheetal’s account to Deepali!
  5. Gmail accepts the request to create the filter because the genuine Gmail account holder (Sheetal) is authenticated and logged in at the moment and her session cookie is passed along with the forged request.
  6. Your browser may not support display of this image. This new Gmail filter will keep stealing Sheetal’s emails till she manually checks her filters and realizes that there is an unauthorized one.

I carried out a small experiment wherein I requested for a filter to forward all emails to a particular account. On analyzing the data transfer between my browser and Gmail (using Tamper Data extension for Firefox) I found that the relevant GET parameter is cf2_email.
 

See the following for more information on this

Safeguard against CSRF

There are a few steps you can take to mitigate the risk of CSRF attacks. Minor steps include using POST rather than GET in HTML forms that perform actions, using $_POST instead of $_REQUEST, and requiring verification for critical actions (convenience typically increases risk, and it's up to you to decide the appropriate balance).

The most important thing you can do is to try to force the use of your own forms. If a user sends a request that looks like it is the result of a form submission, doesn't it make sense to be a little suspicious if the user has not recently requested the form?

Consider the following replacement for the HTML form in the sample application:

<?php
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_time'] = time();
?>

<form action="buy.php" method="post">
<input type="hidden" name="token"
      value="<?php echo $token; ?>" /><p>
Symbol: <input type="text" name="symbol" /><br />
Shares: <input type="text" name="shares" /><br />
<input type="submit" value="Buy" />
</p>
</form>

 

Because this form does not represent an entire script, we do not include the call to session_start (). Readers can safely assume that this required step takes place prior to the form.

With this simple modification, a CSRF attack must include a valid token (anti-CSRF token) in order to perfectly mimic the form submission. Because you store the user's token in the session, it is also necessary that the attacker uses the token unique to the victim. This effectively limits any attack to a single user, and it requires the attacker to obtain a valid token for another user (obtaining your own token is useless when it comes to forging requests from someone else).

This script should be initialized just like any other session variable:

<?php

if (!isset($_SESSION['token']))
{
$_SESSION['token'] =md5(uniqid(rand(), TRUE));
}
?>

The script can be checked with a simple conditional statement:

<?php
if ($_POST['token'] == $_SESSION['token'])
{
/* Valid Token */
}
?>

 

The validity of the script can also be limited to a small window of time, such as five minutes:
 

<?php

$token_age = time() – $_SESSION['token_time'];

 if ($token_age <= 300)
{
  /* Less than five minutes has passed*/
}
?>

Challenge-Response

Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.
 

Prevention Measures That Do NOT Work
 

  • Using secret cookies.
  • Only Accepting POST request.
  • Checking Refer Header.
  • Multi-Step Transactions.
  • URL rewriting.

 

Author bio not avialable

Leave a Reply