26

  1. Requiring authentication in GET and POST parameters, not only cookies;

  2. Checking the HTTP Referer header;

saw this post on wikipedia and was wondering how I can apply them

ok...I am using the Kohana PHP framework and I have the facility to determine the referrer header, but what exactly do I check in the referrer header? the framework function only returns the URL of the referrer

and how do I validate GET and POST params? against what? stored information? expected type?

yretuta
  • 7,963
  • 17
  • 80
  • 151

3 Answers3

54

To prevent CSRF you'll want to validate a one-time token, POST'ed and associated with the current session. Something like the following . . .

On the page where the user requests to delete a record:

confirm.php

<?php
 session_start();
 $token = isset($_SESSION['delete_customer_token']) ? $_SESSION['delete_customer_token'] : "";
 if (!$token) {
     // generate token and persist for later verification
     // - in practice use openssl_random_pseudo_bytes() or similar instead of uniqid() 
     $token = md5(uniqid());
     $_SESSION['delete_customer_token']= $token;
 }
 session_write_close();
?>
<html>
<body>
<form method="post" action="confirm_save.php">
 <input type="hidden" name="token" value="<?php echo $token; ?>" />
Do you really want to delete?
<input type="submit" value=" Yes " />
<input type="button" value=" No " onclick="history.go(-1);" />
</form>
</body>
</html>

Then when it comes to actually deleting the record:

confirm_save.php

<?php
 session_start();
 // validate token
 $token = isset($_SESSION['delete_customer_token']) ? $_SESSION['delete_customer_token'] : "";
 if ($token && $_POST['token'] === $token) {
   // delete the record
   ...
   // remove token after successful delete
   unset($_SESSION['delete_customer_token']);
 } else {
   // log potential CSRF attack.
 }
 session_write_close();
?>

The token should be hard to guess, unique for each delete request, accepted via $_POST only and expire after a few minutes (expiration not shown in this example).

leepowers
  • 37,828
  • 23
  • 98
  • 129
  • The session expiration shouldn't be enough? I mean not to check the expiration with a custom function. – Javier Constanzo Oct 31 '12 at 16:51
  • 1
    Sessions don't prevent CSRF @JavierConstanzo. Sometimes they last for weeks or more. What happens if you open a website with a CSRF attack while your session is still active? – Edson Medina Jun 06 '13 at 09:58
  • Why would you configure your server @EdsonMedina to have sessions that lasts weeks? I know sessions aren't enough to prevent CSRF, I wasn't implying that. – Javier Constanzo Jun 10 '13 at 14:12
  • @JavierConstanzo Why? For convenience. Do you remember when was the last time you had to enter your login in facebook? – Edson Medina Jun 12 '13 at 10:40
  • @EdsonMedina Facebook does not prolong by expanding the sessions timeout. Usually websites use cookies to do that because however long the session is when you closes the browsers it's gone. – deathemperor May 20 '14 at 10:16
  • 3
    According to http://php.net/manual/en/function.uniqid.php, `uniqid() must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable secure IDs. ` – S. Dixon Nov 12 '14 at 02:03
  • 2
    This is a problem when you open the same webpage in different tabs. Because the random value is generated again in each tab, the user has to stick with his current tab. – Jordy Jun 09 '16 at 22:38
4

With referral checking all your doing is looking to make sure the referer is from your site/system. If the referer does not exist or is from a foreign site then the referal check fails and you may not want to honor whatever request is being made.

In the past problems with various technologies and browsers (flash..et al) allowed forgery of referal headers. Its something to consider. There are several methods using javascript to link to resources where the referal data is not present/passed in the request header.

This behavior varies somewhat between browsers. If you use javascript to submit a form your typically ok. If you use something like window.location most likely you should not expect referal data to be present.

A popular method for CSRF prevention is to not use cookies and always pass state between references... Passing a session token in all links throughout an application.

Einstein
  • 4,450
  • 1
  • 23
  • 20
  • 1
    Very true, the HTTP Referer header can be easily forged and doesn't offer any real protection against CSRF. – leepowers Nov 23 '09 at 01:51
2

[Note:] Kohana framework is Deprecated, new fork for Kohana PHP 7 is https://koseven.ga/ and it does support CSRF functionality is Security class.

You can use Official koseven security feature. Here is a link to koseven security class.

Faraz
  • 751
  • 7
  • 23