問題タブ [csrf]

Ajax.ActionLink私の ASP.NET MVC (v1) ページには、破壊的な操作を実行する多くの があります。この場合は HttpMethod を に設定しているため、これは「合法」DELETEであり、破壊的ではありませんGET。

ただし、私の質問は、この操作に対する XSRF 攻撃を軽減して、他のサイトがこの同じ AjaxDELETE要求を作成して別のサイトからユーザー データを削除できないようにする方法です。この ActionLink は、次を含むフォーム内に表示されます<%= Html.AntiForgeryToken() %>が、ActionLinks はフォームを投稿しないため、偽造防止トークンはコントローラーに送られず、検証できません。

ステートレス RESTful サービスに対してクロスサイト リクエスト フォージェリは可能ですか?

私は、Cookie を介してログインしていることをサーバーが記憶する疑似 REST について話しているのではありません。私が話しているのは、Cookie を使用しない純粋なサーバー上でのアプリケーション状態のない REST です。

SSL と基本認証を使用しています。すべてのリクエストに対して、その Authorization ヘッダーが存在する必要があります。SSL レベルにはある種のセッションがありますが、JSP の意味での「セッション」はありません。

そこで、Ajax リクエストを行う正当な Web ページを表示していて、何らかの方法で同じタブまたは別のタブの別のページに移動し、そのページが同じ Ajax リクエストを行うとします。(正規の Web ページには悪意のあるコードはないと仮定しています。それはまったく別のことであり、その場合は何でも可能です。)

2 番目のページが Ajax リクエストを行うとき、ブラウザーは同じ Authorization ヘッダーを設定しますか? つまり、ブラウザは「ああ、またそこに行きたいですか？たまたままだ鍵を持っているだけです！」と言うでしょうか？

また、悪意のあるスクリプトが xhr リクエストを実行し、コールバックで ioargs からリクエストを取得し、Authorization ヘッダーを取得して、名前とパスワードを Base64 で解除することはできませんか?

私のASP.NETMVCアプリケーションは、ValidateAntiForgeryToken属性を使用し、Html.AntiForgeryTokenを呼び出して、トークン値を使用して非表示の入力要素を書き込み、トークンをCookieに配置することで、CSRF攻撃を防ぎます。

私の例外ログは、有効なリクエストからトリガーされたように見えるHttpAntiForgeryExceptionの発生を報告しています（リファラーは正しいように見えます）。例外の原因となった応答には、フォームフィールドにトークン値とともに__RequestValidationTokenも含まれています。ただし、必要なCookieがリクエストから欠落しているため、検証が失敗し、例外がスローされます。

私はこのCookieが欠落している理由を考えようとしており、次の考えられる理由を考え出しました。

1. ドメインのCookieコレクションがいっぱいです。-これがここに当てはまる場合、各リクエストで20/50のCookieが表示されると予想され（ところで、すべてのユーザーエージェントはIE7とIE8です）、どういうわけかCookieが削除されています。例外のさまざまな発生で3〜23個のCookieが表示されます
2. Cookieのデータ制限に達しました。-これは起こっていません。ログを見ると、cookieコレクションが少ないことがわかります。
3. Cookieを追加する前に、応答が返送されています。-これについてはよくわかりません。ヘッドでReponse.Flushを手動で呼び出すと、応答が送信された後にCookieコレクションを変更できないことを示す例外が発生します。
4. ？

必死になって、私はSOの人々に目を向け、調査できるこの欠落したCookieのその他の考えられる原因を尋ねます。

親でiframeに許可されていることを制限する方法はありますか？私が探しているのは、次のようなJavascriptを取り巻くセキュリティモデルです。

両方の'trusted.htmlは次のようになります。

そして、「SomethingIShouldnt.php」は次のようになります。

そして、「untrusted.js」は次のようになります。

（ええと...やり過ぎてごめんなさい。）

HTMLコードに存在しない「セキュリティ」タグがあります。ルールを定義するためにApacheのようなセキュリティ構文が混在しているCSSセレクター風の宣言に沿って何かを考えていました。（私はwindow.parentルールを利用しませんでしたが、クロスサイトスクリプティングをブロックするブラウザーに対して適切な回避策を示していることを願っています。タイトル"）。私はこのようなものがすでに何らかの形で存在していることを望んでいます（ドラフト仕様でさえ）。しかし、私は答えが「いいえ」になるのではないかと心配しています。

これは（部分的にでも）実行できますか？そうでない場合は、このようなものを実装するために誰と話す必要がありますか（標準委員会またはブラウザーの実装者）？もちろん、これは意味があると仮定しますか？

CSRF 攻撃を防ぐために、ランダムな CSRF シークレットが生成されています。

上記は symfony からのものです: http://www.symfony-project.org/getting-started/1_4/en/04-Project-Setup

最終的にはユーザーが操作するので、いわゆる代理攻撃ですが、その秘密を設定してどう動くのでしょうか？

django csrf ミドルウェアに問題があります... テンプレート タグ csrf_token を使用すると、次の出力が得られます。

しかし、私はこの出力が欲しいです（xHTMLではなくHTML：

django.middleware.csrf.CsrfViewMiddleware のコードを見ようとしましたが、成功しませんでした:(

では、csrf_token タグの出力を変更するにはどうすればよいですか?

タンク

ASP.NetMVCのAntiForgeryTokenに問題があります。Webサーバーでiisresetを実行し、ユーザーがセッションを続行すると、ログインページにバウンスされます。ひどいことではありませんが、AntiForgeryトークンが爆発し、再び動作する唯一の方法は、ブラウザのCookieを吹き飛ばすことです。

バージョン1のベータ版では、Cookieを読み戻すときに問題が発生したため、検証トークンを要求する前にCookieをスクラブしていましたが、リリース時に修正されました。

今のところ、ベータ版の問題を修正したコードにロールバックすると思いますが、何かが足りないと思わずにはいられません。より簡単な解決策はありますか？彼らのヘルパーをドロップして、最初から新しいヘルパーを作成する必要がありますか？多くの問題は、古いASP.Netパイプラインに深く結びついていて、実際には設計されていないことを実行しようとしているという事実だと感じています。

ASP.Net MVC 2 RCのソースコードを調べましたが、コードがあまり変更されていないようですので、試していませんが、答えはないと思います。

例外のスタックトレースの関連部分は次のとおりです。

編集：これがGETリクエストにトークンを挿入しようとしているだけだとは言わなかったことに気づきました。これは、POSTキックオフを実行するときに発生する検証ではありません。

symfony 1.4 で jquery を使ってフォームを送信しようとしていますが、毎回 CSRF 攻撃検出エラーが表示されます。これは、フォームデータを送信するために使用するコードです:

何か不足していますか？

ありがとう、ラドゥ。

私はこれについて考えていましたが、POSTは少し脆弱性が低く、やや難しいようです（ユーザーに何かをクリックするように要求するため）。

トークンIDと二重送信されたCookieについて読みましたが、違いがわかりません

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit

現在、私はユーザーID（私のテーブルではPK）とセッションIDを持っているので、Cookie IDを変更して、他の誰かのように振る舞うことはできません。これで、各フォームにセッションIDをトークンとして入れて、攻撃者がこれらのトークンを推測できないことを確認したようです。ただし、pplが表示できるようにセッションIDをページに配置するというアイデアは嫌いです。しかし、本当に、それに問題がありますか？ユーザーにhtmlをコピー/貼り付けさせる以外に、セッションIDがhtmlでプレーンビューになっているために発生する可能性のある攻撃はありますか？