.NET 4.5 では、オプションでランダム化された文字列ハッシュ コード生成を使用できます。つまり、異なるアプリケーション ドメインで計算された同じ文字列のハッシュ コードは異なります。( http://msdn.microsoft.com/en-us/library/jj152924.aspxを参照)
問題は、このオプションの実用的な用途は何ですか? つまり、どのシナリオ (シナリオ) でスイッチをオンにする必要がありますか?
.NET 4.5 では、オプションでランダム化された文字列ハッシュ コード生成を使用できます。つまり、異なるアプリケーション ドメインで計算された同じ文字列のハッシュ コードは異なります。( http://msdn.microsoft.com/en-us/library/jj152924.aspxを参照)
問題は、このオプションの実用的な用途は何ですか? つまり、どのシナリオ (シナリオ) でスイッチをオンにする必要がありますか?
これの一般的な用途は、ハッシュ メカニズムに対する DoS 攻撃の可能性を防ぐことだと思います。
GetHashCode()
は などによって内部的に使用されるためDictionary<,>
、「通常の」データに対しては、ハッシュの衝突が「頻繁に」発生しないように、ハッシュ値を適切に分散する必要があります。ハッシュ衝突が発生するDictionary<,>
と、同じハッシュ コードを持つすべてのアイテムの線形検索にフォールバックします。
一般にアクセス可能なアプリケーションでは、ハッシュ メカニズムの知識を持つ攻撃者が、同一のハッシュ コードを持つ多数の文字列を含むリクエストを送信する可能性があります。その結果、通常は O(1) ルックアップが O(N) ルックアップになります。これらの値が追加された辞書。
特にWebアプリケーションの場合、ヘッダーやクエリ文字列パラメーターなどのものが辞書に追加され、アプリケーションがすばやくアクセスできるようになると思います。そのため、敵対者は衝突するハッシュを含む数千のパラメーターを含むリクエストを送信でき、その結果、リクエストははるかに多くなります「通常の」リクエストよりもリソースを消費します。これはあらゆる DoS 攻撃に対して増幅効果をもたらし、攻撃者が利用できる帯域幅が比較的わずかしかない場合でも攻撃を実行できるようにします。
AppDomain ごとにハッシュ値をランダム化することで、攻撃者が衝突するハッシュを使用して文字列を作成できる可能性が低くなり、そのような攻撃を防ぐことができます。
宛名コメントを編集します。
MSDN の記事では言及されていませんが、設定の意図は、異なる AppDomains に異なる文字列ハッシュを作成させる手段を提供することではなく、サード パーティが同じハッシュを持つ多くの文字列を作成するのを防ぐためのセキュリティ機能です。
.NET 4.5 より前 (またはこの設定を無効にした状態) では、あなたと同じ .NET バージョンを実行していた場合、"some string".GetHashCode()
私のマシンではあなたのマシンと同じ値が返されます。使用されるハッシュ メカニズムは単純であるため (そして、暗号学的に安全なハッシュではないことは確かです)、比較的簡単にリバース エンジニアリングを行い、同一のハッシュを持つ多数の文字列を作成し、上記のようにこれらを使用して DoS 攻撃を増幅します。
この設定を有効にすると、文字列のハッシュ コード生成にランダム性の要素が追加され、攻撃者が衝突する文字列を確実に作成することがはるかに困難になります。
AppDomain ごとであるという事実は、ハッシュ コードに特定の必須プロパティがあるという事実の副産物です。たとえば、2 つの同一の文字列には同一のハッシュ コードがあります。したがって、AppDomain は、この設定を有効にすると、ほとんどのアプリケーションが完全に正常に動作するという点で、設定の効果に適切な境界を提供します。
この新しい設定は、この脆弱性の開示で提起された問題にさらに対処する可能性があります: CVE-2011-3414 ASP.NET アプリケーションでのハッシュ衝突の悪用に関連しています (この問題は、キーの数を制限することにより、他の .NET バージョンでは「修正」されたと思います)要求で提供される可能性があり、攻撃者が非常に多くの衝突を作成してパフォーマンスが大幅に低下するのを防ぎます)。参照された論文では、この問題が広範囲に及ぶ性質の要因として、ランダム化された文字列ハッシュの欠如が具体的に言及されています。