10

最近攻撃され、攻撃者がリモート フォームの送信を繰り返し送信したコードをいくつか継承しました。

ユーザーごとに作成するセッション認証トークンを使用して防止を実装しました(セッション ID ではありません)。この特定の攻撃がCSRFではないことはわかっていますが、これらの投稿からソリューションを適応させました（日付はありますが）。

ただし、ここにはまだ脆弱性があると感じています。100%安全なものはないことは理解していますが、いくつか質問があります。

  • 潜在的な攻撃者は、単純に有効なセッションを開始し、各リクエストに (Cookie を介して) セッション ID を含めることはできませんか?
  • nonceはsession tokenよりも優れているようです。nonceを生成して追跡する最良の方法は何ですか?
  • これらのソリューションが単一のウィンドウにすぎないといういくつかの点に出くわしました。誰かがこの点について詳しく説明できますか?
  • これらのソリューションは常にセッションを必要としますか? または、これらのトークンはセッションなしで作成できますか? UPDATE、この特定のページは単なる 1 つのページ フォーム (ログインなし) です。そのため、トークンを生成するためだけにセッションを開始するのは過剰に思えます。
  • セッションを使用しないこの特定の攻撃から保護するために実装できる、より単純なソリューション (CAPTCHA ではない) はありますか。

最終的には、より堅牢なソリューションを実装できるように、理解を深めたいと考えています。

4

1 に答える 1

9

私が理解している限りでは、3 つのことを行う必要があります: すべてのデータ変更アクションを POST 要求でのみ使用できるようにし、有効なリファラーのない POST 要求を禁止し (同じドメインからのものである必要があります)、各 POST 要求で認証トークンを確認します ( POST トークンの値は、Cookie のトークンと同じである必要があります)。

最初の 2 つは、有害な CSRF リクエストを実行することを非常に困難にします。これは、通常、電子メールや他のサイトなどに隠されている画像であり、有効なリファラーを使用してクロスドメイン POST リクエストを作成することは、最新のブラウザーでは不可能/困難なはずです。これにより、ユーザーの Cookie を盗んだりトラフィックをスニッフィングしたりすることなく、有害なアクションを実行することが完全に不可能になります。

あなたの質問について：

  1. この質問は本当に私を混乱させます: 認証トークンを正しく使用している場合、攻撃者は Cookie からユーザーのトークンを知ってリクエストと共に送信する必要があります。
  2. nonces はすべてのリンクを醜くします - 私はもうそれらを使っている人を見たことがありません。そして、データベース内のすべての通知を保存/検索する必要があるため、サイトを使用してドーズできると思います-通知を生成するための多くの要求により、データベースのサイズが非常に速く増加する可能性があります(検索は遅くなります)。
  3. (2) Dos 攻撃を防ぐために user_id ごとに 1 つの通知のみを許可する場合、ユーザーがページを開いて別のページを開き、最初のページを送信すると、新しい通知が生成され、古い通知が既に生成されているため、要求は拒否されます。無効。
  4. Cookie、GET、または POST 変数など、セッション ID なしで一意のユーザーを識別するには、他にどのような方法がありますか?

UPD: もう CSRF について話しているわけではないので、スパイダーボットがフォームを送信するのを防ぐ多くのあいまいな防御を実装することができます:

  1. 入力してはならない非表示のフォーム フィールド (ボットは通常、ユーザーに対して実際には非表示になっている場合でも、適切な名前を持つほとんどのフォーム フィールドに入力します)
  2. Javascript マウス トラッカー (記録されたマウスの動きを分析してボットを検出できます)
  3. ファイル リクエスト ログの分析 (ページが読み込まれると、ほとんどの場合、javascript/css/images も読み込まれますが、一部の (非常にまれな) ユーザーはそれをオフにしています)
  4. Javascript フォームの変更 (非表示 (または非表示) フィールドが、サーバー側で必要な JavaScript を使用してフォームに追加された場合: 通常、ボットは JavaScript を実行しません)
  5. Snort などのトラフィック分析ツールを使用して、ボットのパターン (奇妙なユーザー エージェント、フォームの送信が速すぎるなど) を検出します。

しかし、結局のところ、一部の最新のボットは、実際のユーザーの動作を完全にエミュレートします (実際のブラウザー API 呼び出しを使用)。そのため、誰かが本当にサイトを攻撃したい場合、このような防御策は役に立ちません。今日の CAPTCHA でさえ、あまり信頼性が高くありません。複雑な画像認識アルゴリズムに加えて、人間が解決した 1000 個の CAPTCHA を任意のサイトでわずか 1 ドルで購入できるようになりました (このようなサービスは主に発展途上国で見つけることができます)。実際には、ボットに対する 100% の防御はありません。ケースごとに異なります。複雑な防御システムを自分で作成する必要がある場合もあれば、少し調整するだけで役立つ場合もあります。

于 2011-08-03T15:47:13.113 に答える