web-dev-qa-db-ja.com

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

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

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

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

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

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

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

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

phptokencsrf
139
php_learner

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

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

脆弱性は次のようになります。

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

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

このコメントスレッド には、そのようなプライバシー違反に対して「のみ」使用できることを示唆する議論があります。おそらく、しかし WikipediaのCSRF記事 のセクションを引用するために：

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

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

109
natevw

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

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

12
Jon

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人のユーザー名を推測しようとした場合、私は単にそれをブラックリストに載せます。

0
Patrice Gagnon

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

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

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