サーバーからAngularJSクライアントへのCSRFトークンの交換

Question

私はWebアプリケーションのCSRF保護を実装する方法を究明しようとしています。私は数多くのページを読んだことがありますが、私の特定の状況で解決策を決めることはできません。

まず、WebアプリケーションはAngularで書かれ、Apacheサーバーに静的にデプロイされます。これは、アプリケーションサーバー上の戦争で展開された、サーバー上のJava型のサービスを呼び出します。両方とも同じドメインに配置されています。認証後、通常のセッションCookie（secure + HttpOnly）が応答に設定されます。

シンクロナイザトークンまたはダブルサブミットクッキーパターンに基づいてCSRF保護を実装したいと思います（ただし、サーバー側で状態を処理できるため、最初の方が優れたソリューションです）。

私が見たソリューションのほとんどは、トークンサーバー側を生成し、クライアント側でアクセスできるようにクッキーに格納することを提案しています。これがうまくいくための制約、そして私はそれが大きなものだと思います.Javascriptがアクセスできないので、クッキーはHttpOnlyにできません。さらに、私は完全に保護されていないクッキーでトークンを共有することは良い考えではないと感じています。しかし、それはAngularJSから推奨される解決策だと思われます...

私はこのソリューションを捨てると何が残っていますか？ トークンをクッキーに入れるのではなく、応答ヘッダーに入れる？それは安全ですか？ サービスを公開してトークンを取得しますか？実用的だが、それが良い考えであるかどうかわからない？ OWASP Guardのように、トークンを提供するためにJavascriptを構築するサーブレットを公開しますか？ 他に何か？

EDIT：解決策として、HTTPレスポンスでトークン名と値を注入しようとしているようです。

ありがとうございました！

Answer 1

1. CSRFトークンは、ユーザーセッションごとに1回生成されます。
2. サーバー側セッション（Javaの場合はHttpSession）に格納する必要があります。
3. クライアントは、ブラウザのクッキーに隠されたパラメータとしてトークンを格納する必要があります。
4. サーバーは、要求ごとにCSRFトークンの存在を検証し、セッションに格納されているトークンと比較する必要があります。

詳細：https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet