1

アンチ CSRF トークンを使用して CSRF を防止する方法について学習しています。基本的に、アイデアは次のとおりです。

1) Md5 や Sha1 などのトークンを生成し、この値をセッション変数に保存します。

$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;

2) すべてのフォームは、POST 非表示フィールドにこのトークン値を含めます

<input type='hidden' name='token' value='$nonce_token' />

たとえば、ソースコードでユーザーにどのように見えるか:-

<input type='hidden' name='token' value='9ee66e4e63a06ee4b83a3edde4ecd587' />

3）フォームが送信されたら、POST隠しフィールドのトークン値がセッション値に保存されているトークンと一致することを確認します

if($_POST['token']==$_SESSION['token']){...ok...}

ただし、トークン値を非表示の POST フィールドに含めることにより、攻撃は単に Web サイトのソース コードを見てトークンを確認し、これを悪意のある生成された POST フォームに含めることができるため、このプロセスには少し欠陥があるようです。送信されたトークン値がセッション変数のトークン値と一致するため、受信すると成功します。これは、基本的に非表示フィールドのトークン値を攻撃者に表示するためです。

したがって、私の質問は、これを回避する最善の方法は何かということです.

1) 代わりに _GET を使用しますが、これにはまだ _POST のような欠陥があります

2) x 分後または各リクエスト後にトークン値を変更するが、ブラウザーに戻るときに使いやすさの問題が発生するか、ユーザーが入力しているフォームとトークン値が更新されたセッション トークン値と比較して古くなったときに失敗します。フォームへの記入。

3) 非表示の POST フォーム トークン値を暗号化してから、POST の送信時に復号化を試みますが、既にハッシュされた値の暗号化/復号化は複雑に思えます。

どんなアイデアでも大歓迎です。

4

4 に答える 4

3

必要なことは、非表示フィールドをセッション ID の MD5 または SHA1 ハッシュにソルトで作成することです。このようにして、送信された値をセッション ID とソルトのハッシュと比較し、一致する場合は有効です。攻撃者がトークンを推測できる場合、セッション ID は既に盗まれており、ログインは既にハイジャックされているため、これ以上保護する必要はありません。それは本当にそれと同じくらい簡単です。CSRF https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheetを防ぐ方法に関するOWASPごとの優れた情報を次に示します

于 2012-11-11T10:51:50.270 に答える
2

ただし、トークンの値を非表示の POST フィールドに含めることで、攻撃は Web サイトのソース コードを見るだけで済むため、このプロセスには少し欠陥があるようです。

いいえ、できません。

アリスはウェブサイトを運営しています。ボブは Web サイトにアクセスします。マロリーはボブのアカウントを攻撃しています。

Bob が Alice の Web サイトにアクセスすると、nonce トークンを取得します。

Mallory がそのサイトを訪れた場合、Mallory は別のnonce を取得します (Mallory には別のセッションがあるため)。

マロリーが (自分の Web サイトで) 悪意のあるデータを含むフォームを生成し、ボブをだましてそれを送信させた場合、マロリーがフォームに入力したナンスはボブのセッションのナンスと一致せず、送信は拒否されます。

于 2012-11-11T10:50:02.087 に答える
2

攻撃シナリオを確認しましょう。

  1. にサーバーがexample.comあり、フォームで CSRF トークンを使用します。
  2. 各 CSRF トークンは一意で、ユーザーに固有であり、一定期間のみ有効です。
  3. 悪意のあるサード パーティの Eve が、ユーザーの 1 人である Alice をだまして彼女のサイトにアクセスさせ、CSRF 攻撃を仕掛けようとします。
  4. Eve が単純に Alice をだまして CSRF トークンなしでサーバーにフォームを送信させると、サーバーはそれを拒否します。
  5. Eve もサーバーにアカウントを持っていて、フォームで送信するトークンを取得しようとすると、トークンが Alice に対して有効でないため、これは失敗します。

これにより、次のシナリオが残ります。Eve は Javascript を使用してサーバーからAlice としてフォームを取得し、有効なトークンを含めてこのフォームを送信します。つまり、Eve は Javascript を使用して、通常のフォーム送信のプロセス全体で完全に Alice になりすます。これは、Same Origin Policyによって防止されます。Eve の Javascript は、サーバーから情報を取得できません。Alice のブラウザは、Same Origin Policy に違反しているため、これを防止します。

つまり、Eve がそのポリシーを回避できるセキュリティ ホールがブラウザにないと仮定します。これはまた、XSS、つまり Eve が自分のスクリプトの 1 つを Web サイトに挿入できないようにする必要があることを意味します。そのため、サイトへの通常の訪問者は、同じオリジンからサイトの一部として Eve のスクリプトを実行します。

ちょっとした自己宣伝として、署名ベースの CSRF トークン ライブラリを実装しました。Kunststube\CSRFPを参照してください。また、私が取り組んでいる間に、それに対する査読と批判を求めたいと思います.

于 2012-11-11T11:37:49.663 に答える
1

最初に、ハッカーによるアプリケーションへの攻撃を防ぐことはできず、事態をより困難にすることができるということを覚えておく必要があります。

CSRF 攻撃の主な目的は何かを考えると、その考えは明確になります。CSRF は、被害者をだまして悪意のある要求を含むページをロードさせる攻撃です。被害者の ID と特権を継承して、被害者の電子メール アドレス、自宅の住所、パスワードを変更したり、何かを購入したりするなど、被害者に代わって望ましくない機能を実行するという意味で悪意があります。CSRF 攻撃は通常、サーバーの状態を変更する機能を対象としていますが、機密データへのアクセスにも使用できます。

上記のように、攻撃者はあなたの Web ページを直接攻撃するのではなく、ブリッジが必要です。つまり、被害者が必要なので、被害者の ID と特権を使用してアクションを実行できます。

あなたが言ったとき：

ただし、トークンの値を非表示の POST フィールドに含めることで、攻撃は Web サイトのソース コードを見るだけで済むため、このプロセスには少し欠陥があるようです。

攻撃者は自分自身を攻撃しないため、意味がありません。

これが助けになることを願っています。

于 2012-11-11T11:01:25.613 に答える