2016-07-07 11 views
1

私は現在、これらの2つの機能、トークン生成するための1と妥当性をチェックするための1持っている:セキュリティ保護されたフォームと同じページにCSRFトークンを生成するのは安全ですか?

function getToken() { 
    if(isset($_SESSION['token'])) { 
     return $_SESSION['token']; 
    } else { 
     $token = //random key generator goes here; 
     $_SESSION['token'] = $token; 
     return $token; 
    } 
} 

function validateToken($token) { 
    if ($token == getToken()){ 
     return true; 
    } else { 
     return false; 
    } 
} 

をそして、私の登録フォームは、この隠された入力を含む:

<input type="hidden" name="token" value="<?php echo getToken(); ?>"> 

は、この安全ですか?正当なユーザーのセッションが期限切れになり、CSRFがこの登録フォームに登録され、悪意のあるサイト/ iframe自体によってトークンが生成される場合、セッションにまだ存在していないので、それでうまくいくので、私は尋ねています。

クッキーのためにユーザーがログインしていると仮定します。

ここで間違って理解していますか? iframeのようなリモートリンクはバックエンドでセッションを生成できませんか?

+0

...セッションはこれよりも安全性が低いのはなぜですか? – Machavity

+0

@Machavity申し訳ありませんが、あなたが何を言おうとしているのか理解できません。私は、私のアプローチが安全であるかどうかを尋ねるのは、フォームとちょうど同じページにトークンを生成することが目的を敗北させると想像しているからです。 –

+0

"フォームと同じページにトークンを生成する" ---どういう意味ですか? CSRFトークンを推測することは不可能でなければなりません。これが唯一の要件です。 – zerkms

答えて

0

いいえ私が知る限り、ユーザーがフォームページに来たらすぐにトークンを生成しなければならないので、正しい方法で行っています。次に、誰か(実際のユーザー)があなたのフォームに実際にアクセスしたことを確認してから、それらのトークンを設定していることを確認するために生成します。

フォームでアクションを実行するときに、トークンをチェックしてそのトークンがそのユーザーに有効かどうかを確認します。それで、あなたは正しいことをしていると思います。

トークンを生成して、ユーザーがフォームページにリクエスト/来たときにトークンを生成してセッションに保存します。要求が来るたびに生成する方が良いでしょう。その後、フォームの送信が成功するたびに、チェックされたトークンをセッションからクリアします。

+0

"リクエストが来るたびに生成する方が良いでしょう。" ---それは確かに痛いでしょうが、セキュリティの観点からは、なぜそれが "より良い"べきか明確ではありません。 – zerkms

+0

セッションがトークンを保存する時間が短いため、セッションのハイジャックを防ぐのに役立ちます。 –

+0

セッションを盗んだら、CSRFとどのように関連していますか?あなたはセッションIDを持っています - ページに行き、生成されたばかりのトークンでリクエストを実行します。私が言っていたのは – zerkms

関連する問題