CORS JSON APIを使用したCSRF
App.example.comと通信するapi.example.comがあり、ネイティブAndroidアプリおよびiOSアプリです。必要に応じて、他のサードパーティもAPIと通信できるようにしたいと考えています。なので、Access-Control-Allow-Origin: *ヘッダーセットがあります。
/reset-passwordや/loginなど、事前認証を必要としないAPIルートがいくつかあります。
他のすべてのAPIルートには認証トークンが追加されている必要があります（例：/important-action?authtoken=abc123）。ヘッダーまたはリクエストの本文でCookieを受け入れません。 app.example.comは、セッションを保持するためにauthトークンをcookieに保存します。
私が理解するのに苦労しているのは、evil.comがこの設定をどのように利用できるかです。誰かが攻撃がどのように機能するか、または心配するのを止める方法の例をいくつか挙げて、CSRFは適用可能なリスクではないことを教えてください。
「Cookieの使用」に関連する他の回答を読みましたが、「使用する」の正確な意味が明確にされていません。この例では、authtokenをCookieに保存し、リクエストURLに追加しています。 APIは、リクエストヘッダーで送信されたCookieを無視します。
クロスサイトリクエストフォージェリでは、攻撃者が行われるリクエストを予測できる必要があります。 authtoken値を予測するのが難しいと仮定すると（つまり、大きなランダム値、ハッシュ値など）、攻撃者がリクエストを偽造することは困難です。
Access-Control-Allow-Origin: *を設定する場合は、エンドポイントが有効なトークンを反映していないことを確認する必要があります。そうでない場合、攻撃者はそこから読み取ることができます。
攻撃者がここで探らなければならない2つの可能なパスがあります。
- 認証を必要としないパスを使用して何かを行うことはできますか？
- どういうわけかトークンを入手できますか？
＃1と2つのパスを見てみましょう。 /reset-passwordパスがアカウント所有者にメールを送信するだけの場合は、あまり役に立ちません。
もう1つは/loginの方が問題です。 Access-Control-Allow-Credentials: trueも設定すると、evil.comは（トークンCookieを設定することにより）ログインを「強制」できます。これにより、 login CSRF が表示されます。これは、アプリケーションによっては、大したことではないものから非常に悪いものまでさまざまです。そのヘッダーを設定しない場合、応答のCookieは破棄され、問題ありません。
＃2に関しては、そのトークンがCookie以外の場所で使用できるかどうかによって異なります。 Originのクロスリクエストの送信者はCookieの読み取りを許可されていないため、そこからトークンを読み取ることはできません。しかし、それは別の場所に含まれているのでしょうか？おそらく、応答にauthtokenパラメータを含むURLが含まれていますか？
クライアントから送信されるときにCookie自体が認証として使用された場合、これは別の話になります。次に、ここで大きな問題が発生する可能性があります。
CSRFはさておき、URLにシークレットを入れることはお勧めしません。結局のところ、URLはブラウザーの履歴は言うまでもなく、あらゆる種類のログに記録されます。理由がない場合は、代わりにトークンをヘッダーに配置します。ヘッダーは実際にはCSRFからの保護にも役立ちます。これは、evil.comではヘッダーを設定できないためです。