フォームにCSRF保護を使用しない場合
デフォルトでは、トークンを使用するすべてのフォームにCSRF保護があります。
しかし、フォームの1つと同様の機能を持つ別のWebアプリケーションに気付きました。そして彼らはCSRFトークンを使用しませんでした。
そのため、私は彼らがそのフォームのCSRF攻撃を防御しなかったと想定しました。
そう
質問1）CSRFトークン以外に、CSRFから保護する別の方法はありませんか？
答えはこれが唯一の方法だと思います。したがって、私の主な質問は
質問2）CSRF保護を使用すべきでないのはいつですか？
POSTフォームが外部URLをターゲットとする場合に考えられる1つのインスタンスを知っています。
Django docs で読みます。
CSRF保護を使用してはいけない、または不要な他のインスタンスはありますか？
[〜＃〜]更新[〜＃〜]
a）CSRF保護の他の方法には、ユーザーの再認証が含まれます
b）ユーザーがログインする必要がない場合、フォームPOSTBACKのCSRFから保護せずに逃げることができます（nbnhの回答とコメントを参照）
いいえ、CSRFから確実に保護する方法はトークンだけではありません。
実際、パッケージ化されたライブラリーが推奨されるほど十分に成熟したのはごく最近のことです。それよりも、独自のライブラリーをロールすると事態が悪化する可能性が高くなります。
CSRFから保護するもう1つの方法は、再認証です。つまりユーザーにもう一度パスワードを要求します。
このアプローチの利点は、この手法が開発者に馴染みがあり、めちゃくちゃになる可能性が低いことです。欠点は、ユーザーには見えないことです。
最近では、ほとんどのフレームワークに保護機能が組み込まれており、追加のライブラリを利用できるので、CSRFトークンの方が好ましいと思いますが、それが唯一の方法ではありません。
Q＃2に関しては、@ nhnbが正しく書いたので、変更が行われない場合、保護を省略しても可能性があります。
それが現在のフレームワーク、ユーザーの透過性、および最小限のオーバーヘッドでどれほど取るに足らないかを考えると、おそらくそれをそのままにして、それを取り出すためのコードと戦わないほうがよいでしょう...
はい、トークンを使用することがCSRF攻撃から確実に保護する唯一の方法です。
保護が必要かどうかは、プログラムが送信されたデータに対して行うアクションによって異なります。
経験則として、現在のユーザーの権限またはコンテキストでデータが変更された場合、保護が必要です。
変更が行われない場合は、保護しなくてもかまいません。一般的な例は、検索フォームと結果です。どの検索がどのユーザーによって行われたかを記録することは一種の変更であり、そのためフォームを保護する必要があることに注意してください。