ASP.NET MS11-100: як я можу змінити обмеження на максимальну кількість розміщених значень форми?

Нещодавно (12-29-2011) Microsoft випустила оновлення для вирішення кількох серйозних вразливих місць безпеки в .NET Framework. Одне з виправлень, введених MS11-100, тимчасово пом’якшує потенційну атаку DoS, пов’язану зі збоями хеш-таблиць. Здається, це виправлення розбиває сторінки, які містять багато даних POST. У нашому випадку на сторінках, які мають дуже великі списки прапорців. Чому це було б так?

Деякі неофіційні джерела, схоже, вказують на те, що MS11-100 встановлює обмеження в 500 на позиції після зворотного зв'язку. Я не можу знайти джерело Microsoft, яке це підтверджує. Я знаю, що функція View State та інші рамкові функції з'їдають частину цієї межі. Чи є якісь налаштування конфігурації, які керують цим новим обмеженням? Ми можемо перейти від використання прапорців, але це працює досить добре для нашої конкретної ситуації. Ми також хотіли б застосувати патч, оскільки він захищає від деяких інших неприємних речей.

Неофіційне джерело, що обговорює межу 500:

Бюлетень фіксує вектор атаки DOS, забезпечуючи обмеження кількості змінних, які можуть бути подані для одного HTTP POST-запиту. Ліміт за замовчуванням - 500, що повинно вистачити для звичайних веб-додатків, але все ще досить низьке для нейтралізації атаки, як описано дослідниками безпеки в Німеччині.

EDIT: Вихідний код із прикладом ліміту (який здається 1000, а не 500) Створіть стандартний додаток 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 (Системні байоди)
. HttpRequest.FillInFormCollection () +307

Спробуйте додати це налаштування в web.config. Я щойно перевірив це на .NET 4.0 з проектом ASP.NET MVC 2, і за допомогою цього параметра ваш код не кидає:

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

Це має працювати зараз (після застосування оновлення безпеки), щоб змінити ліміт.

Я ще не оновлював свою машину, тому за допомогою Reflector я перевірив клас HttpValueCollection, і у нього не було ThrowIfMaxHttpCollectionKeysExceededметоду:

Я встановив KB2656351 (оновлення для .NET 4.0), перезавантажив збірки в Reflector і з'явився метод:

Тож цей метод, безумовно, новий. Я використовував параметр Disassemble в Reflector, і з того, що я можу сказати з коду, він перевіряє AppSetting:

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

Якщо він не знайде значення у файлі web.config, він встановить його в 1000 у System.Web.Util.AppSettings.EnsureSettingsLoaded(внутрішній статичний клас):

 _maxHttpCollectionKeys = 0x3e8;

Також Олексій Гусаров написав твіт про це налаштування два дні тому:

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

А ось офіційна відповідь від Q & A з Джонатаном Несс (Security Менеджер по розвитку, MSRC) і Піт Восс (Sr. Response Communications Manager, Trustworthy Computing):

Q: Чи є AppSettings.MaxHttpCollectionKeys новий параметр, який містить максимальну кількість записів форми?

Відповідь: Так.

Для тих, хто все ще використовує .NET 1.1, цей параметр не налаштовано через web.config - це налаштування реєстру (капелюх для michielvoo, оскільки я виявив це лише через Reflector так само, як він знайшов відповідь). Наведений нижче приклад задає MaxHttpCollectionKeys5000 для 32-розрядних версій Windows:

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.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. Потім ми переробляємо пул додатків, який вирішує проблему ще кілька годин.