ASP.NET MS11-100: ¿cómo puedo cambiar el límite en el número máximo de valores de formulario publicados?

Microsoft recientemente (29-12-2011) lanzó una actualización para abordar varias vulnerabilidades de seguridad graves en .NET Framework. Una de las soluciones introducidas por MS11-100 mitiga temporalmente un posible ataque DoS que involucra colisiones de tablas hash. Parece que esta solución rompe páginas que contienen muchos datos POST. En nuestro caso, en páginas que tienen listas de casillas de verificación muy grandes. Por qué sería este el caso?

Algunas fuentes no oficiales parecen indicar que MS11-100 establece un límite de 500 en artículos de devolución. No puedo encontrar una fuente de Microsoft que confirme esto. Sé que View State y otras características del marco consumen parte de este límite. ¿Hay alguna configuración que controle este nuevo límite? Podríamos dejar de usar casillas de verificación, pero funciona bastante bien para nuestra situación particular. También nos gustaría aplicar el parche porque protege contra otras cosas desagradables.

Fuente no oficial que discute el límite de 500:

El boletín corrige el vector de ataque de DOS al proporcionar un límite al número de variables que se pueden enviar para una sola solicitud HTTP POST. El límite predeterminado es 500, que debería ser suficiente para las aplicaciones web normales, pero lo suficientemente bajo como para neutralizar el ataque como lo describen los investigadores de seguridad en Alemania.

EDITAR: Código fuente con ejemplo de límite (que parece ser 1,000, no 500) Cree una aplicación MVC estándar y agregue el siguiente código a la vista del índice principal:

@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>
}

Este código funcionó antes del parche. No funciona después. El error es:

[InvalidOperationException: la operación no es válida debido al estado actual del objeto.]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded () +82 System.Web.HttpValueCollection.FillFromEncodedBytes (Byteding)
. HttpRequest.FillInFormCollection () +307

Intente agregar esta configuración en web.config. Acabo de probar esto en .NET 4.0 con un proyecto ASP.NET MVC 2 y con esta configuración su código no arroja:

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

Eso debería funcionar ahora (después de haber aplicado la actualización de seguridad) para cambiar el límite.

Todavía no había actualizado mi máquina, así que usando Reflector verifiqué la clase HttpValueCollection y no tenía el ThrowIfMaxHttpCollectionKeysExceededmétodo:

Instalé KB2656351 (actualización para .NET 4.0), volví a cargar los ensamblajes en Reflector y apareció el método:

Entonces ese método es definitivamente nuevo. Utilicé el desmontaje opción en Reflector y, por lo que puedo ver en el código, comprueba una configuración de aplicación:

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

Si no encuentra el valor en el archivo web.config, lo establecerá en 1000 in System.Web.Util.AppSettings.EnsureSettingsLoaded(una clase estática interna):

 _maxHttpCollectionKeys = 0x3e8;

Además, Alexey Gusarov tuiteó sobre esta configuración hace dos días:

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

Y aqui hay una respuesta oficial de un Q&A con Jonathan Ness (Gerente de Desarrollo de Seguridad, MSRC) y Pete Voss (Gerente Senior de Comunicaciones de Respuesta, Computación Confiable):

P: ¿AppSettings.MaxHttpCollectionKeys es el nuevo parámetro que contiene el número máximo de entradas de formulario?

R: sí lo es.

Para aquellos de ustedes que todavía usan .NET 1.1, esta configuración no está configurada a través de web.config: es una configuración de registro (hat tip to michielvoo, ya que solo descubrí esto a través de Reflector de la misma manera que encontró la respuesta). El siguiente ejemplo se establece MaxHttpCollectionKeysen 5000 en las ediciones de Windows de 32 bits:

Windows Registry Editor Version 5.00

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

Para una edición de Windows de 64 bits, configure la clave debajo del nodo Wow6432:

Windows Registry Editor Version 5.00

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

Solo quiero agregar mis $ 0.02 aquí para las personas que ven la rareza.

Si su aplicación oculta información de la página en ASP.NET ViewState y supera el umbral del servidor web, se encontrará con este problema. En lugar de aplicar el problema de solución web.config de inmediato, es posible que desee echar un vistazo a la optimización de su código primero.

Ver código fuente, y buscar más de 1000 campos ocultos de estado de vista, y tiene su problema.

ThrowIfMaxHttpCollectionKeysExceeded()también se ha agregado a la System.Web.HttpCookieCollection.

Parece que cuando HttpCookieCollection.Get()se llama, está llamando internamente HttpCookieCollection.AddCookie(), que luego está llamando 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);
    }
}

Lo que estamos viendo es que durante un período de un par de horas, el sitio web se vuelve progresivamente más lento y con errores, hasta que comienza a arrojarse InvalidOperationExcpetion. Luego reciclamos el grupo de aplicaciones, que soluciona el problema por unas horas más.