preventing csrf in php

Asked 23/11, 2009 at 1:26 Answered 13/11, 2015 at 13:0

Requiring authentication in GET and POST parameters, not only cookies;
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?

Nez answered 23/11, 2009 at 1:26 Comment(0)

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).

Shakira answered 23/11, 2009 at 1:41 Comment(7)

The session expiration shouldn't be enough? I mean not to check the expiration with a custom function. – Conception 31/10, 2012 at 16:51

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? – Gemmation 6/6, 2013 at 9: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. – Conception 10/6, 2013 at 14:12

@JavierConstanzo Why? For convenience. Do you remember when was the last time you had to enter your login in facebook? – Gemmation 12/6, 2013 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. – Ixion 20/5, 2014 at 10:16

According to 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.

– Dirk 12/11, 2014 at 2:3

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. – Whitewing 9/6, 2016 at 22:38

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.

Sharpfreeze answered 23/11, 2009 at 1:42 Comment(1)

Very true, the HTTP Referer header can be easily forged and doesn't offer any real protection against CSRF. – Shakira 23/11, 2009 at 1:51

[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.

Krak answered 13/11, 2015 at 13:0 Comment(0)

Recommended topics

Hot tags