Using a session token or nonce for Cross-site Request Forgery Protection (CSRF)?

Question

I inherited some code that was recently attacked where the attacker sent repeated remote form submissions.

I implemented a prevention using a session auth token that I create for each user (not the session id). While I realize this specific attack is not CSRF, I adapted my solution from these posts (albeit dated).

• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
• http://tyleregeto.com/a-guide-to-nonce
• http://shiflett.org/articles/cross-site-request-forgeries

However, it still feels there is some vulnerability here. While I understand nothing is 100% secure, I have some questions:

• Couldn't a potential attacker simply start a valid session then include the session id (via cookie) with each of their requests?
• It seems an nonce would be better than session token. What's the best way to generate and track an nonce?
• I came across some points about these solutions being only single window. Could someone elaborate on this point?
• Do these solutions always require a session? Or can these tokens be created without a session? UPDATE, this particular page is just a single page form (no login). So starting a session just to generate a token seems excessive.
• Is there a simpler solution (not CAPTCHA) that I could implement to protect against this particular attack that would not use sessions.

In the end, I am looking for a better understanding so I can implement a more robust solution.

Rhythmandblues

Can you please give some exact attack pattern that was made on your site? Your latest update to the post makes it highly unlikely that you had a simple CSRF attack - they usually exploit session vulnerabilities (they are even called "session riding" on wiki). It looks like your form problem can be simply solved with captcha. – Pontius

It was an automated attack where they sent remote form submissions. A CAPTCHA might have prevented such an attack. However, I'm still interested in protecting the form in a more robust way. Ideally not worsening the UX with a CAPTCHA. Hence a session token or nonce. – Rhythmandblues

Uh, this is exactly what bots do - they automatically submit some forms - this is not a CSRF attack. If you invent some protection againt bots that doesnt involve reverse Turing test, you may make a revolution in the Internet :) Good luck! – Pontius

Fair. As mentioned before, I'm still interested in session tokens/nonce as they related to CSRF protection though. While I appreciate sarcasm, your comments aren't very helpful. – Rhythmandblues

Well, you asked a question about CSRF attacks and then it turns out you don't even have a session(main thing that this type of attacks rely on). I think you should delete this question a create a new one as this doesn't make sense at all. I think this is the reason the other guy deleted his answer. You should read en.wikipedia.org/wiki/Cross-site_request_forgery about what this attack really is. – Pontius

I've made some edits, but otherwise, the question expresses my needs - I am looking for a better understanding so I can implement a more robust solution. – Rhythmandblues

I updated my post a bit to give you a few hints about bot attack prevention, but really - just close this question and create a new good one with bounty: you have a lot of points to spend. Bounty questions attract much more top users then regular ones - you will get much more helpfull comments(as I am sure you know). I can flag this question with "misleading title" or something if you want(I don't know if you can close your question yourself). – Pontius

Answer 1

As far as I understand you need to do three things: make all of you changing-data actions avaliable only with POST request, disallow POST requests without valid referrer(it must be from the same domain) and check auth token in each POST request(POST token value must be the same as token in cookie).

First two will make it really hard to do any harmfull CSRF request as they are usually hidden images in emails, on other sites etc., and making cross-domain POST request with valid referer should be impossible/hard to do in modern browsers. The thid will make it completely impossible to do any harmfull action without stealing user's cookies/sniffing his traffic.

Now about your questions:

1. This question really confuses me: if you are using auth tokens correctly then attacker must know user's token from cookie to send it along with request, so why starting a valid attacker's own session can do any harm?
2. Nonces will make all your links ugly - I have never seen anyone using them anymore. And I think your site can be Dosed using it as you must save/search all the nounces in database - a lot of request to generate nounces may increase your database size really fast(and searching for them will be slow).
3. If you allow only one nounce per user_id to prevent (2) Dos attack then if user opens a page, then opens another page and then submits the first page - his request will be denied as a new nounce was generated and the old one is already invalid.
4. How else you will identify a unique user without a session ID be it a cookie, GET or POST variable?

UPD: As we are not talking abot CSRF anymore: you may implement many obscure defences that will prevent spider bots from submitting your form:

1. Hidden form fields that should not be filled(bots usually fill most of form fields that they see that have good names, even if they are realy hidden for a user)
2. Javascript mouse trackers (you can analyse recorded mouse movements to detect bots)
3. File request logs analysis(when a page is loaded javascript/css/images should be loaded too in most cases, but some(really rare) users have it turned off)
4. Javascript form changes(when a hidden(or not) field is added to a form with javascript that is required on server-side: bots usually don't execute javascript)
5. Traffic analysis tools like Snort to detect Bot patterns (strange user-agents, too fast form submitting, etc.).

and more, but in the end of the day some modern bots use total emulation of real user behaviour(using real browser API calls) - so if anyone really want to attack your site, no defence like this will help you. Even CAPTCHA today is not very reliable - besides complex image recognition algorithms you can now buy 1000 CAPTCHA's solved by human for any site for as low as $1(you can find services like this mostly in developing countries). So really, there is no 100% defence against bots - each case is different: sometimes you will have to create complex defence system yourself, sometimes just a little tweak will help.

Pontius

+1 Good point about the overhead of a true nonce implementation. – Rhythmandblues

Given your persistence, I've marked this as the answer. Nonetheless, I did post another question. – Rhythmandblues

Well, you should't have accepted this answer - I asked for questing closing. Questions like this really make finding relevant information on SO difficult. But on the topic - I think you will find out that people will answer this question the same as I did (current answers in new topic repeat my answer). – Pontius

Your answer is helpful and I used the information you provided. Therefore I marked it as such and imagine someone else will find it useful. – Rhythmandblues