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

¿Qué es el estado de vista?

El estado de vista es información que se redondea entre páginas webForms (.aspx) en una aplicación de 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 se puede almacenar 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 button del campo de estado de vista. Consulta el tema ASP.NET Ver información general del estado en el sitio web de Microsoft Developer Network (MSDN) para obtener información general mucho más detallada sobre el estado de vista de ASP.NET.

Dado que el campo __VIEWSTATE contiene información importante que se usa para reconstruir la página tras el retorno, asegúrate de que un atacante no pueda alterar este campo. Si un atacante envió una carga de __VIEWSTATE malintencionada, el atacante podría engañar potencialmente a la aplicación para que realice una acción que, de lo contrario, 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 el MAC que se envía junto con la carga de __VIEWSTATE cuando se produce una devolución de datos. La clave que se usa para calcular el MAC se especifica en el elemento de la aplicación en el archivo Web.config. Debido a que el atacante no puede adivinar el contenido del <elemento machineKey> , el atacante no puede proporcionar un MAC válido si el atacante intenta alterar la carga útil del __VIEWSTATE. ASP.NET detectará que no se ha proporcionado un MAC válido y ASP.NET rechazará la solicitud malintencionada.

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

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

Causa 1: la aplicación web se está ejecutando 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, como esta clave generada automáticamente es local en el equipo que creó la clave, este escenario provoca 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 de servidores aceptará qué clave usar. El resultado es que, si un servidor genera una __VIEWSTATE carga que consume un servidor diferente, el consumidor experimentará un error de validación 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 no usar la clave criptográfica generada automáticamente. Consulta 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 Microsoft Azure sitios web, 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 hayan especificado un elemento machineKey> explícito <sigan trabajando en estos entornos, incluso si la aplicación se está ejecutando en una granja de servidores. Si la aplicación se ejecuta en un servicio de hospedaje de terceros, póngase en contacto con su proveedor de hospedaje 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 de servidor para solucionar temporalmente el problema. Esto ayuda a garantizar que cualquier cliente determinado solo interactúa con un servidor físico detrás del equilibrador de carga para que el mismo servidor genere y consuma todas las cargas criptográficas.

  Esto no debe considerarse una solución a largo plazo para el problema. Incluso cuando se habilita la afinidad de servidor, la mayoría de los equilibradores de carga redirigirán el cliente a un servidor físico diferente si el servidor original al que estaban afines los equilibradores de carga pasa a estar desconectado. Esto hace que el nuevo servidor rechace las cargas criptográficas (como __VIEWSTATE, vales de autenticación de formularios, tokens anti falsificación de MVP y otros servicios) que el cliente tiene actualmente.

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

Causa 2: El proceso de trabajo utiliza 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 mayor seguridad para los servidores que ejecutan ASP.NET aplicaciones. 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 Este no es un problema en IIS 7.5 (Windows 7, Windows Server 2008 R2) y versiones posteriores. En estas versiones de IIS, ASP.NET pueden conservar sus claves generadas automáticamente en una ubicación diferente que sobrevive 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 permitir la persistencia de claves de máquina generadas automáticamente.

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

  

  Para crear andamios de 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. Busque el directorio adecuado, dependiendo de si el grupo de aplicaciones es de 32 bits o 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. Busque el directorio adecuado, dependiendo de si el grupo de aplicaciones es de 32 bits o 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 Los servicios del sistema APPHOSTSVC y WAS pueden tener que ejecutarse para que la utilidad aspnet_regiis resuelva correctamente los nombres APPPOOL\* de IIS.

• Resolució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 no usar la clave criptográfica generada automáticamente. Consulta 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 está ejecutando 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 persistir la machineKey> generada <automáticamente. Por lo tanto, se creará una nueva clave generada automáticamente cada vez que se reinicie la aplicación. Consulta 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 la Resolución 2a. Consulte esa sección para obtener más información.

• Resolución 3b: usar una machineKey explícita <>

  Al agregar un elemento machineKey> explícito <al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET no usar la clave criptográfica generada automáticamente. Consulta 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 usar un script de Windows PowerShell para aprovisionar las claves del Registro adecuadas en HKCU. Consulta el Apéndice B para obtener más información.

• Resolución 3d: Establecer 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 mayor uso de disco o memoria para el proceso de trabajo. Vea 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 falsificación 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 usan 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 grabará en __VIEWSTATE en tiempo de generación. Cuando se usa el campo __VIEWSTATE, el servidor comprueba la propiedad ViewStateUserKey de la página actual y lo valida con el valor que se usó para generar el campo de __VIEWSTATE. Si los valores no coinciden, la solicitud se rechazará como potencialmente malintencionada.

Un ejemplo de un error relacionado con ViewStateUserKey sería un cliente que tiene dos pestañas abiertas en el explorador. El cliente inicia sesión como usuario A y, en la primera pestaña, se representa una página con un __VIEWSTATE cuya propiedad ViewStateUserKey contiene "Usuario A". En la segunda pestaña, el cliente cierra la sesión y luego vuelve a iniciarla como usuario B. El cliente vuelve a la primera pestaña y envía el formulario. La propiedad ViewStateUserKey puede 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 sea el mismo tanto cuando se genera el estado de vista como cuando se usa. Si usa el nombre de usuario del usuario que ha iniciado sesión actual, asegúrese de que el usuario aún ha iniciado sesión y de que la identidad del usuario no ha cambiado en el momento de la devolución de datos. Si usa el identificador de sesión del usuario actual, asegúrese de que no se haya agotado el tiempo de salida de la sesión.

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

          

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

        
Para generar un <elemento machineKey> usted mismo, puede usar 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 de ASP.NET 4.0, 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="..." />

las aplicaciones ASP.NET 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> solo es válido en el archivo de 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 la ayuda Generate-MachineKey desde la solicitud de Windows PowerShell.

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

De forma predeterminada, porque ASP. Las claves generadas automáticamente de 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 permite conservar las claves generadas automáticamente en el Registro HKLM en lugar del registro HKCU. Esto suele realizarse mediante el uso de la utilidad aspnet_regiis (consulte las instrucciones de la sección "Resolución 2a: Uso de la utilidad aspnet_regiis"). Sin embargo, para los administradores que no quieran ejecutar esta utilidad, se pueden usar los siguientes Windows PowerShell script en su lugar:

# 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 el grupo de aplicaciones en su lugar es un grupo de aplicaciones de 64 bits que ejecuta CLR v4.0 (ASP.NET 4.0 o 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 controles de acceso (ACL) para que otras cuentas de usuario no puedan leer el material criptográfico.

Apéndice C: Cifrar el <elemento machineKey> en los archivos de configuración

Es posible que los administradores del servidor no quieran que la información altamente confidencial, como el <material de clave machineKey> , esté en formato de texto sin formato en los archivos de configuración. Si este es el caso, los administradores pueden decidir aprovechar las ventajas de 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 descripción general de 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.