リクエストごとのXSRFトークンはどのように機能しますか？ （角解）
アプリケーションをXSRFから保護したい。私は問題が何であるか、そして私の解決策がどのように機能するかを本当に理解することはできませんでしたが、いくつかの調査の後に私はAngularを使用する解決策を思いつきました。私が得た限り、私の解決策は次の手順：
- クライアントが私のSPAのリクエストを送信します。
- XSRFトークンを送信します（JSがそれを読み取ることができるように、HTTPのみではありません）。また、このXSRFトークンをサーバーのユーザーセッションに保存します。
- POSTリクエストごとに、クライアントにXSRFトークンを読み取って
X-XSRF-TOKENこのトークンのヘッダー。 - リクエストヘッダーとユーザーセッションのXSRFトークンが一致するかどうかを確認することで、すべてのリクエストを確認します。サポートしている場合は、必要に応じてJWTで認証を確認します。
- XSRFトークンを検証した後、データベースに変更を加えます。また、XSRFトークンを再度変更し、新しいトークンをユーザーに送信して、セッションのトークンを変更します。
しかし、XSSの脆弱性がある場合、これがどのように役立つのかはわかりません。挿入されたJavaScriptコードでも同じことができるためです。問題とそのような解決策がどのように役立つかを理解したいと思います。
参考までに、セッション管理にRedisを使用して、JWTベースの認証もExpressサーバーに実装しています。
計画は良いですか？
あなたの計画は私にはよさそうだ。 CSRFトークンの使用は、この種の問題の標準的な解決策です。しかし、インターネット上の見知らぬ人から見た目が良さそうだからといって、安全だと感じるべきではありません。自分が何をしていて、なぜかを理解していることを確認してください。
（マイナーなポイント：リクエストごとにトークンを変更する必要があるかどうかはわかりません。）
なぜそれが機能するのですか？
から この古い答え 私の：
攻撃者は、自動的にPOST to
http://evil.com]を実行するフォームを含むhttp://bank.com/transfer?to=evilHacker&amount=1000000を訪問するように被害者を騙します。被害者がすでに銀行にログインしている場合、CookieブラウザによってセッションIDが通常どおり送信され、被害者が実際に送金するつもりがなかったことを銀行サーバーが知る方法はありません。これは、ブラウザがCookieをセッションIDとともにbank.comに送信します。では、CSRFトークンはどのように役立つのでしょうか。
bank.comが常にそのセッションに固有のランダムトークンがリクエストに存在することを確認する場合、そのサイトを実行している悪意のあるハッカーはトークンが何であるかを知らないため、evil.comはリクエストを偽造できません。
しかし、XSSはどうでしょうか？
あなたの質問で言うように、XSSの脆弱性がある場合、これは役に立ちません。実際、その場合に役立つCSRF保護はありませんが、XSSに対して脆弱である場合は、とにかく心配するCSRFトークンを盗むよりも大きな問題があります。
したがって、ここで行う唯一のことは、XSS保護に取り組むことです。