ASP.NET MS11-100: comment modifier la limite du nombre maximal de valeurs de formulaire publiées?

Microsoft (29-22-2011) a récemment publié une mise à jour pour corriger plusieurs graves failles de sécurité dans le .NET Framework. L'un des correctifs introduits par MS11-100 atténue temporairement une attaque DoS potentielle impliquant des collisions de tables de hachage. Il semble que ce correctif brise les pages qui contiennent beaucoup de données POST. Dans notre cas, sur les pages qui ont de très grandes listes de cases à cocher. Pourquoi en serait-il ainsi?

Certaines sources non officielles semblent indiquer que MS11-100 place une limite de 500 sur les articles publiés. Je ne trouve pas de source Microsoft qui confirme cela. Je sais que l'état d'affichage et d'autres fonctionnalités du cadre absorbent une partie de cette limite. Y a-t-il un paramètre de configuration qui contrôle cette nouvelle limite? Nous pourrions abandonner l'utilisation des cases à cocher, mais cela fonctionne plutôt bien pour notre situation particulière. Nous aimerions également appliquer le patch car il protège contre d'autres choses désagréables.

Source non officielle discutant de la limite de 500:

Le bulletin corrige le vecteur d'attaque DOS en fournissant une limite au nombre de variables pouvant être soumises pour une seule requête HTTP POST. La limite par défaut est de 500, ce qui devrait être suffisant pour les applications Web normales, mais suffisamment bas pour neutraliser l'attaque, comme l'ont décrit les chercheurs en sécurité en Allemagne.

EDIT: code source avec exemple de limite (qui semble être 1 000 et non 500) Créez une application MVC standard et ajoutez le code suivant à la vue d'index principale:

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

Ce code fonctionnait avant le patch. Ça ne marche pas après. L'erreur est:

[InvalidOperationException: l'opération n'est pas valide en raison de l'état actuel de l'objet.]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded () +82 System.Web.HttpValueCollection.FillFromEncodedBytes (Byte [] byteWeb, Encod System [11 octets), Encod System [11 octets], Encod System [11 octets]
. HttpRequest.FillInFormCollection () +307

Essayez d'ajouter ce paramètre dans web.config. Je viens de tester cela sur .NET 4.0 avec un projet ASP.NET MVC 2 et avec ce paramètre, votre code ne renvoie pas:

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

Cela devrait fonctionner maintenant (après avoir appliqué la mise à jour de sécurité) pour modifier la limite.

Je n'avais pas encore mis à jour ma machine, donc en utilisant Reflector j'ai vérifié la classe HttpValueCollection, et elle n'avait pas la ThrowIfMaxHttpCollectionKeysExceededméthode:

J'ai installé KB2656351 (mise à jour pour .NET 4.0), rechargé les assemblys dans Reflector et la méthode est apparue:

Cette méthode est donc définitivement nouvelle. J'ai utilisé l' option Désassembler dans Reflector, et d'après ce que je peux dire du code, il vérifie un AppSetting:

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

S'il ne trouve pas la valeur dans le fichier web.config, il la mettra à 1000 dans System.Web.Util.AppSettings.EnsureSettingsLoaded(une classe statique interne):

 _maxHttpCollectionKeys = 0x3e8;

De plus, Alexey Gusarov a tweeté à propos de ce paramètre il y a deux jours:

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

Et voici une réponse officielle d'un Q&A avec Jonathan Ness (Security Development Manager, MSRC) et Pete Voss (Sr. Response Communications Manager, Trustworthy Computing):

Q: AppSettings.MaxHttpCollectionKeys est-il le nouveau paramètre qui contient le nombre maximal d'entrées de formulaire?

R: Oui, c'est ça.

Pour ceux d'entre vous qui utilisent encore .NET 1.1, ce paramètre n'est pas configuré via web.config - c'est un paramètre de registre (chapeau à michielvoo, car je n'ai découvert cela via Reflector que de la même manière qu'il a trouvé la réponse). L'exemple ci-dessous est défini MaxHttpCollectionKeyssur 5000 sur les éditions 32 bits de Windows:

Windows Registry Editor Version 5.00

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

Pour une édition Windows 64 bits, définissez la clé sous le Wow6432Node:

Windows Registry Editor Version 5.00

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

Je veux juste ajouter mes 0,02 $ ici pour les gens qui voient la bizarrerie.

Si votre application cache des informations de page dans ASP.NET ViewState et dépasse le seuil du serveur Web, vous allez rencontrer ce problème. Plutôt que d'appliquer immédiatement le problème de correction de web.config, vous voudrez peut-être commencer par optimiser votre code.

Affichez la source et recherchez plus de 1000 champs cachés dans l'état d'affichage, et vous avez votre problème.

ThrowIfMaxHttpCollectionKeysExceeded()a également été ajouté au System.Web.HttpCookieCollection.

Il ressemble à quand HttpCookieCollection.Get()est appelé, il appelle en interne HttpCookieCollection.AddCookie(), qui appelle ensuite 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);
    }
}

Ce que nous voyons, c'est que sur une période de quelques heures, le site Web devient progressivement plus lent et plus bogué, jusqu'à ce qu'il commence à lancer le InvalidOperationExcpetion. Nous recyclons ensuite le pool d'applications, qui corrige le problème pendant quelques heures de plus.