CSRF攻撃のクイックフィックスは何ですか？
アプリケーションはJava言語とJSFフレームワークで構築されています。CSRF攻撃を報告しました。アプリケーションが本稼働しているため、開発チームはすぐに修正する必要があります。
私はCSRFトークンの使用を推奨しましたが、開発チームは実装に時間がかかる可能性があると言っています。
CSRFを修正するためのより適切で迅速な方法を提案できる人はいますか？今のところ一時的な解決策であれば、それも問題ありません。その後、適切な時間内に適切なCSRFトークンをコードに実装します。
CSRFに対する迅速な修正は、RefererまたはOrigin HTTPヘッダーをチェックすることです。これらの少なくとも1つを設定し、それに含まれるドメインをドメイン（つまり、同じオリジン）にする必要があります。
これにより、Refererが送信されないため、ブックマーク、メール内のリンクなどからサイトにアクセスする場合に問題が発生することに注意してください。ただし、攻撃者が簡単に作成できるため、空のRefererを受け入れる必要はありません（空でないOriginヘッダーがない限り）。
また、ドメインのチェックが正しいことを確認する必要があります。つまり、サイトがwww.example.comの場合、http://www.example.com.attacker.comまたはhttp://www.attacker.com/www.example.comまたはhttp://www-example.comのようにRefererを受け入れることはできません。
また、攻撃者がアプリケーションの他の機能（またはバグ）をトランポリンとして使用して、悪意のあるペイロードを含むカスタムリクエストを作成できないことを確認する必要がありますが、同じ元のRefererが期待されます。 Arminius がコメントでうまく指摘されているように、オープンリダイレクトはそのようなトランポリンかもしれません。したがって、ドメインへのすべてのリクエストが同じオリジンRefererを持っているか、クロスオリジンRefererを受け入れる必要のある部分がトランポリンとして悪用されないようにする必要があります。
CSRFから保護するこの方法とその潜在的な問題の詳細については、 Cross-Site Request Forgery（CSRF）Prevention Cheat Sheet の Verify Same Origin with Standard Headers を参照してくださいOWASP。
別の可能性は、同じサイトのCookie（SameSite=Strict;）。基本的に、この属性を有効にすると、ブラウザーがクロスサイトリクエストからCookieを送信できなくなります。これは一部の機能を壊す可能性がありますが、すぐに追加できる別のアイデアです。
https://medium.com/compass-security/samesite-cookie-attribute-33b3bfeaeb95
没落-すべてのブラウザがサポートしているわけではありません。