Résolution des erreurs mac (View State Message Authentication Code)

Qu’est-ce que l’état d’affichage ?

L’état d’affichage est une information qui est aller-retour entre les pages WebForms (.aspx) dans une application ASP.NET. Le balisage HTML du champ __VIEWSTATE ressemble à ce qui suit :

<input type="hidden » name="__VIEWSTATE » id="__VIEWSTATE » value= »... » />
Un exemple d’élément qui peut être stocké dans le champ __VIEWSTATE est le texte d’un contrôle Button. Si un utilisateur clique sur le bouton, le gestionnaire d’événements Button_Click peut extraire le texte du bouton du champ d’état d’affichage. Consultez la rubrique Vue d’ensemble de l’état ASP.NET sur le site web MSDN (Microsoft Developer Network) pour obtenir une vue d’ensemble beaucoup plus détaillée de l’état d’affichage ASP.NET.

Étant donné que le champ __VIEWSTATE contient des informations importantes utilisées pour reconstruire la page en postback, assurez-vous qu’un attaquant ne peut pas falsifier ce champ. Si un attaquant a envoyé une charge utile de __VIEWSTATE malveillante, l’attaquant pourrait potentiellement tromper l’application en effectuant une action qu’elle n’aurait pas effectuée autrement.

Pour empêcher ce type d’attaque de falsification, le champ __VIEWSTATE est protégé par un code d’authentification de message (MAC). ASP.NET valide le MAC envoyé avec la charge utile __VIEWSTATE lorsqu’une publication se produit. La clé utilisée pour calculer le MAC est spécifiée dans l’élément de l’application dans le fichier Web.config. Étant donné que l’attaquant ne peut pas deviner le contenu de l’élément <machineKey> , il ne peut pas fournir un MAC valide si l’attaquant tente de falsifier la charge utile __VIEWSTATE. ASP.NET détecte qu’aucun MAC valide n’a été fourni et ASP.NET rejette la demande malveillante.

Quelles sont les causes des erreurs de validation MAC ?

Une erreur de validation MAC ressemble à l’exemple suivant :

Cause 1 : L’application web s’exécute dans une batterie de serveurs (environnement multiserveur)

ASP.NET génère automatiquement une clé de chiffrement pour chaque application et stocke la clé dans la ruche du Registre HKCU. Cette clé générée automatiquement est utilisée s’il n’existe aucun élément machineKey> explicite <dans la configuration de l’application. Toutefois, étant donné que cette clé générée automatiquement est locale sur l’ordinateur qui a créé la clé, ce scénario provoque un problème pour les applications qui s’exécutent dans une batterie de serveurs. Chaque serveur de la batterie génère sa propre clé locale, et aucun des serveurs de la batterie de serveurs ne s’accorde sur la clé à utiliser. Le résultat est que, si un serveur génère une charge utile __VIEWSTATE qu’un autre serveur consomme, le consommateur rencontre un échec de validation MAC.

• Résolution 1a : Créer un élément machineKey> explicite <

  En ajoutant un élément machineKey> explicite <au fichier Web.config de l’application, le développeur indique ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Consultez l’annexe A pour obtenir des instructions sur la façon de générer un <élément machineKey> . Une fois cet élément ajouté au fichier Web.config, redéployez l’application sur chaque serveur de la batterie de serveurs.

  Remarque Certains services d’hébergement web, tels que microsoft Azure sites web, prennent des mesures pour synchroniser la clé générée automatiquement de chaque application sur leurs serveurs principaux. Cela permet aux applications qui n’ont pas spécifié d’élément machineKey> explicite <de continuer à fonctionner dans ces environnements, même si l’application s’exécute dans une batterie de serveurs. Si votre application s’exécute sur un service d’hébergement tiers, contactez votre fournisseur d’hébergement pour déterminer si cette situation s’applique à vous.

• Résolution 1b : Activer l’affinité dans l’équilibreur de charge

  Si vos sites fonctionnent derrière un équilibreur de charge, vous pouvez activer l’affinité serveur pour contourner temporairement le problème. Cela permet de s’assurer qu’un client donné interagit uniquement avec un serveur physique derrière l’équilibreur de charge afin que toutes les charges utiles de chiffrement soient générées et consommées par le même serveur.

  Cela ne doit pas être considéré comme une solution à long terme au problème. Même lorsque l’affinité serveur est activée, la plupart des équilibreurs de charge redirigent le client vers un autre serveur physique si le serveur d’origine avec lequel les équilibreurs de charge ont été affinités est hors connexion. Ainsi, le nouveau serveur rejette les charges utiles de chiffrement (telles que les __VIEWSTATE, les tickets d’authentification par formulaire, les jetons anti-falsification MVCs et d’autres services) dont dispose actuellement le client.

  L’utilisation d’un élément machineKey> explicite <et le redéploiement de l’application doivent être préférables à l’activation de l’affinité serveur.

Cause 2 : Le processus de travail utilise l’identité du pool d’applications IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) a introduit l’identité du pool d’applications, un nouveau mécanisme d’isolation qui permet d’améliorer la sécurité des serveurs qui exécutent ASP.NET applications. Toutefois, les sites qui s’exécutent sous l’identité du pool d’applications n’ont pas accès au registre HKCU. C’est là que le runtime ASP.NET stocke ses clés machineKey> générées automatiquement<. Le résultat est que ASP.NET ne peut pas conserver la clé générée automatiquement lorsque le pool d’applications est réinitialisé. Par conséquent, chaque fois que w3wp.exe est réinitialisé, une nouvelle clé temporaire est générée.

Remarque Ce n’est pas un problème dans IIS 7.5 (Windows 7, Windows Server 2008 R2) et versions ultérieures. Sur ces versions d’IIS, ASP.NET pouvez conserver ses clés générées automatiquement dans un autre emplacement qui survivra aux réinitialisations du pool d’applications.

• Résolution 2a : Utiliser l’utilitaire aspnet_regiis

  ASP.NET installations contiennent un utilitaire ,aspnet_regiis.exe. Cet utilitaire permet ASP.NET interface avec IIS pour effectuer les configurations requises pour exécuter une application managée. L’une de ces configurations crée les clés nécessaires dans la ruche du Registre pour permettre la persistance des clés d’ordinateur générées automatiquement.

  Tout d’abord, vous devez déterminer le pool d’applications que votre site utilise. Cela peut être déterminé à l’aide de l’utilitaire inetmgr inclus avec IIS. Sélectionnez votre site dans l’arborescence à gauche, cliquez avec le bouton droit sur Gérer website, puis cliquez sur Paramètres avancés. La boîte de dialogue qui s’affiche affiche le nom du pool d’applications.

  

  Pour créer la structure des clés de Registre appropriées pour un pool d’applications ASP.NET 4.0, procédez comme suit :

  1. Ouvrez une invite de commandes d’administration.

  2. Recherchez le répertoire approprié, selon que votre pool d’applications est 32 bits ou 64 bits :

     • Pool d’applications 32 bits : cd /d %windir %\Microsoft.NET\Framework\v4.0.30319
     • Pool d’applications 64 bits : cd /d %windir %\Microsoft.NET\Framework64\v4.0.30319

  3. Accédez au répertoire, tapez la commande suivante, puis appuyez sur Entrée :

     aspnet_regiis -ga « IIS APPPOOL\app-pool-name »

  Si le pool d’applications est un pool d’applications ASP.NET 2.0 ou 3.5, procédez comme suit :

  1. Ouvrez une invite de commandes d’administration.

  2. Recherchez le répertoire approprié, selon que votre pool d’applications est 32 bits ou 64 bits :

     • Pool d’applications 32 bits : cd /d %windir %\Microsoft.NET\Framework\v2.0.50727
     • Pool d’applications 64 bits : cd /d %windir %\Microsoft.NET\Framework64\v2.0.50727

  3. Accédez au répertoire, tapez la commande suivante, puis appuyez sur Entrée :

     aspnet_regiis -ga « IIS APPPOOL\app-pool-name »

  Par exemple, si votre pool d’applications est nommé Mon pool d’applications (comme dans l’image précédente), exécutez la commande suivante :
   
  aspnet_regiis -ga « IIS APPPOOL\Mon pool d’applications »

  Remarque Les services système APPHOSTSVC et WAS doivent peut-être être en cours d’exécution pour que l’utilitaire aspnet_regiis résolve correctement les noms APPPOOL\* IIS.

• Résolution 2b : Créer un élément machineKey> explicite <

  En ajoutant un élément machineKey> explicite <au fichier Web.config de l’application, le développeur indique ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Consultez l’annexe A pour obtenir des instructions sur la façon de générer un <élément machineKey> .

Cause 3 : Le pool d’applications est configuré à l’aide de LoadUserProfile=false

Si le pool d’applications s’exécute avec une identité personnalisée, IIS n’a peut-être pas chargé le profil utilisateur pour l’identité. Cela a pour effet secondaire de rendre le registre HKCU indisponible pour ASP.NET de conserver la machineKey> générée automatiquement<. Par conséquent, une nouvelle clé générée automatiquement est créée chaque fois que l’application redémarre. Pour plus d’informations , consultez la section Profil utilisateur sur le site web microsoft.

• Résolution 3a : Utiliser l’utilitaire aspnet_regiis

  Les instructions pour cela sont les mêmes que la résolution 2a. Pour plus d’informations, consultez cette section.

• Résolution 3b : Utiliser une machineKey explicite <>

  En ajoutant un élément machineKey> explicite <au fichier Web.config de l’application, le développeur indique ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Consultez l’annexe A pour obtenir des instructions sur la façon de générer un <élément machineKey> .

• Résolution 3c : Provisionner manuellement les clés de Registre HKCU requises

  Si vous ne pouvez pas exécuter l’utilitaire aspnet_regiis, vous pouvez utiliser un script Windows PowerShell pour provisionner les clés de Registre appropriées dans HKCU. Pour plus d’informations, consultez l’annexe B .

• Résolution 3d : Définir LoadUserProfile=true pour ce pool d’applications

  Vous pouvez également activer le chargement du profil utilisateur dans ce pool d’applications. Cela rend la ruche du registre HKCU, le dossier temporaire et d’autres emplacements de stockage spécifiques à l’utilisateur disponibles pour l’application. Toutefois, cela peut entraîner une augmentation de l’utilisation du disque ou de la mémoire pour le processus de travail. Consultez l’élément pour plus d’informations sur l’activation de ce paramètre.

Cause 4 : La propriété Page.ViewStateUserKey a une valeur incorrecte

Les développeurs de logiciels peuvent décider d’utiliser la propriété Page.ViewStateUserKey pour ajouter la protection contre la falsification de requêtes intersites au champ __VIEWSTATE. Si vous utilisez la propriété Page.ViewStateUserKey, elle est généralement définie sur une valeur telle que le nom d’utilisateur de l’utilisateur actuel ou l’identificateur de session de l’utilisateur. Les modèles de projet pour les applications WebForms dans Microsoft Visual Studio 2012 et versions ultérieures contiennent des exemples qui utilisent cette propriété. Pour plus d’informations, consultez la rubrique Propriété Page.ViewStateUserKey sur le site web MSDN (Microsoft Developer Network).

Si la propriété ViewStateUserKey est spécifiée, sa valeur est gravée dans __VIEWSTATE au moment de la génération. Lorsque le champ __VIEWSTATE est consommé, le serveur vérifie la propriété ViewStateUserKey de la page active et la valide par rapport à la valeur utilisée pour générer le champ __VIEWSTATE. Si les valeurs ne correspondent pas, la demande est rejetée comme potentiellement malveillante.

Un client qui a deux onglets ouverts dans le navigateur est un exemple d’échec lié à ViewStateUserKey. Le client est connecté en tant qu’utilisateur A et, dans le premier onglet, une page est affichée avec un __VIEWSTATE dont la propriété ViewStateUserKey contient « User A ». Dans le deuxième onglet, le client se déconnecte, puis se reconnecte en tant qu’utilisateur B. Le client retourne au premier onglet et envoie le formulaire. La propriété ViewStateUserKey peut contenir « Utilisateur B » (car c’est ce que dit le cookie d’authentification du client). Toutefois, le champ __VIEWSTATE que le client a envoyé contient « Utilisateur A ». Cette incompatibilité provoque l’échec.

• Résolution 4a : Vérifier que ViewStateUserKey est correctement défini

  Si votre application utilise la propriété ViewStateUserKey, vérifiez que la valeur de la propriété est la même lorsque l’état d’affichage est généré et quand il est consommé. Si vous utilisez le nom d’utilisateur de l’utilisateur connecté actuel, assurez-vous que l’utilisateur est toujours connecté et que l’identité de l’utilisateur n’a pas changé au moment de la publication. Si vous utilisez l’identificateur de session de l’utilisateur actuel, assurez-vous que la session n’a pas expiré.

  Si vous exécutez dans un environnement de batterie de serveurs, assurez-vous que les <éléments machineKey> correspondent. Consultez l’Annexe A pour obtenir des instructions sur la façon de générer ces éléments.

          

Annexe A : Comment générer un <élément machineKey>

        
Pour générer vous-même un <élément machineKey>, vous pouvez utiliser le script Windows PowerShell suivant :

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

Pour les applications ASP.NET 4.0, vous pouvez simplement appeler Generate-MachineKey sans paramètres pour générer un <élément machineKey> comme suit :

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

les applications ASP.NET 2.0 et 3.5 ne prennent pas en charge les HMACSHA256. Au lieu de cela, vous pouvez spécifier SHA1 pour générer un élément machineKey> compatible <comme suit :

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

Dès que vous avez un <élément machineKey> , vous pouvez le placer dans le fichier Web.config. L’élément <machineKey> n’est valide que dans le fichier Web.config à la racine de votre application et n’est pas valide au niveau du sous-dossier.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

Pour obtenir la liste complète des algorithmes pris en charge, exécutez l’aide Generate-MachineKey à partir de l’invite de Windows PowerShell.

Annexe B : Provisionnement du Registre pour conserver les clés générées automatiquement

Par défaut, car ASP. Les clés NET générées automatiquement sont conservées dans le registre HKCU. Ces clés peuvent être perdues si le profil utilisateur n’a pas été chargé dans le processus worker IIS, puis le pool d’applications est recyclé. Ce scénario peut affecter les fournisseurs d’hébergement partagé qui exécutent des pools d’applications en tant que comptes d’utilisateur Windows standard.

Pour contourner cette situation, ASP.NET permet de conserver les clés générées automatiquement dans le registre HKLM au lieu du registre HKCU. Cette opération est généralement effectuée à l’aide de l’utilitaire aspnet_regiis (consultez les instructions de la section « Résolution 2a : Utiliser l’utilitaire aspnet_regiis »). Toutefois, pour les administrateurs qui ne souhaitent pas exécuter cet utilitaire, le script Windows PowerShell suivant peut être utilisé à la place :

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # We require administrative permissions to continue.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Open HKLM with an appropriate view into the registry
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Open ASP.NET base key
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

L’exemple suivant montre comment approvisionner les entrées de Registre HKLM appropriées pour un pool d’applications qui s’exécute en tant qu’utilisateur example@contoso.com (il s’agit de l’UPN du compte d’utilisateur Windows). Ce pool d’applications est un pool d’applications 32 bits qui exécute le CLR v2.0 (ASP.NET 2.0 ou 3.5).

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

Si le pool d’applications est plutôt un pool d’applications 64 bits qui exécute CLR v4.0 (ASP.NET 4.0 ou 4.5), la commande est la suivante :

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

Même si les clés générées automatiquement sont stockées dans HKLM, la sous-clé de Registre qui contient le matériel de chiffrement secret de chaque compte d’utilisateur est ajoutée à une liste de contrôle d’accès (ACL) afin que le matériel de chiffrement ne puisse pas être lu par d’autres comptes d’utilisateur.

Annexe C : Chiffrement de l’élément <machineKey> dans les fichiers de configuration

Les administrateurs de serveur peuvent ne pas souhaiter que les informations hautement sensibles telles que le <matériel de clé machineKey> soient en texte clair dans les fichiers de configuration. Si c’est le cas, les administrateurs peuvent décider de tirer parti d’une fonctionnalité du .NET Framework appelée « configuration protégée ». Cette fonctionnalité vous permet de chiffrer certaines sections des fichiers .config. Si le contenu de ces fichiers de configuration est divulgué, le contenu de ces sections reste secret.

Vous trouverez une brève vue d’ensemble de la configuration protégée sur le site web MSDN. Il contient également un tutoriel sur la façon de protéger les <éléments connectionStrings> et <machineKey> du fichier Web.config.