GETリクエストによるCSRF攻撃に対するセキュリティ？

Question

私はStormpath（https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage）の例に従って、WebサーバーにステートレスのJWTベースのユーザー認証システムを構築しました。

セットアップはCSRFに対して非常に安全だと思われますが、私はGETリクエストについてどう思っていますか？

<img>タグを別のドメインのページに含めることで、GET要求に対するCSRF攻撃をモデル化できました。サーバーは、要求に200ステータスのフルページで応答します。 GETリクエストのデータは変更されませんが、ページには機密情報が含まれている可能性があります。たとえば、<img src="https://example.com/account" />がユーザーの詳細を知らせる場合があります。<img src="https://example.com/logout" />は単に迷惑なことをする可能性があります。

この<img>の攻撃は、ブラウザがそれを取得した際の公開情報を公開しないため、無害とみなされますか？ GETリクエストへのサーバーの出力を明らかにして機密情報を漏洩させる可能性のあるHTMLタグを悪用する他のトリックはありますか？

GET URLにJWTアクセストークンのハッシュを追加し、GETリクエストにそのハッシュが含まれていることをサーバーに要求し、そのCookieのJWTトークンと一致する必要があります。このようにして、攻撃者は有効なGET URLを推測することができません。そのようなGET URLを漏らすと、攻撃者はCookieから元のJWTを知らないため、サーバーにアクセスできなくなります。この設定はマイナーな使い勝手の問題とは別に、私には良いアイデアのように見えますが、似たようなものは見つかっていませんので、疑いがあります:)

Answer 1

CSRF攻撃の概念は、彼が許可されているWebアプリケーションでの望ましくない動作。

CSRF攻撃は、被害者がに許可されているように、攻撃者にない被害者への応答を取得します、データのtheftingはGETリクエストとして関与していないステートレスサーバー用の状態変化を導入することを保証します。攻撃者が偽造された要求に対する応答を見ることはできません。

CSRF攻撃は、サーバの状態に変化をもたらすことができますが、その結果を見ることはできません。盲目的に行動することが強制されます。

たとえば、CSRF攻撃は被害者の銀行口座残高を要求するよう犠牲者のブラウザに通知できますが、攻撃者はその残高を見ることはできません。これは明らかに無意味な攻撃です。

攻撃者が犠牲者のブラウザから犠牲者のアカウントから攻撃者のアカウントに金銭の譲渡を依頼するのは無意味ではありません。転送の成功または失敗のページは、攻撃スクリプトにはアクセスできません。攻撃者は成功または失敗の反応を心配していない、彼の主な関心事は、彼は彼のアカウントにお金が欲しいとしている。

サーバーの状態を変更するためにGETリクエストを実行している場合、サーバーが危険にさらされる可能性があります。

「GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1」（リクエストが1つの場合）

私はそれがないと信じています。

したがって、CSRFトークンを使用して監視する必要があるPOSTリクエストに焦点を当てる必要があります。

OWASPルールのリンクを共有すると、https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29は一度実行する必要があります。