私が理解している限り、クロスサイト リクエスト フォージェリ攻撃は、サーバー側の状態を変更するために「のみ」使用されていました。
推定:
- REST Web アプリケーションがあり、HTTP GET 要求がアプリケーションの永続的な状態を変更しない (副作用がない) ことを確信しています。
- セッション固有のキーを使用してリクエストを承認します
GET リクエストのセッション固有のキーを確認する必要がありますか?
私が理解している限り、クロスサイト リクエスト フォージェリ攻撃は、サーバー側の状態を変更するために「のみ」使用されていました。
推定:
GET リクエストのセッション固有のキーを確認する必要がありますか?
それぞれがさまざまなCSRF攻撃ベクトルによって悪用される可能性があるため、実際にはリクエストメソッドの問題ではありません(GETとPOSTは両方とも永続的な状態に変更を加えることができます)。「セッション固有のキー」について話すときは、シンクロナイザー トークン パターンについて話していると思います (これについては、.NET 開発者向けの OWASP トップ 10 パート 5: クロスサイト リクエスト フォージェリ (CSRF) を参照)。これは明らかに、サード パーティのオーケストレーションの下でブラウザがユーザーに代わって不正なリクエストを行うのを防ぐことを目的としています。
したがって、問題は本当に「私のアプリには CSRF に対する保護が必要ですか?」ということです。とにかく、アプリの永続データに変更はないように思われるため、表面的には答えは「いいえ」です。通常、アンチ リクエスト フォージェリ トークンは、CSRF 攻撃が悪影響を与える場所でのみ見つかるため、心配する必要はないように思えます。