質問:
フォームにCSRF保護を使用すべきでないのはいつですか？
Kim Stacks
2011-03-12 10:37:56 UTC
view on stackexchange narkive permalink

デフォルトでは、トークンを使用してすべてのフォームに対してCSRF保護が適用されます。

しかし、フォームの1つと同様の機能を持つ別のWebアプリケーションに気づきました。また、CSRFトークンを使用していませんでした。

そのため、そのフォームのCSRF攻撃から保護されていないと思いました。

したがって

質問1）CSRF以外トークン、CSRFから保護する別の方法はないはずですか？

答えはこれが唯一の方法だと思います。したがって、私の主な質問は

質問2）CSRF保護を使用すべきでない場合はいつですか？

POSTフォームが外部URLを対象としている場合の1つの可能なインスタンスを知っています。

django docsで読みました。

CSRF保護を使用すべきでない、または不要な他のインスタンスはありますか？

UPDATE

a）CSRF保護の他の方法には、ユーザーの再認証が含まれます

b）ユーザーを必要としない場合は、フォームのポストバックでCSRFから保護せずに回避できますログインします。（nbnhの回答とコメントを参照）

他のコメントで示唆しているように、質問で特定のアプリケーションと提案されたフォームのシーケンスを具体化できれば、これを動機付けるのに役立つと思います。
二 答え:
Hendrik Brummermann
2011-03-12 17:18:53 UTC
view on stackexchange narkive permalink

はい、トークンを使用することがCSRF攻撃から確実に保護する唯一の方法です。

保護が必要かどうかは、プログラムが送信されたデータに対して実行するアクションによって異なります。

経験則として：現在のユーザーの権限またはコンテキストでデータが変更された場合は、保護が必要です。

変更が行われない場合は、保護しなくてもかまいません。一般的な例は、検索フォームと結果です。どの検索がどのユーザーによって行われたかを記録することは一種の変更であるため、フォームを保護する必要があることに注意してください。

匿名の訪問者が実行できるアクションはどうですか？たとえば、ログインせずにカートにアイテムを追加します。この場合、CSRF保護を放棄できますか？
ユーザーコンテキストなしで（およびログなしで）誰でも実行できるアクションの場合、フォームを保護しなくてもかまいません。ただし、具体的なユーザーのコンテキストにある場合（匿名のユーザーであっても）、保護が必要です。考えられる方法で例を拡張するには：しばらくすると、ユーザーは住所と請求情報を入力し、ショッピングカートの内容を注文します。明らかな理由で、カートにはアイテムが入っていないはずです。彼は自分でカートに入れませんでした。
AviD
2011-03-12 23:57:14 UTC
view on stackexchange narkive permalink

いいえ、トークンはCSRFから確実に保護する唯一の方法ではありません。
実際、パッケージ化されたライブラリが推奨を正当化するのに十分成熟したのはごく最近のことで、自分で作成する可能性が高くなりました。さらに悪い。

CSRFから保護するもう1つの方法は、再認証です。つまりユーザーにもう一度パスワードを要求します。
このアプローチの利点は、この手法が開発者に馴染みがあり、混乱する可能性が低いことです。欠点は、ユーザーに対して透過的ではないことです。
現在、ほとんどのフレームワークには保護が組み込まれており、追加のライブラリが利用可能であるため、CSRFトークンが推奨されます...しかし、それが唯一の方法ではありません。

Q＃2に関しては、@ nhnbが正しく書いているように、変更が行われない場合は、保護を省略しても問題ない可能性があります。
それがどれほど些細なことかを考慮しても現在のフレームワーク、ユーザーの透明性、最小限のオーバーヘッドにあるので、コードと戦わずにそのままにしておく方がよいでしょう...

@AviD,の再認証は、CSRF保護のためにユーザーに受け入れられるソリューションではありません。 _本当に_危険な行動（送金など）で受け入れられる場合がありますが、標準的な解決策ではありません。 ///トークンが不要であるという理由だけで、トークンを省略してはならないことに同意します。ただし、結果ページを形成するためのリンクを許可することが望ましい場合があります。一般的なケースは、検索結果へのリンクを共有することです。
@nhnbの再認証は、正しい解決策であり、最も直接的なものです。それほど昔までは、独自のトークン管理をロールすることは*常に*間違っており、解決するよりも多くのダメージを与えることが多いため、これは*唯一の*推奨されるソリューションでした。銀行の外でも、これがうまく使用された例はたくさんあります。 LinkedIn。ただし、そのアプローチの鍵は、適用する場所を選択することです。
@AviD匿名の訪問者が実行できるアクションはどうですか？たとえば、ログインせずにカートにアイテムを追加します。この場合、CSRF保護を放棄できますか？
問題のフォームはテンプレートに含まれており、ユーザーが自由にルックアンドフィールをカスタマイズできるようにする予定です。私のユーザーは、TwigとLiquidを使用してUIをカスタマイズすることに慣れているユーザーを対象としています。 CSRF保護を使用すると、Webデザイナーにとって直感的ではなくなります。したがって、質問の背後にある動機
@keisimoneが言ったように、@nhnbは、誤用される可能性のある「ID」があり、実行されている「アクション」がある場合は、CSRF保護が必要です。あなたの場合、これを別の方法で解決することができます。ログイン時にカートを再初期化して空にします。
開発プロセスについては、TwigやLiquidに精通していませんが、UIとコードを分離できるフレームワークがあります（つまり、「コードビハインド」）。また、多くのフレームワークでは、CSRF保護は構成ベースであり、UI設計者に干渉してはなりません。
...他の人がここで反対していることに興味があります...
@AviD CSRF保護を使用するためにUIでフレームワークにネイティブなFormHelperを使用する必要がある、cakephpと呼ばれるフレームワークを使用しています。したがって、ユーザー/デザイナーは少なくともフレームワークにある程度精通している必要があります。
@AviD私が利用できるオプションを判断すると、おそらく先に進んで、少なくともこの保護のためのFormHelperコードをユーザーに知ってもらうだけです。セキュリティは重要なので、通常のHTMLフォームではうまくいかないと思います


ⓘ
このQ＆Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 2.0ライセンスに感謝します。
Loading...