2

Is it safe to use one CSRF token per form on my page, ex:

<form>
    <input type="hidden" name="token" vale="<?=$data['login_token'];?>" />"
</form>
<form>
    <input type="hidden" name="token" vale="<?=$data['register_token'];?>" />"
</form>

Or should I just use one generic token for every form, ex:

<form>
    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"
</form>
<form>
    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"
</form>

Note that I will refresh the token on each page request.

6
  • Why are you generating more than one form per page? May 9, 2016 at 19:11
  • A third option: Use one per session, without chaning it on every page load. I don't see why that would be less secure, but there might be something I am missing.
    – Anders
    May 9, 2016 at 19:34
  • Related: security.stackexchange.com/questions/26390/…
    – Anders
    May 9, 2016 at 19:38
  • 2
    @RobertMennell should I not be? say I have the profile page for a user and have a change password field and a update status field. wouldn't I want one form to point to a page that deals with changing the password and another form to deal with updating statuses? Idk though I'm still learning this wonderful world of programming :) May 9, 2016 at 19:43
  • 1
    Possible duplicate of Why refresh CSRF token per form request? May 10, 2016 at 9:13

2 Answers 2

4

As this question mentions, a single random unguessable token per session is sufficient.

When you start generating tokens per-page or per-form, you're simply limiting the impact of a CSRF token being leaked. Singular token leakage cases are relatively rare bugs, but XSS is obviously a common vector.

In certain cases it does indeed make sense to have a per-page or per-form CSRF token, as when combined with other protection features (e.g. disabling Ajax with CSP's connect-src directive) you can limit an XSS bug's ability to compromise CSRF tokens to the page which the XSS occurred, assuming you ensure that the token can't be re-used elsewhere.

Some people promote per-page or per-form CSRF protection as a way to increase security when using a double-submit cookie method, but I don't think this is sensible: if you have a bug that lets you read a cookie, you'd just read the session ID.

The flipside of the argument is that by implementing the more granular CSRF protection, you add additional complexity to your code, and that increases the attack surface and potential for bugs.

Personally, I'd stick with a single token per session, then implement other anti-automation controls (e.g. captcha, password re-entry) on top of this when needed for additional security.

2
  • Just want to add that per-page/form generally messes with the back button in complex ways. May 10, 2016 at 2:42
  • Agreed. Per-request CSRF is bad for Back button and caching too May 10, 2016 at 2:48
0

Consider what you're protecting against: an attacker tricking a user into making a request they don't think they're making. How would multiple different tokens on the page protect against that any more than a single one?

1
  • 3
    Limiting the impact of token leakage.
    – Polynomial
    May 9, 2016 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .