Why doesn't codeigniter2 save csrf_hash in a more secure way, like a session?

Question

Why is the generated CSRF security token not saved and used through SESSION, as suggested here ? Currently, in CI2, the CSRF protection mechanism (in the security class) is as follows:

1. Create a unique value for the CSRF token in the _csrf_set_hash () function:

$this->csrf_hash = md5(uniqid(rand(), TRUE)); 

2. Paste this token into the hidden form field (using the form_open helper)

3. The user submits the form and the server receives the token through POST. CI checks the token in the function "_sanitize_globals ()" in the input class:

 $this->security->csrf_verify(); 

4. The function "csrf_verify" only for checking the security class is POST ['token'] set and POST ['token'] equal to COOKIE ['token'];

 public function csrf_verify(){ // If no POST data exists we will set the CSRF cookie if (count($_POST) == 0) { return $this->csrf_set_cookie(); } // Do the tokens exist in both the _POST and _COOKIE arrays? if ( ! isset($_POST[$this->_csrf_token_name]) OR ! isset($_COOKIE[$this->_csrf_cookie_name])) { $this->csrf_show_error(); } // Do the tokens match? if ($_POST[$this->_csrf_token_name] != $_COOKIE[$this->_csrf_cookie_name]) { $this->csrf_show_error(); } // We kill this since we're done and we don't want to // polute the _POST array unset($_POST[$this->_csrf_token_name]); // Nothing should last forever unset($_COOKIE[$this->_csrf_cookie_name]); $this->_csrf_set_hash(); $this->csrf_set_cookie(); log_message('debug', "CSRF token verified "); return $this; } 

Why not store the token in the session? IMHO just checks POST ['token'] is not empty and equal to COOKIE ['token'] is not enough, because both can be sent by an evil site.

Answer 1

In CodeIgniter, they do not use native PHP sessions anywhere in the code.

The above example is shown using native PHP sessions.

When using the SessionIgniter Session class: either store data through cookies, or store it in a database. [link: http://codeigniter.com/user_guide/libraries/sessions.html ]

Checking the csrf data, it would be pointless to check the database every time, it would be plausible to store them in cookies.

I think this is generally safe, but there are some vulnerabilities in this method. Perhaps server key encryption can help increase security ...

EDIT:

https://code.djangoproject.com/wiki/CsrfProtection#Sessionindependentnonce

The article says that CSRF protection with session-independent nonce (used by CodeIgniter) has a vulnerability for CSRF + MITM Attack ( Man-in-the-Middle ):

An attacker can set the CSRF cookie using Set-Cookie, and then provide the appropriate token in the data of the POST form. Since the site does not bind the session cookie to CSRF cookies, it cannot determine that the CSRF + cookie token is genuine (does hashing, etc. of one of them will not work, since the attacker can simply get a valid pair from the site directly, and use this couple in attack).

To a large extent, the csrf_verify () function checks if the cookie and POST of the message are equal, which can be created using simple javascript. You should think twice about using this if you are serious about security.

Source: How does this Man-In-The-Middle attack work?

Answer 2

There are several reasons.

The first thing is that storing a token in a cookie is unsafe. Anti-CSRF is not intended to prevent automatic publication of content, which means that it should not push the request as an authenticated user (via an iframe or a simple link). Until the token itself guesses, this is enough.

Second, if it is stored in a session, then you need sessions, it also causes usability problems, because if your session ends and you have an open page with a form, you can no longer submit this form (even if the form itself does not require a registered state).

Answer 3

Because CSRF stands for Cross-Site Request Forgery. An example of such an attack would be if you knew someone had installed Wordpress at http://somedomain.com/wordpress . You can get them to click on the new link, which will really do something bad in the WordPress dashboard. The CSRF was designed to prevent this by confirming that the action taken was intended for the user taking the action.

Even if someone knew how to fake both the cookie and the hidden form field to match, there is no way to make this cross-site, and there is no fake to prevent anyway.