問題タブ [csrf]

CSRF から保護するには、フォームの非表示フィールド、Cookie、またはセッション変数にノンスを配置する必要があります。しかし、ユーザーが異なるタブで複数のページを開いた場合はどうなるでしょうか? この場合、各タブには一意の nonce を持つフォームがありますが、セッション変数または Cookie に保存される nonce は 1 つだけです。または、すべての nonce を cookie/session 変数に格納しようとすると、どれがどのフォームに属しているかをどのように識別しますか?

私が作成したアプリケーションでは、これらのメッセージがたくさん表示されます:

これは、人々がそのページを更新することなく（ajaxを使用して）多くの時間をそのページに費やし、トークンの有効期限が切れるために発生していると思われます。

これらのトークンの寿命を延ばす方法はありますか?

Web アプリケーション用の RESTful (または準 RESTful) API を構築する際に、人々がどのようなアプローチを取っているかを知りたいと思っています。

実際の例:

すべてのフォームで CSRF 保護を使用する従来のブラウザーベースの Web アプリケーションがあるとします。ブラウザーに表示される各フォームには、CSRF 保護トークンを含む非表示の入力が含まれています。フォームの送信時に、この入力がサーバー側のトークンのバージョンと一致しない場合、フォームは無効と見なされます。

ここで、Web アプリケーションを API として公開したいとします (おそらく HTML ではなく JSON を使用します)。従来、API を公開する場合、トランザクションは一方的なものであると考えてきました (つまり、API コンシューマーは、最初にフォームをリクエストしてから、返されたフォームを使用してリクエストを構築するのではなく、公開された API に基づいてリクエストを構築します)。

「一方的な」アプローチは、CSRF 保護などの要素が含まれると破綻します。CSRF 保護トークンは、API コンシューマから送信されるすべての POSTS/PUTS/DELETES に含める必要があります。

これにどう対処するのがベストかを考えてみました。API 呼び出しを行う必要があるたびにフォームを要求するのは非常に面倒に思えますが (特に非同期操作を処理する場合)、私が自分で考えた他のすべての代替手段は、CSRF 保護を無効にしているようです (または、少なくともそれに穴を開けます)。 )、これは容認できません。

これについての洞察を持っている人はいますか？

ありがとう。

(問題は概念的でプラットフォームに依存しないため、あまり重要ではありませんが、私は従来の LAMP スタックを扱っており、アプリケーション フレームワークとして Symfony 1.4 を使用しています。私の目標は、開発者が JSON 形式の Web API を公開できるようにすることです。既存の Web アプリケーションとうまく連携するモバイル/デスクトップ アプリを作成します)。

SymfonyでCSRF保護が有効になっているフォームをテストするための機能テストを作成する最良の方法は何ですか？

現在、各フォームを送信する前に、次のコードを追加する必要があります。

次に、$tokenと$token_nameを追加して、次のようなパラメーターを作成します。

ドキュメントで提案されているオプション：

まったく動作しません。

手動でテストされた各フォームにトークンを追加しないようにするためのより簡単な方法はありますか？または、テストの実行時にcsrfチェックをオフにする方法はありますか？

上記で説明した方法は、1〜2個のフォームをテストする必要がある場合は問題ありませんが、プロジェクトに10個の固有のフォームが含まれていると、面倒になります。

Django の単純な POST フォームで CSRF トークンに苦労しています。テンプレートは、トークンの値を出力する代わりに、次の CSRF 出力を生成します。

テンプレートで使用{% csrf_token %}していますが、これを修正するにはどうすればよいですか? （私はDjango 1.2を使用しています）

編集: 正確なフォーム コードは次のとおりです。

CSRF に関するDoctype のエピソードを見たところです。

CSRF の最善の予防策は、ユーザー固有のデータ (セッション ID のハッシュなど) からトークンを作成し、それをリクエストと共に POST することです。

推測しにくい値 (GUID など) を生成し、それをセッション変数として保存し、非表示フィールドとしてページに配置するのは安全性が低くなりますか?

ページが読み込まれるたびに値が変更されますが、POST されたデータのテストはその前に行われます。

これは私には安全に思えます。私が間違っている？

私が構築しているページは、AJAX に大きく依存しています。基本的に、「ページ」は 1 つだけで、すべてのデータ転送は AJAX を介して処理されます。ブラウザー側で過度に楽観的なキャッシングを行うと奇妙な問題 (データがリロードされない) が発生するため、POST を使用してすべての要求 (読み取りも) を実行する必要があります。これにより、リロードが強制されます。

ここで、CSRF に対してページを防止したいと考えています。フォームHtml.AntiForgeryToken()送信ではうまく機能しますが、AJAX リクエストでは、トークンを手動で追加する必要があると思いますか? すぐに使用できるものはありますか?

私の現在の試みは次のようになります：

既存の魔法を再利用したい。ただし、HtmlHelper.GetAntiForgeryTokenAndSetCookieプライベートであり、MVC をハックしたくありません。他のオプションは、次のような拡張機能を作成することです

これはいくぶんハックであり、より大きな問題を未解決のままにします:そのトークンを確認する方法は? デフォルトの検証の実装は内部であり、フォーム フィールドの使用に対してハードコードされています。少し変更した を書こうとしましたValidateAntiForgeryTokenAttributeが、AntiForgeryDataSerializerそれは非公開の を使用しており、それもコピーしたくありませんでした。

現時点では、自家製のソリューションを考え出す方が簡単に思えますが、それは実際には重複したコードです。

これをスマートな方法で行う方法について何か提案はありますか? 完全に明らかな何かが欠けていますか？

私の Ajax リクエストが X-Requested-With ヘッダーを設定する場合、このヘッダーが存在するかどうかの CSRF チェックをスキップできますか? （ユーザーセッションで）偽造できないと確信できますか？

クロスサイトリクエストフォージェリ（CSRF）は通常、次のいずれかの方法で防止されます。

• リファラーを確認してください-RESTfulですが信頼性がありません
• フォームにトークンを挿入し、サーバーセッションにトークンを保存します-実際にはRESTfulではありません
• 不可解なワンタイムURI-トークンと同じ理由でRESTfulではありません
• このリクエストのパスワードを手動で送信します（HTTP認証で使用されるキャッシュされたパスワードではありません）-RESTfulですが便利ではありません

私の考えは、ユーザーシークレット、不可解であるが静的なフォームID、およびJavaScriptを使用してトークンを生成することです。

1. GET /usersecret/john_doe認証されたユーザーからJavaScriptによってフェッチされます。
2. 応答：OK 89070135420357234586534346この秘密は概念的には静的ですが、セキュリティを向上させるために毎日/時間ごとに変更できます。これが唯一の機密事項です。
3. JavaScriptを使用して不可解な（ただしすべてのユーザーにとって静的です！）フォームIDを読み取り、ユーザーシークレットと一緒に処理します。generateToken(7099879082361234103, 89070135420357234586534346)
4. 生成されたトークンと一緒にフォームをサーバーに送信します。
5. サーバーはユーザーシークレットとフォームIDを認識しているため、両方の結果を送信して比較する前に、クライアントが実行したのと同じgenerateToken関数を実行できます。両方の値が等しい場合にのみ、アクションが許可されます。

JavaScriptなしでは機能しないという事実にもかかわらず、このアプローチに何か問題がありますか？

補遺：

• ステートレスCSRF保護

私はおそらくここでは初心者ですが、CSRF (クロスサイト リクエスト フォージェリ) 攻撃が正確に何であるかについてはまだ確信が持てません。それでは、3つの状況を見てみましょう...

1) サイトのデータを編集するために使用する POST フォームがあります。このデータをログインしているユーザーだけが編集できるようにしたい。

2) ログインしているユーザーとゲストの両方が使用できるサイトがあります。サイトの一部はログイン ユーザー専用ですが、すべてのユーザーが使用できる POST フォームもあります (たとえば、標準の連絡フォームなど)。お問い合わせフォームを CSRF 攻撃から保護する必要がありますか?

3) 認証システムがまったくないサイトがあります (まあ、それはおそらく非現実的です。残りの部分とは別の管理サイトがあり、管理部分が適切に保護されているとしましょう)。サイトの主要部分は、匿名ユーザーのみが使用します。その上の POST フォームを保護する必要がありますか?

1) の場合、答えは明らかにイエスです。しかし、2 と 3 の場合はわかりません (また、2 と 3 の違いは重要ですか?)。