JSON WebトークンまたはセッションCookieにIPアドレスを配置する
私はセキュリティに比較的慣れていないので、作成しているWebアプリケーションへのブルートフォースログインを防止したいと考えています。
いくつかの調査を行った後、ユーザーが一定の時間内にログインを試行しすぎたときにキャプチャを要求することにしましたが、これに関するベストプラクティスに関するドキュメントは多くありませんが、単純な例とオープンソースパッケージがたくさんあります（私はそれらがどのようにそしてなぜ働くかについてのより深い理解なしに使うのをためらいます）。
私はすでにセッションを設定しているので、セッショントークン自体にIPアドレスを含め（これはすべて暗号化されています）、特定の時間内に特定の回数のログイン試行のみが行われるようにクロスチェックすることを考えていました。キャプチャが必要です。送信者のIPアドレスがセッションのIPと一致することを確認できるため、セッションの盗用を防止できるというメリットがあると私は考えていました。
このアプローチはうまくいくでしょうか、それとも危険信号を発しますか？
考えるべきことがいくつかあります。
ログインの試行は、クライアントが有効なセッションCookieを送信した場合にのみ有効であることを確認する必要があります。そうしないと、攻撃者はセッションCookieを送信できなくなり、ログインを試みるたびに攻撃者のために新しいCookieを生成できます。それは解決するのが難しい問題のようです。攻撃者が望んでいない場合、どのようにして攻撃者にCookieを送信させるのですか？
ログイン試行がすべて同じIPアドレスから行われると想定するのはなぜですか？複数のIPから攻撃が仕掛けられた場合はどうなりますか？
攻撃者が1人のユーザーを攻撃しようとせず、ユーザー名とパスワードの全範囲を試みた場合はどうなりますか？つまり、進行中の攻撃を検出することはできません。これは、ユーザーが連続して何度もログインを試行することがないためです。
IMO、クライアントが誰であるかに関係なく、またセッションCookieを取得するか、ない。
オープンソースパッケージ（主流のディストリビューションに同梱されている安定した評判の高いパッケージ）は、オープンソースアドバイス;よりもはるかにリスクが低く、悪いアドバイスが山ほどあります。ところで、このアドバイスはかなり合法です！ ;）
したがって、健康的な懐疑論（パラノイアではない）はセキュリティに役立ち、良いスタートを切ることができます。
一般的に：1.連携するには、複数の保護が必要です。最後に、少なくともある程度はすべての脅威をカバーしているかどうかを調べてください。 2.すべての状況で完全に防止することはすばらしいですが、ほとんどの場合、ターゲットを絞っていない攻撃者にとって不経済になるように障壁を高くすることで十分です。
すなわち：
- 一般的に、私はユーザーとしてキャプチャを嫌います。したがって、私が開発したシステムではそれらを使用しません。私がそれに耐えなければならない場合、CloudFlareが使用するような単純な障壁（上記の原則2を参照）が私が好むものです。最後に確認したのは、サーバー側の分析（ボットリクエストが一般に人間とは異なる頻度で発生する方法）、ブラウザの特性を検出するためのいくつかのJS（ボットは一般にUA文字列のスプーフィングで停止する）、ボットをスローダウンするために挿入された1秒未満の遅延の組み合わせですでも人間などには気づかれない.
- ログイン試行の失敗が繰り返し検出されたときにキャプチャを使用することについて言及しました。これは良い方法です。サーバー側のチェックを使用していることを示しています。
- @ blownie55と@Pascalで言及されているローミング/動的IPアドレスの問題のため、推奨されませんが、より多くのサーバー側のチェックが可能です（必要に応じてIPアドレスのチェックを含みます）。 CookieにIPアドレスを保存する必要はありません。リクエスト自体からいつでもそれを取得し、セッションに対して格納されているプロパティと照合することができます。
- 場合によっては、ブルートフォース攻撃が進行中であることを検出すると、「攻撃的なIPアドレスを一時的にブロックする」ことがあります。アセットドメインの攻撃者の性質に応じて、30分から1日までのすべてが機能するはずです。一般的に、リスクの高いドメインはより長いブロックが必要です。使用量の多いドメインでは、ブロッキングを短くする必要があります。危険な大量ドメインには、侵入する哲学者が必要です。:)
お役に立てれば。