2011年12月28日にUS-CERTは、ハッシュテーブルの衝突を処理する方法のために、DOS攻撃の脆弱性を持つ大部分のWebサーバーに関する情報を公開しました。記事hereasp.netハッシュテーブルの脆弱性
誰かが、このハッシュテーブルがASP.NETライフサイクルに適合する場所を教えてください。それはセッションごとに1つのハッシュテーブルか、サーバーインスタンスごとに1つの大きなハッシュテーブルですか？
は、アプリケーションのではないだけで、一度場所全体で使用される、 フィデル問題のハッシュテーブルはRequest.Formです。
サーバーはフォームデータを解析し、キーと値のペアをRequest.Formコレクションに配置します。フォームデータに同じハッシュコードを生成するキーが含まれていると、ハッシュコリジョンが生成され、ハッシュテーブルのパフォーマンスが低下します。
サーバーごとまたはセッションごとに1つのテーブルではなく、POST要求ごとに1つのテーブルです。
根底にある欠陥はすべてのハッシュテーブルにあると思います。 1回のリクエストにつき1回だけではありません。最大のヒットは通常POSTを使用していますが、アプリケーションが内部的にハッシュテーブルを使用すると、それにも影響します。 –
@JohnMitchell：リクエストデータのキーを使ってハッシュテーブルを作成し、それがDoS攻撃に耐えることができる場合に限ります。他のデータからハッシュテーブルを作成すると、入力の影響を受けません。 – Guffa
しかし、ユーザの入力とその重複（つまり、バケットの衝突を引き起こすデータ）を解析すると、これがDDosとして使用される可能性があります。このときの障害は、衝突が処理されるまでの時間です。したがって、この記事ではPOSTについてのベクトルとして具体的に述べていますが、他のベクターは簡単に使用できます。 –
ハッシュテーブルをいただき、ありがとうございます。たとえば、ポスト変数をページに追加すると、ハッシュテーブル内で内部的に処理されるため、ハッシュテーブルの衝突が大量に発生した場合（つまり、ページに同じ名前の変数をポストすると、ここで発生します）。これは、単語の集まりを使用して "配列"にアクセスするための非常に効率的なメモリストレージシステムです（辞書を考える）。
これは悪用される可能性がありますが、ベストプラクティスを使用し、CPU使用率を監視し、1ページあたりの最大POSTサイズを制限し、単一のホストから要求を制限する方が良い方法です。
申し訳ありませんが、データごとにハッシュテーブルを追加しましたこれは、それを使用するデータの種類ごとに1つになります。そのため、ページごとおよびセッションごとに、ディクショナリスタイルのオブジェクトを必要とするページ上のデータ項目ごとの単なるセッション以上のものが使用されます。どのくらいの頻度で使用されているかを見たい場合は、配列のようにハッシュテーブルを考えてみてください。 –
http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx –