web-dev-qa-db-ja.com

GETリクエストにCSRF保護を使用する必要がありますか？

GETリクエストに対してCSRF保護が必要ないという効果をウェブ上でいくつか見ました。

しかし、多くのWebアプリケーションには、機密データを返すGETリクエストがありますよね？では、CSRF攻撃からそれらを保護したくありませんか？

何か不足していますか、またはこれらの包括的なステートメントは、GETリクエストが提供するデータが重要ではないと想定していますか？

GETでCSRFトークンを使用することで得られる包括的な推奨事項の例：

web-applicationcsrf
34
jtpereyda

same-Originポリシー のため、CSRF保護は状態変更操作にのみ必要です。このポリシーは次のように述べています。

webブラウザーは、最初のWebページに含まれるスクリプトが2番目のWebページのデータにアクセスすることを許可しますが、両方のWebページが同じオリジンを持っている場合に限られます。

したがって、CSRF攻撃はクロスサイト（つまり、-[〜＃〜] cs [〜＃〜][〜＃ 〜] csrf [〜＃〜]）リクエストであり、同一オリジンポリシーにより禁止されています。したがって、不正なデータアクセスはCSRFの問題ではありません。

CSRF攻撃はコマンドを実行できますが、その結果を見ることができないため、盲目的に行動する必要があります。たとえば、CSRF攻撃では、ブラウザに銀行口座の残高を要求するように指示できますが、その残高は確認できません。これは明らかに無意味な攻撃です（銀行サーバーなどをDDoSしようとしているのでない限り）。ただし、たとえば、CSRF攻撃がブラウザに銀行に口座から攻撃者の口座に送金するように指示するように指示しても、意味がありません。転送の成功または失敗のページは、攻撃スクリプトにアクセスできません。攻撃者にとって幸いなことに、彼らは銀行の反応を見る必要はありません。彼らは自分の口座にお金が欲しいだけです。

状態を変更する操作のみがCSRF攻撃のターゲットになる可能性が高いため、CSRF防御が必要なのは操作だけです。

36
Neil Smithline

通常 安全なメソッド は、アプリケーションに変更を加えないため、CSRFから保護する必要はありません。機密情報を返している場合でも、これは 同じ生成元ポリシーによって保護されます） ブラウザで。

サイトが標準に従って実装されている場合、GETリクエストは安全であるため、保護する必要はありません。

ただし、「クロスサイトDoS」が発生する特定のケースがあります。* 攻撃が実行される可能性があります。たとえば、レポートページの実行に10秒かかり、データベースサーバーでのCPU使用率が100％、WebサーバーでのCPU使用率が80％だとします。

あなたのウェブサイトのユーザーは、それがサーバーを殺し、他の用途に悪いユーザー体験を与えるので、営業時間中に決してhttps://yoursite.example.org/Analysis/GetReportに行かないことを知っています。

ただし、 Chuck はyoursite.example.orgのウェブサイトをオフラインにしたいと考えています。彼はあなたやあなたの会社を好きではないからです。

彼が頻繁に投稿する忙しいフォーラムhttp://forum.walkertexasranger.example.comでは、署名を次のように設定しています。

<img src="https://yoursite.example.org/Analysis/GetReport" width=0 height=0 />

彼はまた、あなたの会社の従業員が頻繁にフォーラムに頻繁にアクセスし、またyoursite.example.orgにもログインしていることを知っています。

従業員がチャックの投稿のいずれかを読むたびに、認証Cookieがhttps://yoursite.example.org/Analysis/GetReportに送信されるため、サイトはリクエストを処理してレポートを生成します。これらの一定のリクエストによってCPUが消費されるため、システムはオフラインになります。

そのため、リクエストがGETリクエストであり、システムに永続的な変更（別名「安全」）を行わなくても、実行されるたびにシステムがダウンするのは事実です。したがって、CSRF防止方法でこれを保護することをお勧めします。

* XSDoS、またはサービスの場合のクロスサイト拒否は、私が作り出したフレーズなので、グーグルで検索しないでください。

18
SilverlightFox

CSRF保護は、データの保護には使用されません。これは、送金やアカウントからのログアウトなど、ユーザーが無意識のうちに状態が変化するのを防ぐために使用されます。

したがって、GETリクエストが状態を変更している場合（変更してはならない）、CSRF保護が必要です。ただし、データを返すだけの場合は、CSRF保護は必要ありません。この場合、CSRF保護は何も保護しません。

このページをもう一度参照すると役立つ場合があります： https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

6
d1str0

CSRF（Cross-Site Request Forgery）は、データが取得されることから保護することではなく、データが変更されることから保護することです。これは、状態変化とも呼ばれます。アプリケーションでは、状態の変更に、メールアドレス、ユーザーパスワード、伝記などのプロファイルデータや送金を含めることができます。

GET要求は、べき等の要求、または状態を変更しない要求に使用されます。これらの要求には、抗CSRFトークンは必要ありません。

POST要求は、べき等ではない要求、または状態を変更する要求に使用されます。

1
h4ckNinja

一般に、POST要求は、何かの状態を変更するために使用する必要があります。GET要求が状態を変更できるように設定されている場合（例：www.example.com/settings?delete_account=True ）、次に、バンドエイド修正としてCSRF保護を使用する必要があります。

GETではなくPOSTを使用して状態を変更してください。

0
Stoud