問題タブ [antiforgerytoken]

質問が 1 つあります。最近、すべてのフォームに偽造防止トークンを配置し、コントローラーにValidateAntiForgeryToken属性を配置しました。

しかし、多くの場合、私のユーザーはフォームに入力し、ブラウザー ボタンを押して戻ってきて、間違いの 1 つを修正し、無効な偽造防止トークンを取得します。

なぜそれが起こるのか理解できます（私たちは戻って、もはや有効ではない偽造防止トークンを使用しています）が、この動作を回避する方法はありますか? このページを強制的にリロードしますか?

AntiForgeryToken を使用してクロスサイト リクエスト フォージェリを回避する方法については誰もが知っており、十分に効果的です。

私は別のケースを持っています（しかし、それは一般的だと思います）.2つのasp.net mvc Webサーバーがあり、それらをAとBと呼んでいます.

何らかの理由で、B で要求されたアクションで[ValidateAntiForgeryToken]属性がオンになっている場合、Web ページ A から Web サーバー B への投稿要求を行いたいと考えています。それを可能にする方法は？

ドメインと仮想パスを使用した Html.AntiForgery には可能性があることがわかります。

これを試しましたが、うまくいきませんでした。誰でもこれを解決する方法を知っていますか?

WebページからAJAXスタイルと呼ばれる既存のMVCWebサービスがいくつかあります。これらのサービスは、ValidateAntiForgeryToken属性を利用して、リクエストフォージェリを防止します。

これらのサービスをWebAPIに移行することを検討していますが、同等の偽造防止機能はないようです。

私は何かが足りないのですか？Web APIを使用してリクエストフォージェリに対処するための別のアプローチはありますか？

.Net 4 および IIS6 (Win2003 サーバー) で MVC3 Web アプリケーションを実行しています。断続的に、次のエラー メッセージをキャプチャできます。

ビューにはコードがあります

そして、受信アクションメソッドは次のようになります

コーディングは正しいと思います。似たようなことを経験したことのある人はいますか？

.net 3.5 mvc2 Web アプリケーションにセキュリティを適用しています。私の Web サイトにはユーザー認証が含まれておらず、.js ファイル内の多数の ajax 呼び出しで構成されています

私が書いた.aspxファイルに

私の.jsファイル関数で私が書いた

私のコントローラーで私が書いた

これは私にとってはうまくいきますが、
Q1 で 2 つの質問があります。それは正しいアプローチですか？ページのソースを見ると、このコードが見つかりました

しかし、外部 html ファイルを作成し、__RequestVerificationToken のこの値をコピーして ajax 呼び出しを渡すと、このエラーが発生します
。必要な偽造防止トークンが提供されなかったか、無効でした。 次に
Q2。ランタイムは、このページがコピーされた __RequestVerificationToken を提供していることをどのように認識しますか?

私は JSON ベースの AJAX リクエストを作成しています。MVC コントローラーを使用して、Phil Haack のAJAX による CSRF の防止と、Johan Driessen のMVC 4 RC 用の最新の Anti-XSRF に非常に感謝しています。しかし、API 中心のコントローラーを Web API に移行すると、2 つのアプローチの機能が著しく異なり、CSRF コードを移行できないという問題が発生します。

ScottS は最近、同様の質問を提起し、 Darin Dimitrovが回答しました。Darin のソリューションには、AntiForgery.Validate を呼び出す承認フィルターの実装が含まれます。残念ながら、このコードは私には機能しません (次の段落を参照)。正直なところ、私には高度すぎます。

私が理解しているように、Phil のソリューションは、フォーム要素がない場合に JSON リクエストを行う際の MVC AntiForgery の問題を克服します。フォーム要素は、AntiForgery.Validate メソッドによって想定/期待されます。これが、私が Darin のソリューションにも問題を抱えている理由だと思います。HttpAntiForgeryException 「必要な偽造防止フォーム フィールド '__RequestVerificationToken' が存在しません」を受け取りました。トークンが POST されていることは確かです (ただし、Phil Haack のソリューションのヘッダーにあります)。クライアントの呼び出しのスナップショットを次に示します。

Johan のソリューションと Darin のソリューションを組み合わせてハックを試みましたが、機能するようになりましたが、HttpContext.Current を導入しています。

これが私の洗練されていないマッシュアップです..変更は、try ブロックの 2 行です。

私の質問は次のとおりです。

• Darin のソリューションは、フォーム要素の存在を前提としていると考えるのは正しいですか?
• Darin の Web API フィルターを Johan の MVC 4 RC コードとマッシュアップするエレガントな方法は何ですか?

前もって感謝します！

他のすべてのコントローラーが継承するAntiForgeryTokensという名前のコントローラーにある ActionFilter を使用して、すべての HttpPost アクションで使用したいと考えています。ControllerBase

これを行うには、継承する ActionFilter を作成して、ValidateAntiForgeryTokenどの HTTP 動詞に適用するかを伝える引数を取ります。次に、そのフィルターを適用し て、サイト全体ですべての POST 操作がチェックさControllerBaseれるようにします。AntiForgeryToken

私はこのソリューションの使用を検討していましたが、

• AuthorizationContext Constructor (ControllerContext)は廃止されたコンストラクターが含まれており、推奨される を使用してコードを再構築する方法がわかりませんAuthorizationContext(ControllerContext controllerContext, ActionDescriptor actionDescriptor)。

• 次のエラーが発生するため、デフォルトで AntiForgeryToken を使用していないようですA required anti-forgery token was not supplied or was invalid。すべての投稿アクションの後。

[HttpPost]現在の廃止されていない基準を満たし、すべての動詞で偽造防止トークンを適切に使用するには、ActionFilter をどのように書き直す必要がありますか?

すべてのフォームに自分で偽造防止トークンを含める必要がありますか (そうすると思います)? （自動的に生成されるのではなく、笑わないでください、興味があります） 更新：コメントで指摘されたように。はい、これはすべてのフォームで行う必要があります。

参考までに、私の ControllerBase のコードを次に示します。

私のコントローラーでは、

私の見解では、投稿のためにこれを行っています.HTTP Getを使用してgetJSONのデータを取得できました. 問題は、ユーザーが名前にスペースを入れると、検証されずに 404 が返されることです。したがって、post メソッドを使用してこれを行うことができると思っていましたが、ログ名を送信できないようです。データをシリアル化して偽造防止トークンを送信する...

誰でも助けてもらえますか？私は感謝されます。

私はで深刻な問題に直面してい@Html.AntiForgeryToken()ます。新しいメンバーを作成/登録するための作成ビューを持つ登録コントローラーがあります。そのため@Html.AntiForgeryToken()、メインの送信フォームでSALTを使用せずに使用しました。ここで、ユーザー名テキストボックスのblurイベントでデータベースに既に存在する場合は、ユーザー名を検証したいと思います。この検証のために、「Validation」という名前の新しいコントローラーを作成し、一定の検証SALTを使用してメソッドを作成しました。

メソッドは正常に機能しています。を使用せずにHTTPGetアノテーションを確認したところ[ValidateAntiForgeryToken]、期待どおりの結果が得られました。

私はグーグルで検索し、与えられたソリューションの多くをチェックしましたが、これらはどれも機能していません。検証コントローラーでは、同じページで別のフォームを使用し、偽造防止トークンでSALTを使用しました。

例：メインの送信フォームの最初の偽造防止トークン：

@using（Html.BeginForm（ "Create"、 "Register"））{@ Html.AntiForgeryToken（）@ Html.ValidationSummary（true）...}

2番目の偽造防止トークン：

そしてjavascriptで私はこれを使用しました

私のfirebugで私はこれを手に入れました：

渡されたとおりですが、Cookieセクションで、渡したものとは異なるCookieを取得しました。実際のCookie：

これは、1ページに2つの偽造防止トークンを使用したためだと思います。ただし、最初の1つは送信を実行するために生成され、次の1つは検証を検証する必要があるため、私の考えでは2を使用する必要があります。しかし、これは私の推測であり、私は間違っていると思います。このため、皆さんの助けが必要です。

偽造防止を2つまたは1つ使用する必要があるという事実を誰かが説明できますか？

よろしくお願いします。

Web ページで、ユーザーが認証のためにクリックできるハイパーリンク (GET) を提供します。

これは、ビューを返す次のコントローラー メソッドにマップされます。

このビューには、ユーザーが資格情報を提供するフォームが含まれています。フォームには、必要な AntiForgeryToken が含まれています。

ユーザーがフォームを送信すると、次の Controller メソッドが呼び出されます。

ほとんどの場合、これは完全にうまく機能します...

ただし、ユーザーがブラウザを「かなりの」時間開いたままにしてから、次の手順を立て続けに実行した場合:

1. ハイパーリンク (GET) をクリックして、ログイン フォームを読み込みます。
2. フォームに入力して送信します

偽造防止トークンが提供されなかったか、無効であったことを通知する例外が発生します。

これが事実である理由がわかりません。ブラウザーが休止状態になった後にビュー (フォームを含む) が作成されるため、偽造防止トークンはすべて「新鮮」である必要があります。ただし、この設計には明らかに問題がありますが、それを修正する最善の方法がわかりません。

何か提案があれば、事前に感謝します。

グリフ