2009-11-26 34 views
37

これはCSRFトークンの生成に関する質問です。CSRFトークンの生成

通常、ユーザーのセッションに関連付けられた一意のデータに基づいてトークンを生成し、秘密鍵でハッシュして塩漬けします。

私の質問は、使用する一意のユーザーデータがない場合にトークンを生成することです。セッションは利用できません。クッキーはオプションではありません.IPアドレスなどは信頼できません。

リクエストの一部としてハッシュ文字列を含めることができない理由はありますか?トークン

var $stringToHash = request.get('key') 
var $isValidToken = hash($stringToHash + $mySecrtKey) == request.get('csrfToken') 

ハッシュに使用されている文字列が要求ごとに異なるであろうCSRFの

var $stringToHash = random() 
var $csrfToken = hash($stringToHash + $mySecretKey) 
<a href="http://foo.com?csrfToken={$csrfToken}&key={$stringToHash}">click me</a> 

例サーバー側の検証:トークンを生成し、それを埋め込む 例の擬似コード。各要求に含まれていれば、CSRFトークンの検証を進めることができます。各リクエストで新規であり、ページに埋め込まれているだけなので、トークンへの外部アクセスは利用できません。次に、トークンのセキュリティは、私にのみ知られている$ mySecretKeyに落ちます。

これは簡単なアプローチですか?私はこれがうまくいかない理由を見逃していますか?

おかげ

+8

を読んでお勧めします。同じトークンとキーの組み合わせが無期限に機能します。 – Matthew

答えて

2

CSRFは、通常、POSTリクエストが印加される(意図しない)データ変更を防止することを意味トークン。

したがって、データを変更するリクエスト(GETまたはPOSTリクエスト)ごとにCSRFトークンを含める必要があります。使用するNO ユニークユーザデータが存在しない場合

私の質問は 生成トークンに関してです。セッションはありません。 が利用可能です。クッキーは オプションではありません.IPアドレスなどは のものは信頼できません。

次に、訪問ユーザーごとに固有のユーザーIDを作成するだけです。 そのIDをCookieまたはURLに含めます(Cookieが無効な場合)。

編集:

は、次のイベントを考えてみましょう:

あなたは自分のFacebookアカウントに-にログインして、いくつかの任意のWebサイトに入力しました。

このウェブサイトには、送信するフォームがあります。このフォームは、ブラウザにあなたのFacebookアカウントにPOSTリクエストを送信するよう指示します。

Facebookリクエストは、登録された&ログインユーザーとしてあなたを認識したため、パスワードを変更したりコメントを追加することがあります。 (CAPTCHAのような別のブロックメカニズムがない限り)

+0

トークンの一部をURLに追加し、残りの半分をフォームに含めることはまったく保護を意味しません。 – blowdart

+0

申し訳ありませんが、どういう意味ですか?私はそれを書いていませんでした... – Dor

+0

確かに、 "そのIDをクッキーまたはURLに含めます(クッキーが無効の場合)。"あなたはURLにidを入れると言っていますが、これは単に安全ではありません。 – blowdart

-4

CSRFはユーザーのセッションを利用しているため、CSRFはありません。

+0

この回答は役に立ちませんが、技術的には正しいです。 –

25

リクエストの一部としてハッシュ文字列を含めることができない理由はありますか?

CSRFトークンには2つの部分があります。フォームに埋め込まれたトークンと他のどこかの対応するトークンは、セッション内やその他の場所に保存されたクッキー内に存在します。他の場所でのこの使用は、自己完結型のページを停止させます。

要求にハッシュする文字列を含めると、リクエストは自己完結型なので、フォームのコピーは攻撃者が行う必要があります。トークンの両方の部分を持つため、保護がありません。

フォームURLに入れても、それが自己完結型であることを意味します。攻撃者は、フォームと提出URLを単純にコピーします。

+0

サーバーに格納されているトークンを覚えておく必要があります。 –

+14

いいえ。半分はセッション中に保存することも、クッキーで削除することもできます。サーバーにはまったく格納する必要はありません。通常はセッションを有効にする必要はありません。 – blowdart

+0

OWASPによると、これは「二重送信クッキー」と呼ばれる*緩和*です。https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies – zb226

1

URL /フォームとCookieに同じ「トークン」が必要です。これは、あなたのページがトークンクッキーをJavaScriptで設定したい(望ましくは何らかのランダムな値)ように設定して、あなたのサーバーに行くすべてのリクエスト(URI?paramまたはform-フィールド)。サーバーにCookieを生成させる必要はありません。

これは、ブラウザがドメインのページを他のドメインのCookieの編集/読み取りを許可していないと確信していれば安全です。これは今日は非常に安全だと思われます。

サーバーがトークンを生成すると、CSRFの試行(なぜ危険を冒すのですか?)によってこのトークンが安全に送信されることが前提となります。サーバーで生成されたトークンにロジックを追加することはできますが、CSRFを防ぐためには必要ありません。

(私はここで間違っている場合は私に知らせてください)

0

私はすなわち、このシーケンスいくつかのパスワードで暗号化されたハッシュ行い、HMACに基づくハッシュを作るために最高のアイデアだと思います。username + USER_ID +タイムスタンプを。攻撃のハッシュを簡単に再生したくない場合は、タイムスタンプが必要です。

0

私はあなたのアプローチが働くと言うたい、CSRF攻撃するので攻撃者が犠牲者のブラウザを利用してログイン状態を偽造するのですが、どうしてそうすることができますか?ほとんどのサーバー側でセッションチェックはCookie内のSessionIDに基づいており、Cookieはサーバーに送信されたHTTP要求にCookieが自動的に付加されるためです。

そのため、CSRF

  1. を守るための2つの重要な要素があるチャレンジトークンを生成し、非クッキーの方法でサーバにそれを渡すために、クライアントが必要な、どちらかのURLのPARAMまたはPOSTフォームはokです。
  2. たとえば、SSLを使用してセッションIDに対して行った処理を安全に保ちます。

私は提案されたソリューションは、リプレイ攻撃に対して脆弱であるCSRF Prevention Cheat Sheet