ログインフォームにはCSRF攻撃に対するトークンが必要ですか? 質問する

ログインフォームにはCSRF攻撃に対するトークンが必要ですか? 質問する

これまでに学んだことから、トークンの目的は、攻撃者がフォーム送信を偽造するのを防ぐことです。

たとえば、Web サイトにショッピング カートにアイテムを追加する入力フォームがある場合、攻撃者は不要なアイテムをショッピング カートにスパム送信する可能性があります。

これは理にかなっています。なぜなら、ショッピング カート フォームには複数の有効な入力が存在する可能性があるため、攻撃者は Web サイトで販売されている商品を知るだけでよいからです。

この場合、トークンがどのように機能し、セキュリティが追加されるかを理解しています。トークンにより、ユーザーがカートに追加された各アイテムのフォームに実際に入力し、「送信」ボタンを押したことが保証されるからです。

しかし、トークンはユーザー名とパスワードを必要とするユーザー ログイン フォームにセキュリティを追加するのでしょうか?

ユーザー名とパスワードは非常に固有であるため、ログイン偽装を機能させるには、攻撃者はその両方を知っている必要があります (トークンが設定されていない場合でも)。また、攻撃者がすでにそれを知っていれば、攻撃者は自分で Web サイトにサインオンできます。言うまでもなく、ユーザーに自分でログインさせる CSRF 攻撃には、実際的な目的はありません。

CSRF 攻撃とトークンについての私の理解は正しいでしょうか? また、私が疑っているように、それらはユーザー ログイン フォームには役に立たないのでしょうか?

ベストアンサー1

はい。一般的に、他のフォームと同様に、ログインフォームを CSRF 攻撃から保護する必要があります。

そうしないと、サイトは一種の「信頼されたドメイン フィッシング」攻撃に対して脆弱になります。つまり、CSRF に対して脆弱なログイン ページにより、攻撃者は被害者とユーザー アカウントを共有できるようになります。

この脆弱性は次のように現れます。

  1. 攻撃者は信頼されたドメインにホストアカウントを作成します
  2. 攻撃者は、このホストアカウントの資格情報を使用して、被害者のブラウザにログイン要求を偽造します。
  3. 攻撃者は被害者を騙して信頼できるサイトを利用させ、ホストアカウントでログインしていることに気づかせない可能性がある。
  4. 攻撃者は、被害者がブラウザにホストアカウントでログインしている間に(意図的または意図せずに)「作成した」データやメタデータにアクセスできるようになります。

適切な例として、ユーチューブYouTubeはユーザーが「自分の」視聴履歴を見ることを許可しており、ログインフォームはCSRFに対して脆弱でした。その結果、攻撃者はパスワードを使ってアカウントを設定できました。彼らは知っていたなら、被害者をYouTubeにログインさせてそれアカウント — 被害者が視聴していた動画を追跡する。

議論があるこのコメントスレッドそれは、それがそのようなプライバシー侵害に「のみ」使用される可能性があることを意味しています。おそらく、しかし、Wikipedia の CSRF に関する記事:

ログイン CSRF により、さまざまな新しい攻撃が可能になります。たとえば、攻撃者は後で正当な認証情報を使用してサイトにログインし、アカウントに保存されているアクティビティ履歴などの個人情報を閲覧できます。

「新しい攻撃」に重点を置きます。ユーザーに対するフィッシング攻撃の影響を想像してください。さらに、そのフィッシング攻撃がユーザー自身の信頼するブックマークを介してサイトに対して行われることを想像してください。前述のコメント スレッドにリンクされている論文には、単純なプライバシー攻撃を超えたいくつかの例が示されています。

おすすめ記事