I have been working with CodeIgniter for about 3 weeks and am very well on the way to loving this framework. However I have been looking at the core code of the framework and I was reading over the CSRF protection. I spotted (the lack of) CSRF regeneration. All it does is extends the tokens life. This is making me very nervous. I played around with the expire times and I can not have it expire once a every two minutes. It would make my application unusable as it is mostly based on form submission.

My question is why would some one NOT want to have a token regenerate per request / per form?

Is this a best practice to maintain the same token? I've been reading OWASP and apart from the hidden fields in a form, other solutions are using CAPTCHA but then that would also break my application as the users do not want that. All in all I am just very confused as to why this is so.

Just for a little bit of extra information this is what I am doing to prevent any information leaks:

  1. SSL/TLS (https) through out the entire application
  2. Remove server signatures on headers
  3. set up a 64 Key encryption key for personal information, and the cookies
  4. Xss filter all post get cookie
  5. validate everything
  6. Escape anything that is derived from user inputted data.

and the following are my configurations for CI security :

    $config['cookie_secure']    = TRUE; // Send cookies only over HTTPS
    $config['global_xss_filtering'] = TRUE; // Global xss filter (input only- i escape output when needed) 
    $config['sess_encrypt_cookie']  = TRUE; // "encrypts" session with my 64 Character encryption key
    $config['sess_time_to_update']  = 10; // regenerate session id every 10 seconds

Sorry if this post is long and drawn out I just want to make sure that I am taking all the required steps into application security.



Under what conditions should an application regenerate a CSRF synchronization token?

The most important attribute is that this value cannot be guessed by an attacker and therefore unique to a session. Synchronization Tokens are commonly defeated using XSS. A good example is the Sammy MySpace XSS worm, which read the CSRF token using an XHR and filed the request. So even if the synchronization token was regenerated for every page, it would still fall to an XSS attack. (Also Cookie variables are not a vector for XSS because an attacker cannot control these variables in the request.)

An attacker has an advantage that they can make a very large number of requests. It maybe possible for an attacker to guess the CSRF token used. Similarly it is also possible for an attacker to potentially guess the session id used. Both of these attacks have an identical impact, an attacker is able to perform an action as that user. There should be some timeout to prevent both of these attacks, but this value varies on your application. Is this a bank application dealing with money? Which should expire a session after 20 or so minutes Or is this just a forum with limited security impact, in that case maybe 24 hours.

  • Its a student tracking system dealing with Red Flag data such as student A Numbers (student Id's). Said A Numbers are also linked to other special data. And The reason why I was confused is because doesn't making a CSRF token static defeat the purpose? – RaGe10940 Feb 19 '13 at 0:17
  • But then you can have access/deny lists in the webserver, use IP tables in the server (linux 12.04 in my case) and have a firewall around the box itself which acts as a filter for none allowed IP's. But then the problem comes with spoofing and such. Alright thanks for clarifying this for me Rook! – RaGe10940 Feb 19 '13 at 0:18
  • I'd vote vote you but I can't -_- – RaGe10940 Feb 19 '13 at 0:19
  • @RaGe10940 - now you can. – Deer Hunter Feb 19 '13 at 16:55
  • @RaGe10940 you can't spoof a tcp connection over the internet, and the sync token must be unique per session. No two users will share the same sync token. – rook Feb 19 '13 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.