asp.net - リプレイ攻撃を防ぐにはどうすればよいですか?

Question

これは、私が尋ねた別の質問に関連しています。要約すると、フォームが POST されたときに、認証やユーザーのセッションの維持のために Cookie に頼ることができない URL の特殊なケースがあります。彼らがログインしていることを知るために！

問題の解決策を思いついたと思いますが、具体化する必要があります。これが私が考えていることです。「username」という非表示のフォームフィールドを作成し、その中にユーザーのユーザー名を暗号化して配置します。次に、フォームが POST すると、ブラウザーから Cookie を受信しなくても、非表示のフォームフィールドを解読してユーザー名を取得できるため、ログインしていることがわかります。

私が見ることができる主要なセキュリティ上の欠陥は、リプレイ攻撃です。誰かがその暗号化された文字列を入手して、そのユーザーとして投稿するのを防ぐにはどうすればよいですか? SSL を使用してその文字列を盗みにくくすることができることはわかっています。暗号化キーを定期的にローテーションして、文字列が有効な時間を制限することもできますが、防弾を見つけたいと思っています。解決。誰にもアイデアはありますか？ASP.Net ViewState は再生を妨げますか? もしそうなら、彼らはどのようにそれをしますか?

編集：データベースに何も保存する必要のないソリューションを望んでいます。アプリケーションの状態は問題ありませんが、IIS の再起動に耐えられないか、Web ファームまたはガーデンシナリオでまったく機能しません。データベースなしでこれを保護することさえ可能であると確信していないので、今のところクリスの答えを受け入れています。しかし、誰かがデータベースに関係のない答えを思いついたら、私はそれを受け入れます!

score 15 · Accepted Answer

ユーザー名とパスワードとともにタイムスタンプをハッシュすると、リプレイ攻撃のウィンドウを数秒以内に閉じることができます。これがあなたのニーズを満たすかどうかはわかりませんが、少なくとも部分的な解決策です。

score 14 · Accepted Answer

ここにはいくつかの良い答えがあり、それらをすべてまとめると、最終的に答えがあります。

ブロック暗号暗号化（AES-256 +を使用）およびハッシュ（SHA-2 +を使用）して、クライアントに送信されるすべての状態/ノンス関連情報。それ以外のハッカーは、データを操作し、それを表示してパターンを学習し、他のすべてを回避します。覚えておいてください...開いているウィンドウは1つだけです。
POSTリクエストとともに返送されるリクエストごとに1回限りのランダムで一意のナンスを生成します。これは2つのことを行います。POST応答がその要求に対応することを保証します。また、特定のget / POSTペアのセットの1回限りの使用を追跡することもできます（再生を防止します）。
タイムスタンプを使用して、ナンスプールを管理しやすくします。上記の＃1に従って、タイムスタンプを暗号化されたCookieに保存します。アプリケーションの最大応答時間またはセッション（たとえば、1時間）より古い要求はすべて破棄します。
暗号化されたタイムスタンプデータを使用して、要求を行うマシンの「合理的に一意の」デジタル指紋を保存します。これにより、攻撃者がクライアントのCookieを盗んでセッションハイジャックを実行するという別のトリックを防ぐことができます。これにより、リクエストが1回だけでなく、フォームが送信されたマシンから（または攻撃者がコピーすることを事実上不可能にするほど近くに）戻ってくることが保証されます。

上記のすべてをゼロコーディングで実行するASPNETおよびJava/J2EEセキュリティフィルターベースのアプリケーションがあります。大規模なシステム（株取引会社、銀行、大量の安全なサイトなど）のナンスプールを管理することは、パフォーマンスが重要な場合は簡単な作業ではありません。Webアプリケーションごとにこれをプログラムするのではなく、これらの製品を確認することをお勧めします。

score 13 · Accepted Answer

本当に状態を保存したくない場合は、タイムスタンプと短い有効期限を使用してリプレイ攻撃を制限するのが最善だと思います。たとえば、サーバーは次のように送信します。

{Ts, U, HMAC({Ts, U}, Ks)}

Ts はタイムスタンプ、U はユーザー名、Ks はサーバーの秘密鍵です。ユーザーはこれをサーバーに送り返し、サーバーは提供された値の HMAC を再計算して検証します。有効な場合は、いつ発行されたかがわかります。たとえば、5 分より古い場合は無視することを選択できます。

このタイプの開発に適したリソースは、Web 上のクライアント認証の推奨事項と禁止事項です。

score 5 · Accepted Answer

ユーザー名とともに使用されるある種のランダムなチャレンジ文字列を使用して、ハッシュを作成できます。チャレンジ文字列をサーバーのデータベースに保存すると、それが一度だけ使用され、特定の 1 人のユーザーに対してのみ使用されるようにすることができます。

score 2 · Accepted Answer

「リプレイ」攻撃を阻止するアプリの 1 つで、セッションオブジェクトに IP 情報を挿入しました。コードでセッションオブジェクトにアクセスするたびに、必ず Request.UserHostAddress を渡してから、IP が一致していることを確認します。そうでない場合は、明らかにその人以外の誰かがこのリクエストを行ったので、null を返します。これは最善の解決策ではありませんが、リプレイ攻撃を阻止するための少なくとも 1 つの障壁になります。

score 1 · Accepted Answer

（リプレイ攻撃は、IP / MACスプーフィングに関するものである可能性があり、さらに動的IPに挑戦する可能性があります）

ここでのリプレイだけでなく、単独では意味がありません。SSLを使用し、手作りは避けてください。

ASP.Net ViewStateは混乱しているので、避けてください。PKIは重量があり肥大化していますが、少なくとも独自のセキュリティ「スキーム」を発明しなくても機能します。ですから、できればそれを使って、常に相互認証を求めます。サーバーのみの認証はまったく役に立ちません。

score 1 · Accepted Answer

私は Web プログラミングのいくつかの側面に不慣れですが、先日これを読んでいました。Nonceを使用する必要があると思います。

score 1 · Accepted Answer

メモリまたはデータベースを使用して、ユーザーまたは要求に関する情報を維持できますか?

もしそうなら、フォームのリクエストに応じて、内容がランダムに生成された数字である非表示のフォームフィールドを含めます。リクエストがレンダリングされるときに、このトークンをアプリケーションコンテキストまたは何らかのストア (データベース、フラットファイルなど) に保存します。フォームが送信されたら、アプリケーションコンテキストまたはデータベースをチェックして、ランダムに生成された番号がまだ有効かどうかを確認します (ただし、有効と定義しても、おそらく X 分後に有効期限が切れる可能性があります)。その場合は、「許可されたトークン」のリストからこのトークンを削除してください。

したがって、リプレイされたリクエストには、サーバー上で有効と見なされなくなった同じトークンが含まれます。

score 1 · Accepted Answer

ViewState にはセキュリティ機能が含まれています。ASP.NET に組み込まれているセキュリティ機能の一部については、この記事を参照してください。サーバー上の machine.config のサーバー machineKey に対して検証を行い、各ポストバックが有効であることを確認します。

この記事のさらに下ではLosFormatter、独自の非表示フィールドに値を格納する場合、クラスを使用して、ViewState が暗号化に使用するのと同じ方法で値をエンコードできることもわかります。

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

score 0 · Accepted Answer

各キーを 1 回だけ受け入れると (たとえば、キーを GUID にして、戻ってきたときに確認する)、リプレイが妨げられます。もちろん、攻撃者が最初に応答すると、新たな問題が発生します...

score 0 · Accepted Answer

これは WebForms ですか、それとも MVC ですか? MVC の場合は、AntiForgery トークンを利用できます。これは、基本的にGUIDを使用し、その投稿のguid値でCookieを設定することを除いて、あなたが言及したアプローチに似ているようです。詳細については、Steve Sanderson のブログをご覧ください: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

もう1つ、ポストバックでリファラーを確認することを検討しましたか? これは防弾ではありませんが、役立つ場合があります。

asp.net - リプレイ攻撃を防ぐにはどうすればよいですか?

12 に答える 12

Related

Reference