36

I am fully aware of CSRF and have already implemented some safe forms, but I have never been happy with the results yet.

I've created tokens as a md5 of username, form info and a salt and stored it in a session. This has a problem with tabbed browsing (can be fixed by keeping an array of active hashes) and with timing. I would like my hashes to work only for eg. 10 minutes, but how do I put a time-related variable in the hash?

Can anybody point me to a good resource describing how to make CSRF security properly?

Improve this question
1

5 Answers 5

Reset to default
25

The best way to build CSRF protection properly:

Don't.

Most common frameworks have this protection already built in (ASP.NET, Struts, Ruby I think), or there are existing libraries that have already been vetted. (e.g. OWASP's CSRFGuard).

Another option, depending on your context, is to enforce reauthentication of the user, but only for specific, sensitive operations.

As per your comments, if you need to implement this yourself, your solution is not too bad, but I would simplify it.
You can generate a crypto-random nonce (long enough), store that in session memory, and change it every X minutes (you store the expiry time in session too). In each form, you include the nonce in a hidden form field, and compare that value when the form is posted.
If the form token matches, you're clear. If not, you can accept e.g. the previous token as well, to handle the edge cases.

Though I must say that I've seen too many failed attempts at implementing this by oneself, to really recommend this path. You're still better off finding a minimal package to do this for you.

Improve this answer
5
  • 12
    OK, that doesn't quite answer the question. It's a site about security, not webapp development. I know I should use existing solutions for any security, but here I expected to get to know how such a solution is created.
    – naugtur
    Nov 12, 2010 at 9:03
  • 1
    Moreover - I want to use CSRF protection in an app working on a tiny embedded device. Know any frameworks for that in bash or perl without modules? ;)
    – naugtur
    Nov 12, 2010 at 9:12
  • Heh, fair point about the embedded - you're serving up a web app from that? Wrt the first comment, I would say proper security includes "Don't re-invent the wheel", but if you need it for embedded - or just interested in the theory - I'll update my answer.
    – AviD ♦
    Nov 12, 2010 at 10:27
  • Thanks! I'm glad I convinced you to answer me that easily. People often get really mean when I ask about things that should not be re-implemented. ;)
    – naugtur
    Nov 13, 2010 at 21:43
  • 2
    Well, you did make two convincing arguments: 1. I want to understand, and not just be a code monkey :), 2. I have an edge case (embedded usually fits the bill), and there is no wheel there yet.
    – AviD ♦
    Nov 14, 2010 at 0:38
27

There is a good explanation on OWASP: OWASP CSRF Prevention Cheat Sheet

In short they say that there are two ways:

  1. Add a random token to each user session. Only if this token is present and correct will the changes be applied, otherwise the request should be rejected. It is important that the token is only sent with a POST request, since GET requests can leak the token to different places (browser history, log files, etc.).

    It is also possible to generate a token per request, but this leads to usability problems. For example the back button wouldn't work properly anymore. But of course the security would be increased.

    Also make sure (to enhance security even more) that the token is only sent over TLS, so there won't be any man in the middle problems.

  2. The other option is to use some sort of challenge - response (for example CAPTCHAs or one-time tokens).

The OWASP-Page also lists a few measures that don't work. These are

  • Using (secret) cookies
  • Not using GET-requests
  • Multi-Step transactions
  • URL Rewriting
Improve this answer
1
  • The OWASP page linked above has been updated to recommend "Verifying Same Origin with Standard Headers" checks in addition to the tokens described.
    – Russbear
    Dec 12, 2017 at 18:55
3

In addition to @Andreas Arnold answer there is an alternative. I implemented the Encrypted Token Pattern from OWasp.

Apart from preventing csrf attacks, it has the added advantage of implementing object security.

Only those who are authorized to modify objects, can do so. Others will not have the correct/valid cipher text or key. I usually encrypt sessionId, timestamp, userId, and/or recordId.

timestamp prevents replayAttacks. sessionid isolates changes to this session only userId isolates changes to this user only. If you include recordId, then at the cost of extra processing you gain more security.

Improve this answer
1
  • 2
    Timestamps only prevent replay outside of a configured timeout. You should use a nonce for that. Also, another good property of the Encrypted Token pattern is that it doesn't require server state (i.e. no session) and thus makes horizontal scalability easier (e.g. no session replication, no sticky session).
    – skuro
    Apr 29, 2015 at 9:07
-2

I don't think that there's much wrong (though I may be wrong ;) with including a timestamp in the token to be hashed and including this timestamp as a hidden form field - maybe hex-encoded as basic obfuscation - you can then check for staleness on submission.

Improve this answer
1
  • 4
    A timestamp doesn't have sufficient entropy. If you used it as input to a PRF, together with a cryptographic key that is never revealed to any client, that might work, but it is needless complexity. Better to avoid building your own, and rely upon some well-vetted implementation, as AviD recommends.
    – D.W.
    Jan 10, 2013 at 2:34
-2

I tend to think that token based CSRF protection can be fairly easily broken: an attacker just need to know how to request a CSRF protected page, normally these pages have the token as a hidden field. Attacker then grabs the token from the page (fairly trivial) and use it to construct a CSRF attack.

Improve this answer
1
  • 7
    Well, if you're using a program that can query the page, you're as much of a user to me as anybody else. anti-CSRF is to prevent sending request from another site through an ordinary browser (because the user is logged in and the browser sends session information). If your attacking code can get the page contents, you're not doing a CSRF anymore. You can just post anything.
    – naugtur
    Feb 19, 2013 at 19:56

You must log in to answer this question.

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