ASP.NET MS11-100：投稿されたフォーム値の最大数の制限を変更するにはどうすればよいですか？

Microsoftは最近（2011年12月29日）、. NET Frameworkのいくつかの深刻なセキュリティ脆弱性に対処するためのアップデートをリリースしました。MS11-100で導入された修正の1つは、ハッシュテーブルの衝突を含む潜在的なDoS攻撃を一時的に軽減します。この修正により、大量のPOSTデータを含むページが破損するようです。私たちの場合、非常に大きなチェックリストのあるページで。なぜこれが当てはまるのでしょうか？

一部の非公式ソースは、MS11-100がポストバックアイテムに500の制限を設定していることを示しているようです。これを確認するマイクロソフトの情報源が見つかりません。ビューステートと他のフレームワーク機能がこの制限の一部を使い果たしていることを知っています。この新しい制限を制御する構成設定はありますか？チェックボックスの使用から切り替えることもできますが、特定の状況ではかなりうまく機能します。パッチは他の厄介なものから保護するため、パッチを適用したいと思います。

500の制限について議論している非公式の出典：

このセキュリティ情報は、単一のHTTP POSTリクエストに対して送信できる変数の数に制限を設けることにより、DOS攻撃ベクトルを修正しています。デフォルトの制限は500ですが、これは通常のWebアプリケーションには十分ですが、ドイツのセキュリティ研究者が説明しているように攻撃を無効にするのに十分なほど低くなっています。

編集：制限の例を含むソースコード（500ではなく1,000のように見えます）標準のMVCアプリを作成し、次のコードをメインインデックスビューに追加します。

@using (Html.BeginForm()) 
{
    <fieldset class="fields">
        <p class="submit">
            <input type="submit" value="Submit" />
        </p>

        @for (var i = 0; i < 1000; i++)
        {
            <div> @Html.CheckBox("cb" + i.ToString(), true) </div>
        } 
    </fieldset>
}

このコードはパッチの前に機能しました。後は動作しません。エラーは：

[InvalidOperationException：オブジェクトの現在の状態のため、操作は無効です。]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded（）+82
System.Web.HttpValueCollection.FillFromEncodedBytes （Byte [] bytes、Encoding encoding）+111 System.Web。 HttpRequest.FillInFormCollection（）+307

この設定をweb.configに追加してみてください。ASP.NET MVC 2プロジェクトを使用して.NET 4.0でこれをテストしたところ、この設定ではコードでスローされません。

<appSettings>
  <add key="aspnet:MaxHttpCollectionKeys" value="1001" />
</appSettings>

これで（セキュリティ更新プログラムを適用した後）制限が変更されます。

私はまだマシンを更新していなかったので、Reflectorを使用してHttpValueCollectionクラスをチェックしましたが、それにはThrowIfMaxHttpCollectionKeysExceededメソッドがありませんでした。

KB2656351（.NET 4.0のアップデート）をインストールし、Reflectorでアセンブリをリロードすると、メソッドが表示されました。

したがって、その方法は間違いなく新しいものです。リフレクターで逆アセンブルオプションを使用しました。コードからわかるように、AppSettingをチェックしています。

if (this.Count >= AppSettings.MaxHttpCollectionKeys)
{
  throw new InvalidOperationException();
}

web.configファイルで値が見つからない場合は、1000に設定されますSystem.Web.Util.AppSettings.EnsureSettingsLoaded（内部静的クラス）。

 _maxHttpCollectionKeys = 0x3e8;

また、Alexey Gusarovはこの設定について2日前にツイートしました。

• http://twitter.com/#!/tr_tr_mitya/status/152473667102715904
• http://twitter.com/#!/tr_tr_mitya/status/152475158941138944

そして、ここにジョナサンネス（セキュリティ開発マネージャー、MSRC）とピート・ヴォス（シニアレスポンスCommunications Managerの、信頼できるコンピューティング）とのQ＆Aから公式の答えは次のとおりです。

Q：AppSettings.MaxHttpCollectionKeysは、フォームエントリの最大数を含む新しいパラメーターですか？

A：はい、そうです。

まだ.NET 1.1を使用している人にとって、この設定はweb.configを介して構成されていません-これはレジストリ設定です（michielvooへのヒント、私はReflectorで答えを見つけたのと同じ方法でこれを発見しただけです）。以下の例はMaxHttpCollectionKeys、32ビット版のWindowsでは5000に設定されています。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\1.1.4322.0]
"MaxHttpCollectionKeys"=dword:00001388

64ビットWindowsエディションの場合、Wow6432Nodeの下にキーを設定します。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\1.1.4322.0]
"MaxHttpCollectionKeys"=dword:00001388

奇妙なものを見た人のために、ここに$ 0.02を追加したいだけです。

アプリケーションがページ情報をASP.NET ViewStateに格納し、Webサーバーのしきい値を超えると、この問題が発生します。web.config修正問題をすぐに適用するのではなく、最初にコードの最適化を確認することをお勧めします。

ソースを表示し、1000以上のビューステート非表示フィールドを探します。問題があります。

ThrowIfMaxHttpCollectionKeysExceeded()にも追加されましたSystem.Web.HttpCookieCollection。

HttpCookieCollection.Get()が呼び出されたときのように見えます。内部的にが呼び出されHttpCookieCollection.AddCookie()、次にが呼び出されThrowIfMaxHttpCollectionKeysExceeded()ます。

public HttpCookie Get(string name)
{
    HttpCookie cookie = (HttpCookie) base.BaseGet(name);
    if ((cookie == null) && (this._response != null))
    {
        cookie = new HttpCookie(name);
        this.AddCookie(cookie, true);
        this._response.OnCookieAdd(cookie);
    }
    return cookie;
}

internal void AddCookie(HttpCookie cookie, bool append)
{
    this.ThrowIfMaxHttpCollectionKeysExceeded();
    this._all = null;
    this._allKeys = null;
    if (append)
    {
        cookie.Added = true;
        base.BaseAdd(cookie.Name, cookie);
    }
    else
    {
        if (base.BaseGet(cookie.Name) != null)
        {
            cookie.Changed = true;
        }
        base.BaseSet(cookie.Name, cookie);
    }
}

私たちが見ているのは、ウェブサイトがをスローし始めるまで、数時間かけてウェブサイトが徐々に遅くなり、バグが増えることInvalidOperationExcpetionです。その後、アプリプールをリサイクルします。これにより、問題がさらに数時間修正されます。