0

I have a site that lets users submit POST requests to perform actions, authenticated by a standard PHP session cookie. For an extreme example:

<!-- real site !-->
<form action="http://victimserver.com/accountactions.php">
  <input type=hidden name="request" value="delete_all_my_account_data">

  This button will delete all your account data! Please be sure you mean it! 
  <input type="submit" name="delete" value="Delete All">
</form>

I understand the reason for CSRF tokens is to prevent a form on another site trivially setting my own site as the target and mimicking my site's commands, causing the victim's browser to faithfully submit cookies on their behalf, and successfully executing the command:

<!-- attacker site !-->
<form action="http://victimserver.com/accountactions.php">
  <input type=hidden name="request" value="delete_all_my_account_data">

  Click this button if you love chocolate cake!
  <input type="submit" name="delete" value="Yes, I love chocolate cake!">
</form>

Obviously I don't want to allow my site to be so easily targeted. As the simplest possible mitigation of this, I inject the PHP_SESSID cookie right into the form, and compare it server-side:

<!-- real site, improved !-->
<form action="http://victimserver.com/accountactions.php">
  <input type=hidden name="request" value="delete_all_my_account_data">
  <input type=hidden name="csrf" value="abcdef45678zyxwvu01234">

  This button will delete all your account data! Please be sure you mean it! 
  <input type="submit" name="delete" value="Delete All">
</form>

This seems like it covers all the bases. In a CSRF attack, the session cookie is supposed to be unknown to the attacker anyway (it would be game over already) and so they could not trivially mimic the hidden parameter on their site.

Could you tell me if there a real problem with the approach above, beyond just happening to be the simplest possible mitigation?

Dan Gelder
  • 75
  • 5
  • 1
    If you inject the session id in a GET form, it means that the id will appear in the URL. It is strongly recommended to avoid that. – Olivier Aug 15 '21 at 07:52
  • Also JS will be able to read the id. Sessions ids should not be accessible by JS. – Olivier Aug 15 '21 at 07:54
  • Does this answer your question? [How to properly add cross-site request forgery (CSRF) token using PHP](https://stackoverflow.com/questions/6287903/how-to-properly-add-cross-site-request-forgery-csrf-token-using-php) – digijay Aug 15 '21 at 08:13
  • Olivier, I use method=post on my site but forgot in the example. The client still has to know the CSRF token somehow though to submit it, doesn't it, whether in script or html? Would having a second cookie containing a random number be okay? – Dan Gelder Aug 15 '21 at 16:29

1 Answers1

0

Usually we set the httponly attribute for session ID cookies to prevent the session ID from being stolen by XSS. However, using session IDs as CSRF tokens can be easily stolen by XSS since the session IDs are in HTML files. Therefore, it is not appropriate to use session IDs as CSRF tokens.

ockeghem
  • 242
  • 1
  • 2