問題タブ [antiforgerytoken]

ログインページの偽造防止トークンに特定の問題があります。ユーザーが1つのアクティブなウィンドウだけでログインする場合、すべてがうまく機能しますが、ユーザーが2つの異なるウィンドウでログインページを開き、ウィンドウAからログインすると（問題なくログインします）、このウィンドウのウィンドウBからログインに戻ります。ユーザーには、「必要な偽造防止トークンが提供されなかったか、無効でした」というメッセージが表示されます。

ビュー/コントローラーアクションから偽造防止トークンを削除する方法は他にありますか？セキュリティを強化するためにトークンを用意したいと思います。

これはこの質問と非常に似ていますが、これはmvc2MVCValidateAntiForgeryTokenマルチタブ の問題について尋ねられました

@Html.AntiForgeryToken()Stack Exchange サイトでは、XSRF/CSRF 攻撃を防ぐために組み込みの ASP.NET MVC を使用していないことを知っています。web.config の machineKey セクションに基づいて非常に長い値で名前が付けられた非表示の入力を作成する代わりに、Stack Exchange メソッドは、__RequestVerificationTokenより簡潔な値で名前fkeyが付けられた入力を作成します。これは明らかに Guid であり、Google Code の Stack Exchange Data Explorer プロジェクトからの証拠に基づいて、この値は個々のユーザーに関連付けられており、ログインまたはログアウトするまでかなり一定のままです。

また、Stack Exchange の値はページ上で定数であり、クライアント スクリプトで使用できるようになっているため、Ajax が投票のために投稿したり、そのようなものでもトークンを使用したりできます。対照的に

では、なぜ Stack Exchange は独自のドラマーに向かって行進するのでしょうか?

• AntiForgeryToken を信頼しない理由はありますか?
• AntiForgeryToken には、Stack Exchange チームが受け入れたがらなかったいくつかの制限がありますか? もしそうなら、彼らは何でしたか？
• あるいは、Stack Overflow が開始されたときに AntiForgeryToken が存在しなかった (MVC Futures プロジェクトで開始された) 可能性があります。

SE ネットワークでの XSRF 防止ポリシーの背後にある指針となる原則を説明する、Jeff や Stack Exchange チームの他のメンバーによるブログ投稿を見つけることができませんでした。もちろん、脆弱性を作成することなく一般的な用語で行うことができると仮定して、そのうちの1人が記事を作成できるとしたら、それは本当に素晴らしいことです. Web サイトを安全に保ちたいと考えている私たちにとって、これは非常に価値のある情報ですが、Microsoft が私たちのためにそれをしてくれると盲目的に信頼するだけでは完全に快適ではありません.

Windows Azure (最新の 2.x OS バージョン) で実行されている ASP.NET MVC 2 (.NET 4) アプリケーションと、2 つの Web ロール インスタンスがあります。

すべての POST 要求に対して MVC によって提供される偽造防止トークンを使用し、web.config で静的なマシン キーを設定しているため、すべてが複数のマシンで再起動しても機能します。ケースの 99.9% は完全に機能します。

ただし、時折、HttpAntiForgeryException がログに記録され、「必要な偽造防止トークンが指定されていないか、無効でした」というメッセージが表示されます。

ブラウザで Cookie が許可されていないことが問題である可能性があることは承知していますが、Cookie が有効になっており、正しく送受信されていることを確認しました。

このエラーはさまざまなブラウザで発生し、操作を繰り返す必要があるか、一部のデータが失われる可能性があるため、明らかにユーザーに問題を引き起こします. 問題をローカルで再現することはできませんでしたが、Windows Azure でのみ発生します。

なぜそれが起こっているのですか？どうすればそれを避けることができますか?

ajax.actionlinkオブジェクトを削除するためにa を呼び出す次のものがDelete action methodあります:-

しかし、攻撃者が誤った削除要求を送信できないようにするため@Html.AntiForgeryToken()に、削除呼び出しに含める方法はありますか?Ajax.actionlink

ブラジル

AntiForgeryTokenをJqueryajaxreuestsで動作させる方法についてここで読みました。基本的に、次のようなものを使用して、post/ajax呼び出しにトークンを含める必要があります。

ただし...ViewModelsを使用して、ビューモデルオブジェクトを作成し、値を割り当ててから、JSON.stringifyしてデータとして渡します（以下のとおり）。

現在の設定を使用してトークンを渡す方法が少し混乱していますか？どんなアドバイスも大歓迎です。

バックグラウンド

WebForms ページ (cms でホストされている) から AntiForgeryToken を使用する必要があります。ページは、ソリューションの一部である MVC 2.0 アクションにデータを投稿する必要があります。アクションは ValidateAntiForgeryToken 属性を使用する必要があります。

ここから解決策を試しました: Using an MVC HtmlHelper from a WebFormが、レンダリングされた偽造防止トークンがコントローラー アクションから無効として通知されたため、機能していないようです。

現在のソリューション

これで、偽造防止トークンを含む入力タグのみを含む部分ビューをレンダリングするアクションを利用できるように解決しました。

意見

このページでは、JavaScript を使用して、偽造防止トークンを次のようなフォームに取り込みます。

形

偽造防止トークンを取得する

これは、フォームの投稿が ValidateAntiforgeryToken 属性に従って有効である限り機能します。

質問

この方法で偽造防止トークンをフォームに追加すると、セキュリティ上の問題はありますか?

乾燥させない簡単な方法はありますか？

ASP.NetMVC4ベータ版の代わりにASP.NetMVC4RCをインストールしました。既存のアプリケーションを実行しようとすると、AntiForgeryToken非推奨のエラーメッセージが表示されます。これが私のコードです：

- - アップデート - -

ASP.Net MVC 4 RCにより、ValidateAntiForgeryToken属性およびAntiForgeryTokenhtmlヘルパーのSaltプロパティが廃止されました。したがって、私のコードは次のようになります。

コントローラ：

形：

生成されたHTMLを見ると、AntiForgeryTokenは引き続き非表示フィールドを生成し、暗号化された値を提供します。私の行動もまだ機能します。しかし、暗号化プロセスで使用するキーを指定する機能が失われました。プロセスがどのように機能するかはよくわかりませんが、アクションとフォームにソルト値を設定していたことがわかります。アクションが投稿を受け入れるには、値が一致している必要がありました。では、今どのように塩分値を設定しますか？AntiForgeryConfig AdditionalDataProviderと関係があると思いますが、AntiForgeryConfigAdditionalDataProviderの使用方法について何もわかりません。助けてください。

ありがとう

偽造防止メカニズムを使用して ajax 投稿を保護しようとしています。

まず、antiforgerytoken ヘルパー メソッド呼び出しをビューに追加しました。

そして、私のjqueryポストコールを調整しました

もちろん、アクション メソッドを ValidateAntiForgeryToken で装飾しました

しかし、フォームを送信した後、必要な偽造防止トークンが提供されなかったか、無効なエラーがスローされます。

トークン Cookie を削除し、ブラウザを再起動しました。

何か不足していますか？

MVC3、.Net 4、および VS2010 を実行しています。問題を説明するために、次のサンプルプロジェクトがあります。

私のコントローラーコード

私のビューと JavaScript コード

ここには 2 つのボタンがあり、最初のボタンはフォーム ポストをトリガーし、2 つ目は Ajax ポストをトリガーします。A required anti-forgery token was not supplied or was invalid.フォームの投稿は正常に機能しますが、Ajax の投稿は機能しません。JSON に既にトークンを含めているにもかかわらず、サーバーが文句を言います。

私のコードの何が問題なのですか？

しばらくの間、これの何が問題なのかを理解しようとしてきました。サーバーAPIへのjson本体を使用してHttpClient.executeで投稿リクエストを作成しています。通常の Wi-Fi とほとんどの 3g では正常に動作しますが、特に AT&T データプランを備えた電話で 3g を使用している場合、リクエストを実行しようとすると HttpResponseException が返されます。ステータス コード 422 です。に：

「422 Unprocessable Entity (WebDAV) (RFC 4918)、要求は整形式でしたが、セマンティック エラーのため従うことができませんでした。」

したがって、リクエストの送信方法に問題があると推測していますが、Wi-Fi を使用しているか 3G を使用しているかにかかわらず、リクエストを作成する際に同じことを行っています。このエラーの原因について何か考えはありますか?

編集：私のサーバーが偽造防止で投稿をキャッチしているように見えました。オフにしてエラーは止まりましたが、APIは通りませんでした。もう少し深く掘り下げて、サーバーが実際に受信しているものを出力し、wifi のオンとオフを比較して、2 つの違いに気付きました。まず、3g で本文が空だったのですが、何らかの理由で送信がブロックされたようです。次に、ヘッダーによって、送信されるコンテンツ タイプが変更されました。

wifi: "HTTP_CONTENT_TYPE"=>"application/json" att 3g: "HTTP_CONTENT_TYPE"=>"text/plain; charset=ISO-8859-1,application/json"

次のように接続を設定していることを考えると、「application/json」を期待しています。

3g に移行したときに状況が変わる理由はありますか?

更新: tcpdump を実行したところ、Android から送信しているものは wifi と 3g でまったく同じであるように見えるため、データを変更しているのはプロバイダーのようです。HTTPS 以外に提案された戦略はありますか?