問題タブ [antiforgerytoken]

ELMAHを使用してMVCサイトのエラーを処理していますが、過去2週間で、CryptographicExceptionsがスローされることに気づきました。メッセージは次のとおりです。

System.Security.Cryptography.CryptographicException：パディングが無効であり、削除できません。

System.Web.Mvc.HttpAntiForgeryException：必要な偽造防止トークンが提供されていないか、無効でした。---> System.Web.HttpException：ビューステートMACの検証に失敗しました。このアプリケーションがWebファームまたはクラスターによってホストされている場合は、構成で同じvalidationKeyと検証アルゴリズムが指定されていることを確認してください。AutoGenerateはクラスターでは使用できません。--->

アプリケーションがクラスターで実行されておらず、これらのエラーを再現できないようです。それらは有効なリクエストのように見えます-手作りの投稿ではありません-そして__RequestVerificationTokenクッキーを含んでいます。フォーム（ログインフォーム）内のページに必要なHTMLヘルパーがあります。

ユーザーからの苦情はまだないので、最終的にはログインしようとしている人なら誰でもうまくいくと思いますが、なぜこれが起こるのか疑問に思っています。

他の誰かがこの振る舞いを見たり、例外を診断する方法について何か考えを持っている-私が言ったように、私はそれを失敗させることはできません。FFでCookieを削除すると、別のエラーが発生します。Cookieを変更する（コンテンツを変更または削除する）と、ページに入力された非表示のトークンのコンテンツを変更する場合と同様に、別のエラーが発生します。

私は自分の会社のウェブサイトのセキュリティを向上させることに取り組んでおり、簡単に維持できる偽造の試みを防ぐトークンを作成したいと考えました。これが私が思いついたものです。

MasterPage の基本クラスには、次の名前のプロパティでラップされた HiddenField があります。ReferenceToken

セッション内にトークンを格納する StructureMap ハンドルを持っているので、ユーザー セッションごとに永続化されます。これはすべて、偽造防止スキームの有効な実装でしょうか?

編集:私の質問にはいくつかの混乱があるようです。はい、 ASP.NET MVC には AntiForgeryToken スキームが組み込まれていることを理解しています。この質問は、CSRF 攻撃 (クロス サイト リクエスト フォージェリ）。これにより、ユーザー権限の適切な承認が不要になるわけではないことを理解しています。

@Neal と @solairaja が投稿したまさにそのリンクを表示するつもりでした: ASP.NET MVC の AntiForgeryToken() helper を使用して Cross-Site Request Forgery (CSRF) を防止します。この記事では、CSRF 攻撃とは何か、MVC がそれをどのように阻止するかについて詳しく説明しますが、その解決策は Web フォームには適用できないため、独自の実装に取り​​掛かりました。

@Neal からの応答を見た後、GUID の作成を置き換える可能性が最も高い MVC ツールから実際のソース コードを取得できることに気づかなかったので、それが受け入れられる可能性が最も高いと思います。しかし、他の誰かが追加する価値のある情報を持っている場合に備えて、質問を開いたままにします.

興味深い問題があります...変更を本番環境にプッシュする前に、Web アプリケーションが IBM アプリ スキャン アプライアンスを通過する必要があります。私の最新の変更には、ASP.NET MVC の AntiForgeryToken が含まれています。これをテストしたすべてのブラウザは問題なく動作します。しかし、アプライアンスがフォームを送信しようとすると、検証エラーが発生します。検証トークンを見ると、アプライアンスは投稿のフォーム値で html エンコードを行っているため、文字列が一致しません...これは次のようになります。

cmiuJRHizXLPvlu9zHKmTwdJiHvq+n87CSJZkixkf/BLHayCPVITJhRCsWWirPWg - Cookie から取得

つまり、+ を %2B に、/ を %2F に変換しています... 誰かこれを見たことがありますか? これはクライアント ブラウザの問題ですか? また、このスキャンでアプリを取得できるように、特殊文字を含まない文字列を生成する AntiForgeryToken がありますか? ありがとう！

ASP.NET MVC とテスト ケース プロジェクトでは、

コントローラー メソッドの既存のセキュリティ エクスプロイトに対してテストするテスト ケースを作成するにはどうすればよいでしょうか?

たとえば、偽造防止トークンが必要な呼び出しのテスト ケースをどのように作成しますか? それともXSS？

HTML フォームにテキスト フィールドを動的に追加し、jQuery を介してそのフォームの POST 要求を ASP.NET MVC コントローラーに実行します。

コントローラー アクションで ValidateAntiForgeryToken 属性を指定せずに POST 要求を呼び出すと、正常に動作します。しかし、ValidateAntiForgeryToken 属性をアクションに追加すると、次の例外が発生します。

「必要な偽造防止トークンが提供されなかったか、無効でした。」

なぜこれが考えられるのか、誰かアイデアはありますか？

注意点の 1 つは、Cookie のトークン ID が、フォームでレンダリングされたトークンとはまったく異なるように見えることです。なぜこれらは異なるのでしょうか？

アクション：

フォーム (レンダリングされたもの):

偽造防止トークンをレンダリングする元のビュー:

私の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のその他の考えられる原因を尋ねます。

ASP.NET MVC を使用して構築したアプリケーションでペネトレーション テストを実行したところ、返された推奨事項の 1 つは、フォーム内の AntiForgeryToken の値を複数回再送信でき、期限切れにならないというものでした。 1回の使用後。

Synchronizer Token Patternに関する OWASP の推奨事項によると、次のようになります。

「一般に、開発者は現在のセッションでこのトークンを 1 回生成するだけで済みます。」

これが、ASP.NET MVC AntiForgeryToken が機能すると私が考える方法です。

戦いを戦わなければならない場合、各検証後に AntiForgeryToken に新しい値を再生成させることは可能ですか?

私のビューでは、jQuery$.ajax呼び出しによって呼び出されている基本的なJsonResultメソッドがあります。

だから私の質問は、このメソッドが呼び出され/ハッキングされて誤ったデータが渡される可能性があるかどうかです。システム内に新しいユーザーを作成することだったとしましょう。このメソッドの呼び出しを偽造できますか？ある種の偽造防止トークンなどを使用して、このメソッドをどのように保護する必要がありますか？

私はいくつかのフォームを持つ公開サイトを持っています。

簡単な質問:
AntiForgeryToken の検証が失敗した場合、どのような情報を表示する必要がありますか?

404 (ページが見つかりません)、エラー、または単に無視してホームページにリダイレクトする必要がありますか?

最近、ソリューションを MVC 2 に更新しました。これにより、AntiForgeryToken動作が更新されました。残念ながら、これはもはや AJAX フレームワークには適合しません。

Name問題は、MVC 2 が対称暗号化を使用して、ユーザーのプロパティ (から)を含む、ユーザーに関する一部のプロパティをエンコードすることIPrincipalです。AJAX を使用して新しいユーザーを安全に登録できます。その後、ユーザーに新しいプリンシパルが付与されると偽造防止トークンが変更されるため、その後の AJAX 呼び出しは無効になります。ユーザーが自分の名前を更新するなど、これが発生する可能性がある他のケースもあります。

私の主な質問は、なぜ MVC 2 がわざわざ対称暗号化を使用するのかということです。では、プリンシパルのユーザー名プロパティを気にするのはなぜでしょうか?

私の理解が正しければ、ランダムな共有シークレットで十分です。基本的な原則は、特定のデータ (HttpOnly!) を含む Cookie がユーザーに送信されることです。この Cookie は、副作用 (通常は POST) を持つ可能性のある各要求で返されるフォーム変数と一致するために必要です。これはクロスサイト攻撃から保護することのみを目的としているため、テストに簡単に合格する応答を簡単に作成できますが、それは Cookie に完全にアクセスできる場合に限られます。クロスサイト攻撃者はユーザー Cookie にアクセスできないため、保護されます。

対称暗号化を使用することで、Cookie の内容を確認する利点は何ですか? つまり、既に HttpOnly Cookie を送信している場合、攻撃者は (ブラウザに重大なセキュリティ上の問題がない限り) それを上書きすることはできません。

考えてみると、これは「追加されたセキュリティ層」のケースの 1 つであるように見えますが、防御の第 1 ラインが落ちた場合 (HttpOnly)、攻撃者は完全なアクセス権を持っているため、とにかく第 2 層を通り抜けようとしています。間接的な XSS/CSRF 攻撃を使用する代わりに、ユーザーの Cookie コレクションに直接なりすますことができます。

もちろん、大きな問題を見落としている可能性もありますが、まだ見つかっていません。ここで明らかな問題または微妙な問題が発生している場合は、それらに注意したいと思います。