「チャレンジ トークン」を使用すると、どのようにして何らかの防止策が追加されるのか理解できません。どの値を何と比較する必要があるのでしょうか?
OWASP より:
一般的に言えば、開発者が必要とするのは このトークンを一度生成します 現在のセッション。初期化後 このトークンの生成、その値は セッションに保存されて使用される 後続のリクエストごとに、 セッションの有効期限が切れ。
プロセスを正しく理解すると、これが起こります。
http://example.com にログインし、このランダムなトークンを含むセッション/Cookie を作成します。各フォームには、セッションからのランダムな値も含まれる非表示の入力が含まれており、フォーム送信時にセッション/Cookie と比較されます。
しかし、何が達成できるのでしょうか?セッション データを取得してページに配置し、まったく同じセッション データと比較するだけではありませんか?循環論法のように思えます。これらの記事は「同一生成元ポリシー」に従うことについて話し続けていますが、すべての CSRF 攻撃はユーザーから発生し、ユーザーを騙して意図しないことを実行させるだけであるため、意味がありません。
トークンをクエリ文字列として各 URL に追加する代わりに何か方法はありますか?見た目は非常に醜くて実用的ではなく、ユーザーがブックマークするのが難しくなります。
CSRF を類推で説明 - 例:
詐欺師はあなたのお金をすべて持ち去り、おそらく帰りに Xbox で遊んだかもしれません...
###まとめ###CSRF は基本的に、あなたが家のドアを開けて、そのままにしておき、他人が勝手に入ってきてあなたのふりをできるようにするという事実に依存しています。
この問題を解決するにはどうすればよいですか?
あなたが初めて家のドアを開けると、ドアマンは非常にランダムな長い番号が書かれた紙を渡します:
さて、家に入りたい場合は、その紙をドアマンに見せて中に入る必要があります。
だから
今詐欺師があなたの家に入ろうとすると、ドアマンは次のように尋ねます: 「紙に書かれた乱数は何ですか?」
偽者が正しい番号を持っていない場合、入力することはできません。彼は乱数を正確に推測する必要がありますが、これは非常に困難な作業です。さらに悪いことに、乱数は (たとえば) 20 分間のみ有効です。したがって、なりすまし者は正しく推測しなければならないだけでなく、正しい答えを得るまでの時間は 20 分しかないことを知っておいてください。これはとても大変です!それで彼は諦めた。
もちろん、このたとえは少し突飛ですが、お役に立てば幸いです。
**crud = (作成、読み取り、更新、削除)
攻撃者はトークンを取得できません。したがって、リクエストは有効になりません。
Gnucitizen によるこの記事をお勧めします。 CSRF についてはかなり詳しく説明されています: http://www.gnucitizen.org/blog/csrf-revealed/