なぜcodeigniter2はセッションのようにより安全な方法でcsrf_hashを保存しないのですか？

Question

生成されたCSRF保護トークンが保存されず、提案されたhereのようにSESSION経由で使用されるのはなぜですか？現在CI2で、（Securityクラス内）CSRFの保護メカニズムは、次のとおりです。

1.generate _csrf_set_hashでCSRFトークン（）関数のためのユニークな値：隠されたフォームにトークン

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

2.Insertフィールド（form_openヘルパーを使用）

3.ユーザーがフォームを送信し、サーバーがPOSTによってトークンを取得します。セキュリティクラスの

$this->security->csrf_verify(); 

4。機能「csrf_verify」だけチェックPOST [「トークン」]に設定し、POSTである[「トークン」である：CIは、入力クラスの関数が「）_sanitize_globals（」トークン検証を行います] 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; 
} 

なぜセッションにトークンを格納しないのですか？ IMHOはPOST ['token']が空ではなく、COOKIEと等しい['token']は悪いサイトから送信される可能性があるため、十分ではありません。

Answer 1

CodeIgniterでは、コード内のどこでもネイティブのPHPセッションを使用しません。

提供したサンプルは、ネイティブのPHPセッションを使用して表示されます。

CodeIgniter Sessionクラスを使用している間は、クッキーを介してデータを保存するか、データベースに保存します。 [参照：http://codeigniter.com/user_guide/libraries/sessions.html]

csrfデータをチェックしている間は、毎回データベースをチェックすることは意味がありません。クッキーに保存するのが妥当でしょう。

一般的には安全だと思いますが、この方法にはいくつかの脆弱性があります。おそらく、

EDIT

...セキュリティの向上に役立つかもしれないサーバー側のキーで暗号化：

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

が記事によれば、CSRF保護はセッションの独立したナンスと（CodeIgniterのが使用することを言います）CSRF + MITM攻撃（Man-in-the-Middle）に対する脆弱性を有している：

攻撃者がのSet-Cookieを使用してCSRFクッキーを設定し、を供給することができ10は、POSTフォームデータ内の一致するトークンである。サイトでは のセッションクッキーをCSRFクッキーと結びつけていないので、 というCSRFトークン+クッキーが本物であると判断する方法はありません（ のハッシングなどを行うと、攻撃者は直接サイト の有効なペアを使用し、そのペアを攻撃に使用します）。かなり

、クッキー、入力POSTの両方が単純なジャバスクリプトを使用して作成することができ、 等しいかどうか関数csrf_verify（）のみをチェックします。セキュリティを真剣に考えているなら、これを使うことについて二度考えなければなりません。

出典：How does this Man-In-The-Middle attack work?

Answer 2

いくつかの理由があります。

まず、トークンをクッキーに格納することは安全ではないことです。 Anti-CSRFは、コンテンツの自動投稿を防ぐようには設計されておらず、認証されたユーザーとしての要求を偽造することも防ぎます（iframe経由、または単純なリンク経由）。トークン自体が推測できない限り、それで十分です。

セッションに保存されているセッションが有効になっている必要があります。セッションがタイムアウトしてフォームが開いている場合でも、そのフォームを送信できなくなるフォーム自体にログイン状態が必要ない場合）。

Answer 3

CSRFは「クロスサイトリクエスト偽造」を表しているためです。この攻撃の例は、誰かがワードプレスをインストールしていることがわかっていれば、http://somedomain.com/wordpressになります。新しいリンクをクリックすることができます。実際には、WordPressのコントロールパネルで何か悪いことが起こります。 CSRFは、これを防ぐために、ユーザがアクションを取ることによって意図されたアクションが実行されたことを検証しました。

誰かがクッキーと隠れたフォームフィールドの両方を偽造する方法を知っていたとしても、そのクロスサイトを行う方法はなく、とにかく防ぐための偽造はありません。