8

最近、ソリューションを 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 コレクションに直接なりすますことができます。

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

4

2 に答える 2

6

これは、1 つのサブドメインが別のサブドメインを攻撃しようとしている場合 (bad.example.com が good.example.com を攻撃しようとしている場合) に、より強力な保護を提供するために追加されました。ユーザー名を追加すると、bad.example.com が裏で good.example.com に連絡して、あなたに代わってトークンを生成しようとすることが難しくなります。

今後、Cookie はシステムの適切な機能に厳密には必要ないため、削除される可能性があります。(たとえば、フォーム認証を使用している場合、そのCookie は、システムに 2 番目の Cookie の生成を要求する代わりに、アンチ XSRF Coo​​kie として機能できます。) Cookie は、たとえば、匿名ユーザーの場合にのみ発行される場合があります。

于 2010-04-23T16:46:12.460 に答える
2

Levi によって概説された「悪のサブドメイン」シナリオに加えて、標的のサイトにアカウントを持つ攻撃者を考えてみましょう。CSRF トークンがユーザー固有の情報をエンコードしない場合、サーバーは、トークンがログイン ユーザー専用に生成されたことを確認できません。攻撃者は、偽造されたリクエストを作成する際に、正当に取得した独自の CSRF トークンの 1 つを使用する可能性があります。

そうは言っても、匿名トークンは特定の状況で ASP.NET MVC によって受け入れられます。ValidateAntiForgeryTokenAttribute が匿名トークンを許可する理由を参照してください。

于 2015-03-12T07:30:46.277 に答える