問題タブ [csrf]

Rails に組み込まれている CSRF 防止は、私たちが行っている自動負荷テストでいくつかの問題を引き起こしているため、プロセスの間はオフにしたいと考えています。どうすればいいですか？

Django には、フォームで使用するための一意のセッションごとのトークンを生成するCSRF 保護ミドルウェアが付属しています。すべての受信POSTリクエストをスキャンして正しいトークンを探し、トークンが見つからないか無効な場合はリクエストを拒否します。

一部の POST リクエストに AJAX を使用したいのですが、リクエストには CSRF トークンがありません。ページには<form>フックする要素がなく、トークンを非表示の値として挿入してマークアップを混乱させたくありません。これを行う良い方法は/get-csrf-token/、ユーザーのトークンを返すようなビューを公開し、ブラウザーのクロスサイト スクリプティング ルールに依存して、敵意のあるサイトがトークンを要求するのを防ぐことだと考えています。

これは良い考えですか？AJAX リクエストを許可しながら、CSRF 攻撃から保護するためのより良い方法はありますか?

では、GAE アプリケーションに対する XSRF 攻撃を防ぐ最善の方法は何でしょうか? 次のことを想像してください。

1. 誰でもユーザーの公開オブジェクトを見ることができ、db.Model id を要求で使用して、表示するオブジェクトを特定します。悪意のあるユーザーが ID を取得しました。
2. 悪意のあるユーザーが独自のオブジェクトを作成し、削除フォームをチェックアウトします。彼らは、特定の ID を持つオブジェクトを削除する方法を知っています。
3. 悪意のあるユーザーが無実のユーザーに、そのユーザーのオブジェクトの削除要求を送信させます。

#3 を防ぐためにどのような手順を追加できますか? ID と言うときは、キーの実際の ID 部分を使用していることに注意してください。私が持っていた 1 つのアイデアは、削除要求で完全なキー値を使用することでしたが、悪意のあるユーザーがこれを理解するのを防ぐことができますか? 私が知る限り、キーはモデル クラス タイプ、アプリ ID、およびオブジェクト インスタンス ID の組み合わせであるため、必要に応じて ID からキーを導出できる可能性があります。

他のアイデアはありますか？Jeff はこれについて投稿し、いくつかの方法を提案しました。リクエストごとに変更される非表示のフォーム値と、js を介してフォームに書き込まれる Cookie 値です。javascript 以外のユーザーを除外したくないので、Cookie ソリューションは役に立ちません。非表示のフォーム値の場合、削除可能なオブジェクトを表示するすべてのリクエストでデータストアへの書き込みを行う必要があります。スケーラブルなアプリケーションにとって理想的な状況ではありません。アプリ！

そこに他のアイデアはありますか？

誰もトークンと ttl の両方を使用して XSRF を実行できないようにする抽象基本クラスまたはマスター ページ ソリューションを探しています。誰かが私を正しい方向に向けることができますか?

編集: 理想的なソリューションは、既定のメンバーシップ プロバイダーがクライアントに送信する Cookie を利用することです。

クロスサイト リクエスト フォージェリ (CSRF) 攻撃に関して、Cookie が最もよく使用される認証方法である場合、Web ブラウザーが別のドメインから生成されたページから特定のドメイン (およびそのドメイン) の Cookie を送信できるのはなぜですか?

CSRF はブラウザでそのような動作を禁止することで簡単に防止できませんか?

私の知る限り、この種のセキュリティ チェックは Web ブラウザには実装されていませんが、その理由はわかりません。何か問題がありましたか？

CSRFについて:

• ウィキペディアで
• コーディングホラーについて

編集: 上記の場合、Cookie は http POST で送信されるべきではないと思います。それが私を驚かせるブラウザの動作です。

私はRailsとRESTfulなアプローチを学ぼうとしているASP.NET開発者です。理解するために、私は電子メールクライアントを作成することを計画しています。これは、サーバーに RESTful GET 呼び出しを行って電子メールを取得し、POST して電子メールを送信します。

上記のアプリケーションが XSRF の脆弱性を公開しないようにするために、従うべきベスト プラクティス (一般的および/または Rails 固有の両方) は何ですか。

私が取り組んでいるサイトでの XSRF 攻撃を防ぐために、ダブル サブミット クッキーテクニックを使用することにしました。したがって、ここに書き留めた方法は、実際に GET 情報以外のことを行うすべてのアクションが投稿になるということです。Gets は...ええと...GETs になります。次に、投稿するすべてのフォームにキーと Cookie の組み合わせがあります。

私の質問は、これを ASP.NET MVC Web アプリケーションに実装する最も簡単な方法は何でしょうか?

私自身の質問に答えるつもりはありませんが、私の最初の考えは次のとおりです。

現在、私のコントローラーはすべて基本コントローラーから継承されているため、最初に考えたのは、OnActionExecuted メソッドをオーバーライドして、必要なフォーム フィールドの存在を確認し、そこから見つかった場合は、Cookie に対して検証し、投稿を許可することでした。続行するか、エラーページに移動します。

フォーム部分については、BeginForm と同じメソッドをすべてオーバーロードする Html.BeginSecureForm() のような独自の html 拡張メソッドを生成することを考えていましたが (必要な場合に備えて)、疑似乱数キーと Cookie を自動生成し、 Cookie とフォーム内のフォーム フィールド (IF ITS A POST!) が自動的に作成されます。

申し訳ありませんが、これがごちゃごちゃしている場合は、これらのページ全体にメモが散らばっていて、それらを整理しようとしています. その一部は、この XSRF セキュリティに関する私の設計を理解することです。

POST リクエストによって返された JSON データは、クロスサイト リクエスト フォージェリ攻撃によって盗まれる可能性がありますか?

asp.netで、CSRF攻撃を軽減するためにIHttpModuleを実装しています。GETでasp.netSessionIDを使用して非表示のフォームパラメーターを応答htmlに挿入します。次に、POSTで、非表示のパラメーターの値が現在のSessionIDと一致することを確認します。私の知る限り、SessionID値を取得する唯一の方法は、Cookieから取得することです。これは、悪意のあるサイトによって読み取られたり、判別されたりすることはありません。私が見落としているものはありますか？

MVC の AntiForgeryToken 属性を使用する方法を知っています。これは、アプリケーションのフォーム POST を XSRF で保護するのに役立つ HTML ヘルパーに関連付けられています。

GET を実装する JsonResults に対して同様のことができますか?

たとえば、私のビューには、次のような onSubmit jQuery 呼び出しが含まれています。

この JsonResult が目的のページからのみ呼び出し可能であることを確認したいと思います。

編集：

同様の質問に関するこの投稿を見つけましたが、具体的な回答はありません。

GET (非破壊) URL が自分のページからの AJAX 呼び出しによってのみ消費されるようにする最も簡単な方法は何ですか?