Résolution des erreurs de code d’authentification des messages d’affichage (MAC)

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

L’état d’affichage est une information qui fait l’objet d’allers-retours entre les pages WebForms (.aspx) d’une application ASP.NET. Le balisage HTML du champ __VIEWSTATE se présente comme 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 d’affichage 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 lors de la publication, assurez-vous qu’un attaquant ne peut pas falsifier ce champ. Si un attaquant a soumis une charge utile de __VIEWSTATE malveillante, il pourrait potentiellement inciter l’application à effectuer une action qu’elle n’aurait pas effectuée autrement.

Pour éviter ce type d’attaque par falsification, le champ __VIEWSTATE est protégé par un code d’authentification des messages (MAC). ASP.NET valide le MAC envoyé avec la charge utile __VIEWSTATE lors d’une publication. 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 s’il tente de falsifier la charge utile __VIEWSTATE. ASP.NET détecte qu’aucun MAC valide n’est fourni et ASP.NET rejette la demande malveillante.

Qu’est-ce qui provoque les 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 à plusieurs serveurs)

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’y a pas d’é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 pose un problème pour les applications exécutées dans une batterie de serveurs. Chaque serveur de la batterie génère sa propre clé locale, et aucun des serveurs de la batterie ne s’accorde sur la clé à utiliser. Par conséquent, 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 de Web.config de l’application, le développeur ASP.NET demande de ne pas utiliser la clé cryptographique générée automatiquement. Voir 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 les sites web Microsoft Azure, 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 à travailler 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é n’interagit qu’avec un seul serveur physique derrière l’équilibreur de charge afin que toutes les charges utiles cryptographiques soient à la fois 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 auquel les équilibreurs de charge ont été affinités passe hors ligne. Le nouveau serveur rejette alors les charges utiles de chiffrement (telles que les __VIEWSTATE, les formulaires, les tickets d’authentification, les MVC, les jetons anti-falsification et autres services) dont dispose actuellement le client.

  L’utilisation d’un élément machineKey> explicite <et le redéploiement de l’application doivent être privilégiés plutôt que l’activation de l’affinité serveur.

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

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) a introduit l’identité de pool d’applications, un nouveau mécanisme d’isolation qui permet d’accroître la sécurité des serveurs qui exécutent ASP.NET applications. Toutefois, les sites qui s’exécutent sous l’identité de 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. Par conséquent, ASP.NET ne pouvez pas conserver la clé générée automatiquement lors de la réinitialisation du pool d’applications. Par conséquent, chaque fois qu'w3wp.exe est réinitialisée, une nouvelle clé temporaire est générée.

Remarque Il ne s’agit pas d’un problème dans IIS 7.5 (Windows 7, Windows Server 2008 R2) et versions ultérieures. Sur ces versions d’IIS, ASP.NET peut conserver ses clés générées automatiquement dans un autre emplacement qui survit 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 ASP.NET permet de s’interfacer avec IIS pour effectuer les configurations requises pour exécuter une application géré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 de machine générées automatiquement.

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

  

  Pour générer un modèle automatique 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. Localisez 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. Localisez 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\My App Pool »

  Remarque Il se peut que les services système APPHOSTSVC et WAS doivent être exécutés pour que l’utilitaire aspnet_regiis résolution appropriée des noms IIS APPPOOL\*.

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

  En ajoutant un élément machineKey> explicite <au fichier de Web.config de l’application, le développeur ASP.NET demande de ne pas utiliser la clé cryptographique générée automatiquement. Voir 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 peut ne pas avoir chargé le profil utilisateur pour l’identité. Ceci a pour effet secondaire de rendre le registre HKCU indisponible pour ASP.NET 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 de Microsoft.

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

  Les instructions à ce sujet sont les mêmes que celles de la résolution 2a. Consultez cette section pour plus d’informations.

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

  En ajoutant un élément machineKey> explicite <au fichier de Web.config de l’application, le développeur ASP.NET demande de ne pas utiliser la clé cryptographique générée automatiquement. Voir 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 configurer les clés de Registre appropriées dans HKCU. Voir l’annexe B pour plus d’informations.

• 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. Ainsi, la ruche du Registre HKCU, le dossier temporaire et d’autres emplacements de stockage spécifiques à l’utilisateur sont à la disposition de l’application. Toutefois, cela peut entraîner une augmentation de l’utilisation du disque ou de la mémoire pour le processus de travail. Pour plus d’informations sur l’activation de ce paramètre, consultez l’élément .

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 au champ __VIEWSTATE une protection contre la falsification des requêtes intersites. 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, reportez-vous à la rubrique 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 actuelle 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 car potentiellement malveillante.

Un exemple d’échec lié à ViewStateUserKey serait un client ayant deux onglets ouverts dans le navigateur. 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 « Utilisateur A ». Dans le deuxième onglet, le client se déconnecte, puis se reconnecte en tant qu’utilisateur B. Le client revient 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 soumis par le client 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 lorsqu’il est consommé. Si vous utilisez le nom d’utilisateur de l’utilisateur actuellement connecté, assurez-vous que l’utilisateur est toujours connecté et que son identité 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="..." />

ASP.NET applications 2.0 et 3.5 ne prennent pas en charge 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 disposez d’un <élément machineKey> , vous pouvez le mettre 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 le Generate-MachineKey d’aide à partir de l’invite de Windows PowerShell.

Annexe B : Approvisionnement du registre pour conserver les clés générées automatiquement

Par défaut, car ASP. Les clés générées automatiquement par les réseaux NET 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 de travail IIS, puis si 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’utilisateurs Windows standard.

Pour contourner cette situation, ASP.NET active la persistance des 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 (voir 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 provisionner 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 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 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 cryptographique secret de chaque compte d’utilisateur est ajoutée à une liste de contrôle d’accès (ACL) afin que le matériel cryptographique ne puisse pas être lu par d’autres comptes d’utilisateurs.

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

Les administrateurs du serveur ne veulent peut-être pas que des informations très sensibles telles que le matériel de clé <machineKey> soient affichées sous forme de texte brut dans les fichiers de configuration. Si tel est le cas, les administrateurs peuvent décider de tirer parti d’une fonctionnalité de .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 restera secret.

Vous trouverez un bref aperçu de la configuration protégée sur le site web MSDN. Il contient également un didacticiel sur la façon de protéger les <éléments connectionStrings> et <machineKey> du fichier Web.config.