CryptographicException: le rembourrage n'est pas valide, il ne peut pas être supprimé et la validation du MAC Viewstate a échoué

Question

Surveillant mes journaux d’exception globaux, cette erreur semble impossible à éliminer quoi que je fasse, je pensais l’avoir finalement éliminée, mais c’est de retour. Vous pouvez voir une trace de l'erreur sur poste similaire ici .

Remarques sur l'environnement:

IIS 6.0, .NET 3.5 SP1 serveur unique application ASP.NET

Mesures déjà prises:

  <system.web>
    <machineKey validationKey="big encryption key"
      decryptionKey="big decryption key"
      validation="SHA1" decryption="AES" />

Dans ma base de pages pour toutes mes pages

  protected override void OnInit(EventArgs e)
  {
    const string viewStateKey = "big key value";

    Page.ViewStateUserKey = viewStateKey;
  }

La source de la page indique également que tous les champs masqués générés par ASP.NET se trouvent correctement en haut de la page.

Answer 1

Tout d'abord, commençons par le fait que cet état d'erreur de vue se produit sur PostBack .

Je dois également dire que j'ai fait tout ce que tout le monde suggère de faire pour éviter ce problème. Et je n'ai qu'un seul ordinateur, mais 2 pools qui exécutent les mêmes pages.

Pour que quelqu'un fasse une action , un homme, une autre machine de recherche en "cliquant" sur vos pages ou un pirate informatique essaye de vérifier si votre système a des problèmes ...

J'ai des problèmes similaires (rares mais existants) et j'ai finalement découvert que les gens essayaient de tester mes pages. (de la même adresse IP que j'ai et dos attaques)

Je modifie la fonction LoadPageStateFromPersistenceMedium () qui traduit l'état d'affichage, et je vois en enregistrant ce qui était exactement l'entrée et les adresses IP ... puis j'ai démarré la surveillance. ces résultats et constatez que l'état d'affichage a été modifié manuellement ou est totalement vide.

En cas d'erreur, je le redirige vers la même page ...

Voici ce que j'ai fait ...

public abstract class BasePage : System.Web.UI.Page
{
    protected override object LoadPageStateFromPersistenceMedium()
    {
        try
        {
            .. return the base, or make here your decompress, or what ever...
            return base.LoadPageStateFromPersistenceMedium();            
        }
        catch (Exception x)
        {
            string vsString = Request.Form[__VIEWSTATE];
            string cThePage = Request.RawUrl;

            ...log the x.ToString() error...
            ...log the vsString...
            ...log the ip coming from...
            ...log the cThePage...

        // check by your self for local errors
            Debug.Fail("Fail to load view state ! Reason:" + x.ToString());
        }

        // if reach here, then have fail, so I reload the page - maybe here you
        // can place somthing like ?rnd=RandomNumber&ErrorId=1 and show a message
        Responce.Redirect(Request.RawUrl, true);        

        // the return is not used after the redirect
        return string.Empty;
    }    
}

Deuxième raison

Maintenant, cela peut se produire pour une autre raison, notamment parce que quelqu'un clique sur votre page avant le chargement de __EVENTVALIDATION.

Cet événementValidation est placé sur le dernier bouton, même celui sur lequel asp.net a été trouvé. Si vous en avez certains à de nombreux endroits sur la page, ou à proximité du bouton, vous accédez à la fin de la page.

Donc, même si vous voyez l'état d'affichage en haut de la page, où se trouve la validation ??? peut-être que cela n’a jamais été chargé - page corrompue?, utilisateur trop rapide, clic sur la page?

<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" ... >

Pour éviter ce genre de problème, j’ai fait un simple javascript que je ne le laisse pas appuyer sur le bouton si cette entrée n’a pas été chargée !!!.

Encore un commentaire, la __EVENTVALIDATION n’est pas toujours présente! Il est donc peut-être plus prudent de ne pas rechercher ce champ si vous apportez une solution générale, mais de faire une astuce en javascript pour vérifier si la page entière est chargée ou autre chose que vous pensez.

Voici ma solution finale avec jQuery: (notez que je vérifie le chargement de page si la validation d'événement existe!). Je l'ai placé sur mes MasterPages.

<script language="javascript" type="text/javascript">
    function AllowFormToRun()
    {
        var MyEventValidation = $("#__EVENTVALIDATION");

        if(MyEventValidation.length == 0 || MyEventValidation.val() == ""){
            alert("Please wait for the page to fully loaded.");
            return false;
        }

        return true; 
    }       
</script>

protected void Page_Load(object sender, EventArgs e)
{
    // I do not know if Page can be null - just in case I place it.
    if (Page != null && Page.EnableEventValidation)
    {
        Form.Attributes["onsubmit"] = "return AllowFormToRun();";
    }
}

Vous pouvez tester en plaçant un délai près du bouton de votre page.

<% System.Threading.Thread.Sleep(5000); %>

Mettre à jour

Aujourd'hui, je vois de nouveau dans le journal ce message pour WebResource. Ce que je découvre, c'est qu'un bot récupère les pages et crée tous les caractères sur les liens en minuscules , y compris les paramètres. Une raison de plus de ne pas obtenir la chaîne encodée correcte et d'envoyer un message du type Le remplissage est invalide et ne peut pas être supprimé.

J'espère que cela vous aidera davantage.

Answer 2

Un sondage des pages Web contenant plusieurs des mots clés du message d'erreur indique que ce type d'erreur est relativement courant, généralement aléatoire (du moins en apparence) et, malheureusement, rarement inclus dans un contournement explicite ou explication ...

L’existence de nombreuses situations similaires, mais différentes, est probablement liée aux très nombreuses architectures et configurations sous-jacentes qui peuvent en quelque sorte empêcher la couche cryptographique d’affirmer l’authenticité du MAC (Codes d’authentification de message) dans le système. pages de demande:

• Configuration de la batterie de serveurs
  
• Pages de domaines croisés / syndiquées
• bibliothèques de widgets tiers et autres
• Logique réelle du programme ASP (bien sûr)

Un "marqueur" relativement fréquent autour de ces rapports de bogues, il est fait mention de demandes de ressources (par exemple, WebResource.axd ).
Notez que ces demandes sont souvent non enregistrées (sinon elles gonfleront la taille des fichiers journaux avec un événement présentant un intérêt relativement faible). Cette absence du fichier journal et le fait qu’ils soient souvent mis en cache (et donc l’occurrence relativement aléatoire et peu fréquente du bogue) peuvent expliquer comment cette origine possible du bogue va "sous le radar". Cela suggère également qu'en essayant de recréer le bogue (lors du suivi dans les journaux, en temps réel, etc.), il peut être utile d'empêcher le navigateur Web de se mettre en cache (ou au moins de l'effacer initialement).

En bref, voici quelques idées et éléments à rechercher:

• commencer à consigner les demandes * .axd
• essayez de mettre en corrélation ces demandes axd avec les événements d'erreur du journal des exceptions
• rechercher des pages avec des références de ressources
• si vous vous trouvez dans un contexte de batterie, assurez-vous que toutes les instances utilisent la même clé (apparemment, l'extrait de code fourni dans l'indicateur de question sur plusieurs serveurs IIS)
• Méfiez-vous des pages avec des liens tiers (services de recherche, programmes d'affiliation, etc.)

J'espère que cela aide ;-)

Answer 3

Êtes-vous sûr que votre problème est lié à la cryptographie et qu'il n'est pas causé par un ViewState surdimensionné? Si ViewState est le problème, vous pouvez le diviser - modifiez la valeur de pages / MaxPageStateFieldLength dans web.config