Resolución de errores de código de autenticación de mensajes (MAC) de estado de vista

¿Qué es el estado de vista?

El estado de vista es información que se realiza de ida y vuelta entre páginas de WebForms (.aspx) en una aplicación ASP.NET. El marcado HTML para el campo __VIEWSTATE es similar al siguiente:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
Un ejemplo de un elemento que podría almacenarse en el campo __VIEWSTATE es el texto de un control Button. Si un usuario hace clic en el botón, el controlador de eventos Button_Click podrá extraer el texto del botón del campo de estado de vista. Consulte el tema ASP.NET Introducción al estado de vista en el sitio web de Microsoft Developer Network (MSDN) para obtener información mucho más detallada sobre el estado de vista ASP.NET.

Dado que el campo __VIEWSTATE contiene información importante que se usa para reconstruir la página en la devolución, asegúrese de que un atacante no pueda alterar este campo. Si un atacante envía una carga __VIEWSTATE malintencionada, el atacante podría engañar a la aplicación para que realice una acción que de otro modo no habría realizado.

Para evitar este tipo de ataque de manipulación, el campo __VIEWSTATE está protegido por un código de autenticación de mensajes (MAC). ASP.NET valida la MAC que se envía junto con la carga __VIEWSTATE cuando se produce una devolución de entrada. La clave que se usa para calcular el MAC se especifica en el elemento de la aplicación en el archivo Web.config. Dado que el atacante no puede adivinar el contenido del <elemento machineKey> , no puede proporcionar una MAC válida si intenta manipular la carga __VIEWSTATE. ASP.NET detectará que no se ha proporcionado una MAC válida y ASP.NET rechazará la solicitud malintencionada.

¿Qué causa los errores de validación de MAC?

Un error de validación de MAC será similar al siguiente ejemplo:

Causa 1: la aplicación web se ejecuta en una granja de servidores (entorno de varios servidores)

ASP.NET genera automáticamente una clave criptográfica para cada aplicación y almacena la clave en el subárbol del registro HKCU. Esta clave generada automáticamente se usa si no hay ningún elemento machineKey> explícito <en la configuración de la aplicación. Sin embargo, dado que esta clave generada automáticamente es local en el equipo que creó la clave, este escenario causa un problema para las aplicaciones que se ejecutan en una granja de servidores. Cada servidor de la granja generará su propia clave local y ninguno de los servidores de la granja se pondrá de acuerdo sobre qué clave usar. El resultado es que, si un servidor genera una carga __VIEWSTATE que consume un servidor diferente, el consumidor experimentará un error de validación de MAC.

• Resolución 1a: Crear un elemento machineKey> explícito <

  Al agregar un elemento machineKey> explícito <al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET que no use la clave criptográfica generada automáticamente. Consulte el Apéndice A para obtener instrucciones sobre cómo generar un <elemento machineKey> . Después de agregar este elemento al archivo Web.config, vuelva a implementar la aplicación en cada servidor de la granja de servidores.

  Nota Algunos servicios de hospedaje web, como los sitios web de Microsoft Azure, toman medidas para sincronizar la clave generada automáticamente de cada aplicación en sus servidores back-end. Esto permite que las aplicaciones que no han especificado un elemento machineKey> explícito <sigan funcionando en estos entornos, incluso si la aplicación se ejecuta en una granja de servidores. Si su aplicación se ejecuta en un servicio de hospedaje de terceros, comuníquese con su proveedor de alojamiento para determinar si esta situación se aplica a usted.

• Resolución 1b: Habilitar la afinidad en el equilibrador de carga

  Si los sitios funcionan detrás de un equilibrador de carga, puede habilitar la afinidad del servidor para solucionar temporalmente el problema. Esto ayuda a garantizar que un cliente determinado solo interactúe con un servidor físico detrás del equilibrador de carga, de modo que todas las cargas criptográficas sean generadas y consumidas por el mismo servidor.

  Esto no debe considerarse una solución a largo plazo al problema. Incluso cuando la afinidad de servidor está habilitada, la mayoría de los equilibradores de carga redirigirán al cliente a un servidor físico diferente si el servidor original al que se afinaron los equilibradores de carga se desconecta. Esto hace que el nuevo servidor rechace cargas criptográficas (como __VIEWSTATE, vales de autenticación de formularios, MVC, tokens antifalsificación y otros servicios) que el cliente tiene actualmente.

  Es preferible usar un elemento machineKey> explícito <y volver a implementar la aplicación a habilitar la afinidad de servidor.

Causa 2: el proceso de trabajo usa la identidad del grupo de aplicaciones de IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introdujo la identidad del grupo de aplicaciones, un nuevo mecanismo de aislamiento que ayuda a proporcionar una mayor seguridad a los servidores que ejecutan aplicaciones ASP.NET. Sin embargo, los sitios que se ejecutan bajo la identidad del grupo de aplicaciones no tienen acceso al registro HKCU. Aquí es donde el tiempo de ejecución de ASP.NET almacena sus claves machineKey> generadas <automáticamente. El resultado es que ASP.NET no puede conservar la clave generada automáticamente cuando se restablece el grupo de aplicaciones. Por lo tanto, cada vez que se restablece w3wp.exe, se genera una nueva clave temporal.

Nota: Esto no es un problema en IIS 7.5 (Windows 7, Windows Server 2008 R2) y versiones posteriores. En estas versiones de IIS, ASP.NET puede conservar sus claves generadas automáticamente en una ubicación diferente que sobreviva a los restablecimientos del grupo de aplicaciones.

• Resolución 2a: Usar la utilidad aspnet_regiis

  ASP.NET instalaciones contienen una utilidad, aspnet_regiis.exe. Esta utilidad permite ASP.NET interfaz con IIS para realizar las configuraciones necesarias para ejecutar una aplicación administrada. Una de estas configuraciones crea las claves necesarias en el subárbol del Registro para habilitar la persistencia de las claves de equipo generadas automáticamente.

  En primer lugar, debe determinar qué grupo de aplicaciones está utilizando su sitio. Esto se puede determinar mediante la utilidad inetmgr que se incluye con IIS. Seleccione su sitio en la vista de árbol de la izquierda, haga clic con el botón derecho en Administrar sitio weby luego haga clic en Configuración avanzada. El cuadro de diálogo que aparece mostrará el nombre del grupo de aplicaciones.

  

  Para aplicar scaffolding a las claves del Registro adecuadas para un grupo de aplicaciones de ASP.NET 4.0, siga estos pasos:

  1. Abra un símbolo del sistema administrativo.

  2. Localice el directorio adecuado, dependiendo de si el grupo de aplicaciones es de 32 bits o de 64 bits:

     • Grupo de aplicaciones de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • Grupo de aplicaciones de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. Vaya al directorio, escriba el comando siguiente y presione Entrar:

     aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

  Si el grupo de aplicaciones es un grupo de aplicaciones ASP.NET 2.0 o 3.5, siga estos pasos:

  1. Abra un símbolo del sistema administrativo.

  2. Localice el directorio adecuado, dependiendo de si el grupo de aplicaciones es de 32 bits o de 64 bits:

     • Grupo de aplicaciones de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • Grupo de aplicaciones de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. Vaya al directorio, escriba el comando siguiente y presione Entrar:

     aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

  Por ejemplo, si el grupo de aplicaciones se denomina Mi grupo de aplicaciones (como en la imagen anterior), ejecute el siguiente comando:
   
  aspnet_regiis -ga "IIS APPPOOL\My App Pool"

  Nota: Es posible que los servicios del sistema APPHOSTSVC y WAS tengan que estar ejecutándose para que la utilidad aspnet_regiis resuelva los nombres APPPOOL\* de IIS correctamente.

• Solución 2b: Crear un elemento MachineKey> explícito <

  Al agregar un elemento machineKey> explícito <al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET que no use la clave criptográfica generada automáticamente. Consulte el Apéndice A para obtener instrucciones sobre cómo generar un <elemento machineKey> .

Causa 3: El grupo de aplicaciones se configura mediante LoadUserProfile=false

Si el grupo de aplicaciones se ejecuta con una identidad personalizada, es posible que IIS no haya cargado el perfil de usuario para la identidad. Esto tiene el efecto secundario de hacer que el registro HKCU no esté disponible para ASP.NET conserve la machineKey> generada <automáticamente. Por lo tanto, se creará una nueva clave generada automáticamente cada vez que se reinicie la aplicación. Consulte la sección Perfil de usuario en el sitio web de Microsoft para obtener más información.

• Resolución 3a: Usar la utilidad aspnet_regiis

  Las instrucciones para esto son las mismas que en la Resolución 2a. Consulte esa sección para obtener más información.

• Solución 3b: Utilizar una clave de máquina explícita <>

  Al agregar un elemento machineKey> explícito <al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET que no use la clave criptográfica generada automáticamente. Consulte el Apéndice A para obtener instrucciones sobre cómo generar un <elemento machineKey> .

• Resolución 3c: Aprovisionar manualmente las claves del Registro HKCU necesarias

  Si no puede ejecutar la utilidad aspnet_regiis, puede utilizar una secuencia de comandos Windows PowerShell para aprovisionar las claves del Registro apropiadas en HKCU. Consulte el Apéndice B para obtener más información.

• Resolución 3d: establezca LoadUserProfile=true para este grupo de aplicaciones

  También puede habilitar la carga del perfil de usuario dentro de este grupo de aplicaciones. Esto hace que el subárbol del registro HKCU, la carpeta temporal y otras ubicaciones de almacenamiento específicas del usuario estén disponibles para la aplicación. Sin embargo, esto puede provocar un aumento del uso de disco o memoria para el proceso de trabajo. Consulte el elemento para obtener más información sobre cómo habilitar esta configuración.

Causa 4: la propiedad Page.ViewStateUserKey tiene un valor incorrecto

Los desarrolladores de software pueden decidir usar la propiedad Page.ViewStateUserKey para agregar protección contra falsificaciones de solicitudes entre sitios al campo __VIEWSTATE. Si usa la propiedad Page.ViewStateUserKey, normalmente se establece en un valor como el nombre de usuario del usuario actual o el identificador de sesión del usuario. Las plantillas de proyecto para aplicaciones WebForms en Microsoft Visual Studio 2012 y versiones posteriores contienen ejemplos que utilizan esta propiedad. Vea el tema de la propiedad Page.ViewStateUserKey en el sitio web de Microsoft Developer Network (MSDN) para obtener más información.

Si se especifica la propiedad ViewStateUserKey, su valor se graba en __VIEWSTATE en el momento de la generación. Cuando se consume el campo __VIEWSTATE, el servidor comprueba la propiedad ViewStateUserKey de la página actual y la valida con el valor que se usó para generar el campo __VIEWSTATE. Si los valores no coinciden, la solicitud se rechaza por ser potencialmente maliciosa.

Un ejemplo de un error relacionado con ViewStateUserKey sería un cliente que tiene dos pestañas abiertas en el explorador. El cliente ha iniciado sesión como el usuario A y, en la primera pestaña, una página se representa con un __VIEWSTATE cuya propiedad ViewStateUserKey contiene el "usuario A". En la segunda pestaña, el cliente cierra sesión y vuelve a iniciar sesión como usuario B. El cliente vuelve a la primera pestaña y envía el formulario. La propiedad ViewStateUserKey podría contener "Usuario B" (porque eso es lo que dice la cookie de autenticación del cliente). Sin embargo, el campo __VIEWSTATE que envió el cliente contiene "Usuario A". Esta falta de coincidencia causa el error.

• Resolución 4a: Comprobar que ViewStateUserKey está establecido correctamente

  Si la aplicación usa la propiedad ViewStateUserKey, compruebe que el valor de la propiedad es el mismo cuando se genera el estado de vista y cuando se consume. Si está utilizando el nombre de usuario del usuario que ha iniciado sesión actualmente, asegúrese de que el usuario siga teniendo la sesión iniciada y de que la identidad del usuario no haya cambiado en el momento de la devolución. Si usa el identificador de sesión del usuario actual, asegúrese de que no se ha agotado el tiempo de espera de la sesión.

  Si se ejecuta en un entorno de granja, asegúrese de que los <elementos machineKey> coinciden. Consulte el Apéndice A para obtener instrucciones sobre cómo generar estos elementos.

          

Apéndice A: Cómo generar un <elemento machineKey>

        
Para generar usted mismo un <elemento machineKey>, puede utilizar el siguiente script de Windows PowerShell:

# 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)
  }
}

Para aplicaciones ASP.NET 4.0, simplemente puede llamar a Generate-MachineKey sin parámetros para generar un <elemento machineKey> de la siguiente manera:

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

ASP.NET aplicaciones 2.0 y 3.5 no admiten HMACSHA256. En su lugar, puede especificar SHA1 para generar un elemento machineKey> compatible <de la siguiente manera:

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

Tan pronto como tenga un <elemento machineKey> , puede colocarlo en el archivo Web.config. El <elemento machineKey> sólo es válido en el archivo Web.config en la raíz de la aplicación y no es válido en el nivel de subcarpeta.

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

Para obtener una lista completa de los algoritmos admitidos, ejecute el Generate-MachineKey de ayuda desde el Windows PowerShell mensaje.

Apéndice B: Aprovisionamiento del Registro para conservar las claves generadas automáticamente

De forma predeterminada, ya que las características de ASP. Las claves generadas automáticamente por NET se conservan en el registro HKCU, estas claves se pueden perder si el perfil de usuario no se ha cargado en el proceso de trabajo de IIS y, a continuación, el grupo de aplicaciones se recicla. Este escenario podría afectar a los proveedores de hospedaje compartido que ejecutan grupos de aplicaciones como cuentas de usuario estándar de Windows.

Para solucionar esta situación, ASP.NET habilita la conservación de las claves generadas automáticamente en el registro HKLM en lugar de en el registro HKCU. Esto se lleva a cabo normalmente mediante la utilidad aspnet_regiis (consulte las instrucciones de la sección "Resolución 2a: Utilizar la utilidad aspnet_regiis"). Sin embargo, para los administradores que no deseen ejecutar esta utilidad, se puede usar en su lugar el siguiente script de Windows PowerShell:

# 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)
    }
  }
}

En el ejemplo siguiente se muestra cómo aprovisionar las entradas de registro HKLM adecuadas para un grupo de aplicaciones que se ejecuta como usuario example@contoso.com (este es el UPN de la cuenta de usuario de Windows). Este grupo de aplicaciones es un grupo de aplicaciones de 32 bits que ejecuta CLR v2.0 (ASP.NET 2.0 o 3.5).

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

Si, en cambio, el grupo de aplicaciones es un grupo de aplicaciones de 64 bits que ejecuta CLR v4.0 (ASP.NET 4.0 ó 4.5), el comando es el siguiente:

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

Aunque las claves generadas automáticamente se almacenan en HKLM, la subclave del Registro que contiene el material criptográfico secreto de cada cuenta de usuario se agrega a una lista de control de acceso (ACL) para que otras cuentas de usuario no puedan leer el material criptográfico.

Apéndice C: Cifrado del elemento machineKey> en archivos <de configuración

Es posible que los administradores de servidor no quieran que la información altamente confidencial, como el material de clave de la clave de la <máquina> , esté en texto sin formato en los archivos de configuración. Si este es el caso, los administradores pueden decidir aprovechar una característica de .NET Framework conocida como "configuración protegida". Esta característica le permite cifrar determinadas secciones de los archivos .config. Si el contenido de estos archivos de configuración se divulga alguna vez, el contenido de estas secciones seguirá siendo secreto.

Puede encontrar una breve introducción a la configuración protegida en el sitio web de MSDN. También contiene un tutorial sobre cómo proteger los <elementos connectionStrings> y <machineKey> del archivo Web.config.