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

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

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

ショッピングカートフォームには複数の有効な入力がある可能性があるため、これは理にかなっています。攻撃者が行う必要があるのは、Webサイトが販売しているアイテムを知っていることだけです。

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

ただし、トークンはユーザーのログインフォームにセキュリティを追加しますか？これにはユーザー名とパスワードが必要ですか？

ユーザー名とパスワードは非常に一意であるため、攻撃者はログインフォージェリが機能するために（トークンが設定されていなくても）両方を知っている必要があり、攻撃者がすでにそれを知っている場合は、Webサイトにサインオンするだけです彼自身。言うまでもなく、ユーザーを自分でログインさせるCSRF攻撃は、いずれにしても実用的な目的はありません。

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

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

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

この脆弱性は次のように発生します。

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

適切な例として、YouTubeを検討してください。YouTubeではユーザーが「自分の」視聴履歴の記録を見ることができ、ログインフォームにはCSRFの脆弱性がありました。その結果、攻撃者は自分が知っているパスワードを使用してアカウントを設定し、そのアカウントを使用して被害者をYouTubeにログインさせ、被害者が見ている動画をストーキングする可能性があります。

このコメントスレッドには、そのようなプライバシー違反に「のみ」使用される可能性があることを示唆する議論がいくつかあります。おそらく、しかしウィキペディアのCSRF記事のセクションを引用すると：

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

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

あなたの理解は正しいです。CSRFの要点は、攻撃者が事前に正当に見えるリクエストを偽造できることです。ただし、攻撃者が被害者のユーザー名とパスワードを知らない限り、ログインフォームを使用してこれを行うことはできません。その場合、より効率的な方法で攻撃（ログイン）できます。

最終的に攻撃者ができることは、セキュリティシステムが一定期間ユーザーをロックアウトする可能性がある場合に、失敗したログインをスパムすることによってユーザーに不便をかけることだけです。

はい、そのため、他のWebサイトはログインフォームを模倣できません！それと同じくらい簡単です。

彼らはそれを行うことによって何を達成できますか？

• 最初に、あなたはそれを許可したくありません。
• 2番目：次のような非常に単純な失敗の場合でも
  • パスワードが正しくないため、ユーザーをブロックしていますn。の場合、回避することができます。
  • フレーズハッキングアラートを防止できます。などなど

CSRF検証の事前ログインは、私見ではあまり意味がありません。

リンクの@squiddleのおかげで：seclab.stanford.edu/websec/csrf/csrf.pdf、最初のページで読むことができます：

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

ログイン前にCSRF検証を試みると、潜在的な攻撃者にWebサイトの有効なコードをこする機会が与えられます。その後、彼/彼女は目的を打ち破ってトークンを再投稿することができます。

おそらく、攻撃者はサイトのユーザー名を推測しようとする可能性があります。私がやったこと、IPアドレスが成功せずに10人のユーザー名を推測しようとした場合、私は単にそれをブラックリストに載せます。