web-dev-qa-db-ja.com

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

マイクロソフトは最近（2011年12月29日）、. NET Frameworkのいくつかの深刻なセキュリティ脆弱性に対処する更新プログラムをリリースしました。 MS11-1 によって導入された修正の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

asp.netpostms11-100
196
colithium

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

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

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

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

enter image description here

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

enter image description here

したがって、その方法は間違いなく新しいものです。 ReflectorでDisassembleオプションを使用し、コードからわかることからAppSettingをチェックします。

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

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

 _maxHttpCollectionKeys = 0x3e8;

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

here は、ジョナサンネス（セキュリティ開発マネージャー、MSRC）およびピートヴォス（シニアレスポンスコミュニケーションマネージャー、Trustworthy Computing）とのQ＆Aからの公式回答です。

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

A：はい。

275
Michiel van Oosterhout

まだ.NET 1.1を使用している場合、この設定はweb.configを介して構成されません-これはレジストリ設定です（michielvooのヒントです。これは、Reflectorで答えを見つけたのと同じ方法で発見したためです）。次の例では、32ビット版のWindowsでMaxHttpCollectionKeysを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
18
terranwannabe

奇妙さを見ている人のために、ここに0.02ドルを追加したいだけです。

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

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

4
Eyeless Whim

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をスローし始めるまで、徐々に遅くなりバグが増えていくということです。次に、アプリプールをリサイクルします。これにより、問題がさらに数時間修正されます。

3
Joshua Barker