Are we really secured from CSRF?

Question

confirm.php

<?php
 session_start();
 $token= md5(uniqid());
 $_SESSION['delete_customer_token']= $token;
 session_write_close();
?>
<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);" />

confirm_save.php

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

Lets say we have a typical CSRF protection like this one What if an attacket uses this code to bypass the csrf token?

//On any site
<img src="http://cia.teletubbies.com/csrf.php" height="0" weight="0"/>

//csrf.php
$cont = get_file_contents("http://cia.google.com/confirm.php");
// parse the html using [PHP Simple HTML DOM Parser][2] and get the CSRF token
//CURL and send a POST request to confirm_save.php with the token

This thing keeps bugging me, but im too lazy to try an attack on any random site. Isnt this is possible?

The example code was stolen from preventing csrf in php

Updated

What happens when someone wants to pass a token from one platform to another or from server side to the client side? Flash to PHP for instance, how could its secure from csrf?

Spandex

You're misunderstanding CSRF. If an attacker uses the "bypass" code sample you posted, they'd get their own unique token. There'd be no point in hijacking their own session. – Helmet

Thanks for explaining, any ideas on making CSRF secure client side requests? – Spandex

Answer 1

You'd be getting the CSRF token for the session of the server you are using to scrape the page. Since that session is not the victim's, it's secure. (If you're stealing the user's session, it's no longer a CSRF attack!)

So, yes, unless it's implemented horribly, you can't just scrape a CSRF token and use it in a CSRF attack.

Gunyah

so the csrf.php will get a new session instead of the current users which changes on every request? – Spandex

The server that is executing get_file_contents() will have a different session than the users', yes, so the value of $_SESSION['delete_customer_token'] will be different for each. – Gunyah

Okay, what if someone wants to make server side request from client side app securely from CSRF? How is thats possible? – Spandex

Depends on the type of client-side application. Unless the app is just submitting data via POST/GET through the browser, it shouldn't be a problem. As long as you can't exploit the trust of the user's browser, it's not CSRF-able. Otherwise, use a session token in a similar fashion - it doesn't necessarily have to be the same token as used by PHP. – Gunyah

Answer 2

The CSRF protection works since only the authenticated user can access the token.

Your csrf.php page is on another domain, and can thus not see session cookies for the legitimate site, nor get to the CSRF token.

Spirochete

an attacker can get the token which is passed in typical HTML form and submit it using CURL – Spandex

The token is only ever passed between the legitimate website and the browser of the legitimate user. The attacker only controls csrf.php on another server, and has no access to the token of the legitimate user. If the attacker makes a request to the legitimate website, he will get his own token, not the token of the legitimate user. – Pshaw

I think I got it but then how could someone make a server side request from client side app securely from CSRF? – Spandex

If the client needs to make a request via a third-party server, the client will need to pass the token to the third-party. In this case, you'll have to trust the third-party. But this is really not the setup that CSRF protection was designed for. – Pshaw