ASP.NET MS11-100: ¿cómo puedo cambiar el límite de la cantidad máxima de valores de formulario publicados?

Recientemente, Microsoft (12-29-2011) publicó una actualización para abordar varias vulnerabilidades graves de seguridad 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 este arreglo rompe páginas que contienen una gran cantidad de datos POST. En nuestro caso, en páginas que tienen listas de casillas muy grandes. Por qué sería este el caso?

Algunas fonts no oficiales parecen indicar que MS11-100 pone un límite de 500 en artículos de devolución de datos. No puedo encontrar una fuente de Microsoft que lo confirme. Sé que View State y otras características del framework consumen algo 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 discutiendo 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 pueden enviarse 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 según lo descrito por los investigadores de seguridad en Alemania.

EDITAR: código fuente con un 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 principal del índice:

@using (Html.BeginForm()) { 

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

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 (Byte [] bytes, Codificación de encoding) +111
System.Web.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:

    

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 al usar Reflector, verifiqué la clase HttpValueCollection y no tenía el método ThrowIfMaxHttpCollectionKeysExceeded :

enter image description here

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

enter image description here

Entonces ese método es definitivamente nuevo. Utilicé la opción Desmontar en Reflector, y por lo que puedo decir del código, comprueba un AppSetting:

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

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

  _maxHttpCollectionKeys = 0x3e8; 

Además, Alexey Gusarov tuiteó sobre este entorno hace dos días:

Y aquí hay una respuesta oficial de una sesión de preguntas y respuestas con Jonathan Ness (Gerente de Desarrollo de Seguridad, MSRC) y Pete Voss (Gerente de Comunicaciones de Respuesta Sr., Informática Confiable):

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

A: 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 (punta de sombrero para michielvoo, ya que solo descubrí esto a través de Reflector de la misma manera que él encontró la respuesta). El siguiente ejemplo establece MaxHttpCollectionKeys en 5000 en ediciones de 32 bits de Windows:

 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 Wow6432Node:

 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\1.1.4322.0] "MaxHttpCollectionKeys"=dword:00001388 

Solo quiero agregar mi $ 0.02 aquí para gente que ve la rareza.

Si su aplicación almacena información de la página en ASP.NET ViewState y excede el umbral del servidor web, se encontrará con este problema. En lugar de aplicar el problema del arreglo web.config de inmediato, es posible que primero desee optimizar su código.

Ver origen y buscar más de 1000 campos ocultos de viewstate, y usted tiene su problema.

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

Parece que cuando se llama a HttpCookieCollection.Get() llama internamente a HttpCookieCollection.AddCookie() , que a continuación llama a 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 en un período de un par de horas, el sitio web se vuelve progresivamente más lento y complicado, hasta que comienza a lanzar InvalidOperationExcpetion . Luego reciclamos el grupo de aplicaciones, lo que soluciona el problema por unas horas más.