Problemen met MAC-code (Message Authentication Code) oplossen.

Wat is weergavestatus?

De weergavestatus is informatie die wordt gesplitst tussen pagina's van webformulieren (.aspx) in een ASP.NET toepassing. De HTML-opmaak voor het veld __VIEWSTATE ziet er ongeveer als volgt uit:

<Input type="verborgen" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
Een voorbeeld van een item dat kan worden opgeslagen in het veld __VIEWSTATE is de tekst van een besturingselement Knop. Als een gebruiker op de knop klikt, kan de gebeurtenis-handler van de Button_Click de tekst van de knop ophalen uit het veld Weergavestatus. Zie het onderwerp ASP.NET View State Overview op de website van Microsoft Developer Network (MSDN) voor een veel gedetailleerder overzicht van de ASP.NET weergavestatus.

Omdat het veld __VIEWSTATE belangrijke informatie bevat die wordt gebruikt om de pagina op postback te reconstrueren, moet u ervoor zorgen dat aanvallers niet met dit veld kunnen knoeien. Als een aanvaller een schadelijke __VIEWSTATE payload heeft ingediend, kan de aanvaller de toepassing mogelijk misleiden om een actie uit te voeren die anders niet zou zijn uitgevoerd.

Om dit soort manipulatieaanvallen te voorkomen, wordt het veld __VIEWSTATE beveiligd met een Message Authentication Code (MAC). ASP.NET valideert de MAC die samen met de __VIEWSTATE-nettolading wordt verzonden wanneer een postback plaatsvindt. De sleutel die wordt gebruikt om de MAC te berekenen, wordt gespecificeerd in het element van de toepassing in het Web.config bestand. Omdat de aanvaller de inhoud van het <machineKey-element> niet kan raden, kan de aanvaller geen geldige MAC opgeven als de aanvaller probeert te knoeien met de __VIEWSTATE-payload. ASP.NET detecteert dat er geen geldige MAC is opgegeven en ASP.NET weigert het schadelijke verzoek.

Wat veroorzaakt MAC-validatiefouten?

Een MAC-validatiefout ziet er ongeveer uit zoals het volgende voorbeeld:

Oorzaak 1: De webtoepassing wordt uitgevoerd in een farm (omgeving met meerdere servers)

ASP.NET genereert automatisch een cryptografische sleutel voor elke toepassing en slaat de sleutel op in de HKCU-registercomponent. Deze automatisch gegenereerde sleutel wordt gebruikt als er geen expliciet <machineKey-element> aanwezig is in de configuratie van de toepassing. Omdat deze automatisch gegenereerde sleutel echter lokaal is op de computer waarop de sleutel is gemaakt, veroorzaakt dit scenario een probleem voor toepassingen die in een farm worden uitgevoerd. Elke server in de farm genereert een eigen lokale sleutel en geen van de servers in de farm wordt het eens over de te gebruiken sleutel. Het resultaat is dat, als een server een __VIEWSTATE payload genereert die een andere server verbruikt, de consument een MAC-validatiefout zal ervaren.

• Oplossing 1a: Maak een expliciet <element van de machineKey>

  Door een expliciet <machineKey-element> toe te voegen aan het Web.config bestand van de toepassing, vertelt de ontwikkelaar ASP.NET de automatisch gegenereerde cryptografische sleutel niet te gebruiken. Zie Bijlage A voor instructies over het genereren van een <machineKey-element> . Nadat dit element is toegevoegd aan het Web.config bestand, implementeert u de toepassing opnieuw op elke server in de farm.

  Opmerking Sommige webhostingservices, zoals Microsoft Azure-websites, nemen stappen om de automatisch gegenereerde sleutel van elke toepassing te synchroniseren op hun back-endservers. Hierdoor kunnen toepassingen die geen expliciet <machineKey-element> hebben opgegeven in deze omgevingen blijven werken, zelfs als de toepassing in een farm wordt uitgevoerd. Als uw toepassing wordt uitgevoerd op een hostingservice van derden, neem dan contact op met uw hostingprovider om te bepalen of deze situatie op u van toepassing is.

• Oplossing 1b: Schakel affiniteit in de load balancer in

  Als uw sites achter een taakverdeling werken, kunt u serveraffiniteit inschakelen om het probleem tijdelijk te omzeilen. Dit helpt ervoor te zorgen dat een bepaalde client slechts met één fysieke server achter de load balancer interageert, zodat alle cryptografische nettoladingen worden gegenereerd en gebruikt door dezelfde server.

  Dit moet niet worden beschouwd als een langetermijnoplossing voor het probleem. Zelfs wanneer serveraffiniteit is ingeschakeld, zullen de meeste load balancers de client omleiden naar een andere fysieke server als de oorspronkelijke server waarmee de load balancers waren geaffinitiseerd, offline gaat. Dit zorgt ervoor dat de nieuwe server cryptografische nettoladingen (zoals __VIEWSTATE, formulieren, verificatietickets, MVC's, antivervalsingtokens, en andere services) die momenteel op de client staan, weigert.

  Het gebruik van een expliciet <machineKey-element> en het opnieuw implementeren van de toepassing verdient de voorkeur boven het inschakelen van serveraffiniteit.

Oorzaak 2: Het werkproces maakt gebruik van de id van de toepassingsgroep IIS 7.0

IIS (Internet Information Services) 7.0 (Windows Vista, Windows Server 2008) introduceerde toepassingsgroepidentiteit, een nieuw isolatiemechanisme waarmee servers met ASP.NET toepassingen beter worden beveiligd. Sites die onder de identiteit van de groep van toepassingen worden uitgevoerd, hebben echter geen toegang tot het HKCU-register. Dit is waar de ASP.NET runtime zijn automatisch gegenereerde <machineKey-sleutels> opslaat. Het resultaat is dat ASP.NET de automatisch gegenereerde sleutel niet kunt behouden wanneer de groep van toepassingen opnieuw wordt ingesteld. Daarom wordt elke keer dat w3wp.exe opnieuw wordt ingesteld, een nieuwe tijdelijke sleutel gegenereerd.

Opmerking: dit is geen probleem in IIS 7.5 (Windows 7, Windows Server 2008 R2) en latere versies. In deze versies van IIS kan ASP.NET de automatisch gegenereerde sleutels op een andere locatie bewaren die het opnieuw instellen van de groep van toepassingen overleeft.

• Oplossing 2a: Gebruik het hulpprogramma aspnet_regiis

  ASP.NET installaties een hulpprogramma bevatten, aspnet_regiis.exe. Met dit hulpprogramma kan ASP.NET interface met IIS maken om de configuraties uit te voeren die vereist zijn om een beheerde toepassing uit te voeren. Een van deze configuraties maakt de benodigde sleutels in de registercomponent om persistentie van automatisch gegenereerde machinesleutels mogelijk te maken.

  Eerst moet u bepalen welke groep van toepassingen uw site gebruikt. Dit kan worden vastgesteld met het hulpprogramma inetmgr dat deel uitmaakt van IIS. Selecteer uw site in de structuurweergave aan de linkerkant, klik met de rechtermuisknop op Websites beherenen klik vervolgens op Geavanceerde instellingen. In het dialoogvenster dat wordt weergegeven, wordt de naam van de groep van de toepassingen weergegeven.

  

  Voer de volgende stappen uit om de juiste registersleutels voor een ASP.NET 4.0-toepassingsgroep te gebruiken:

  1. Open een administratieve opdrachtprompt.

  2. Zoek de juiste map, afhankelijk van of uw groep toepassingen 32-bits of 64-bits is:

     • 32-bits groep van toepassingen: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • 64-bits groep van toepassingen: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. Ga naar de adreslijst, typ de volgende opdracht en druk op Enter:

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

  Als de groep van toepassingen een ASP.NET 2.0- of 3.5-groep is, voert u de volgende stappen uit:

  1. Open een administratieve opdrachtprompt.

  2. Zoek de juiste map, afhankelijk van of uw groep toepassingen 32-bits of 64-bits is:

     • 32-bits groep van toepassingen: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • 64-bits groep van toepassingen: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. Ga naar de adreslijst, typ de volgende opdracht en druk op Enter:

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

  Als uw groep van toepassingen bijvoorbeeld Mijn groep van apps heet (zoals in de vorige afbeelding), voert u de volgende opdracht uit:
   
  aspnet_regiis -ga "IIS APPPOOL\Mijn app-groep"

  Opmerking: de systeemservices APPHOSTSVC en WAS moeten mogelijk actief zijn voor het hulpprogramma aspnet_regiis om IIS APPPOOL\*-namen op de juiste manier om te zetten.

• Oplossing 2b: Maak een expliciet <element van de machineKey>

  Door een expliciet <machineKey-element> toe te voegen aan het Web.config bestand van de toepassing, vertelt de ontwikkelaar ASP.NET de automatisch gegenereerde cryptografische sleutel niet te gebruiken. Zie Bijlage A voor instructies over het genereren van een <machineKey-element> .

Oorzaak 3: De groep van toepassingen is geconfigureerd met behulp van LoadUserProfile=false

Als de groep van toepassingen met een aangepaste identiteit wordt uitgevoerd, is het gebruikersprofiel voor de identiteit mogelijk niet in het geheugen geladen. Dit heeft als neveneffect dat het HKCU-register niet beschikbaar is voor ASP.NET om de automatisch gegenereerde <machineKey> te behouden. Daarom wordt er telkens wanneer de toepassing opnieuw start een nieuwe automatisch gegenereerde sleutel gemaakt. Zie de sectie Gebruikersprofiel op de Microsoft-website voor meer informatie.

• Oplossing 3a: Gebruik het hulpprogramma aspnet_regiis

  De instructies hiervoor zijn hetzelfde als resolutie 2a. Zie die sectie voor meer informatie.

• Oplossing 3b: Gebruik een expliciete <machineKey>

  Door een expliciet <machineKey-element> toe te voegen aan het Web.config bestand van de toepassing, vertelt de ontwikkelaar ASP.NET de automatisch gegenereerde cryptografische sleutel niet te gebruiken. Zie Bijlage A voor instructies over het genereren van een <machineKey-element> .

• Oplossing 3c: De vereiste registersleutels van HKCU handmatig inrichten

  Als u het hulpprogramma voor aspnet_regiis niet kunt uitvoeren, kunt u een Windows PowerShell-script gebruiken om de juiste registersleutels in te richten in HKCU. Zie Bijlage B voor meer informatie.

• Oplossing 3d: Stel LoadUserProfile=true in voor deze groep van toepassingen

  U kunt ook het laden van het gebruikersprofiel in deze groep van toepassingen inschakelen. Hierdoor worden de HKCU-register, de tijdelijke map en andere gebruikersspecifieke opslaglocaties beschikbaar voor de toepassing. Dit kan echter leiden tot een hoger schijf- of geheugengebruik voor het werkproces. Zie het element voor meer informatie over het inschakelen van deze instelling.

Oorzaak 4: De eigenschap Page.ViewStateUserKey heeft een onjuiste waarde

Softwareontwikkelaars kunnen besluiten om de eigenschap Page.ViewStateUserKey te gebruiken om bescherming tegen vervalsing op meerdere sites toe te voegen aan het veld __VIEWSTATE. Als u de eigenschap Page.ViewStateUserKey gebruikt, wordt deze meestal ingesteld op een waarde zoals de gebruikersnaam van de huidige gebruiker of de sessie-id van de gebruiker. De projectsjablonen voor WebForms-toepassingen in Microsoft Visual Studio 2012 en latere versies bevatten voorbeelden waarin deze eigenschap wordt gebruikt. Zie het onderwerp Page.ViewStateUserKey Property op de website van Microsoft Developer Network (MSDN) voor meer informatie.

Als de eigenschap ViewStateUserKey is opgegeven, wordt de waarde ervan tijdens het genereren in __VIEWSTATE gebrand. Wanneer het veld __VIEWSTATE wordt gebruikt, controleert de server de eigenschap ViewStateUserKey van de huidige pagina en valideert deze met de waarde die is gebruikt om het veld __VIEWSTATE te genereren. Als de waarden niet overeenkomen, wordt de aanvraag geweigerd als mogelijk schadelijk.

Een voorbeeld van een aan ViewStateUserKey gerelateerde fout is een client met twee tabbladen geopend in de browser. De client is aangemeld als gebruiker A en op het eerste tabblad wordt een pagina weergegeven met een __VIEWSTATE waarvan de eigenschap ViewStateUserKey 'Gebruiker A' bevat. In het tweede tabblad meldt de client zich af en vervolgens weer aan als gebruiker B. De klant gaat terug naar het eerste tabblad en verzendt het formulier. De eigenschap ViewStateUserKey bevat mogelijk 'Gebruiker B' (omdat dat is wat de verificatiecookie van de client aangeeft). Het __VIEWSTATE veld dat de klant heeft verzonden, bevat echter 'Gebruiker A'. Deze niet-overeenkomende oorzaak van de fout.

• Oplossing 4a: Controleer of ViewStateUserKey correct is ingesteld

  Als uw toepassing gebruikmaakt van de eigenschap ViewStateUserKey, controleert u of de waarde van de eigenschap hetzelfde is, zowel op het moment dat de weergavestatus wordt gegenereerd als op het moment dat deze wordt verbruikt. Als u de gebruikersnaam van de huidige ingelogde gebruiker gebruikt, zorg er dan voor dat de gebruiker nog steeds is ingelogd en dat de identiteit van de gebruiker niet is gewijzigd op het moment van postback. Als u de sessie-id van de huidige gebruiker gebruikt, controleert u of er geen time-out is opgetreden voor de sessie.

  Als u werkt in een farmomgeving, controleert u of de <machineKey-elementen> overeenkomen. Zie Bijlage A voor instructies over het genereren van deze elementen.

          

Bijlage A: Hoe een <machinesleutelelement> te genereren

        
Als u zelf een <machineKey-element> wilt genereren, kunt u het volgende Windows PowerShell script gebruiken:

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

Voor ASP.NET 4.0-toepassingen kunt u Generate-MachineKey zonder parameters aanroepen om als volgt een <machineKey-element> te genereren:

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

ASP.NET 2.0- en 3.5-toepassingen bieden geen ondersteuning voor HMACSHA256. In plaats daarvan kunt u SHA1 opgeven om als volgt een compatibel <machineKey-element> te genereren:

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

Zodra u een <machineKey-element> hebt, kunt u dit in het Web.config bestand plaatsen. Het <element machineKey> is alleen geldig in het Web.config bestand in de hoofdmap van uw toepassing en is niet geldig op het niveau van de submap.

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

Voer Help Generate-MachineKey uit vanaf de prompt Windows PowerShell voor een volledige lijst met ondersteunde algoritmen.

Bijlage B: Het register inrichten zodat automatisch gegenereerde sleutels behouden blijven

Omdat ASP. De automatisch gegenereerde sleutels van NET blijven behouden in het HKCU-register, deze sleutels kunnen verloren gaan als het gebruikersprofiel niet is geladen in het IIS-werkproces en de groep van toepassingen vervolgens wordt gerecycled. Dit scenario kan van invloed zijn op gedeelde hostingproviders die toepassingsgroepen uitvoeren als standaard Windows-gebruikersaccounts.

U kunt deze situatie omzeilen door ASP.NET in te schakelen om de automatisch gegenereerde sleutels in het HKLM-register in plaats van in het HKCU-register te behouden. Dit wordt meestal gedaan met behulp van het aspnet_regiis hulpprogramma (zie de instructies in de sectie "Oplossing 2a: gebruik het hulpprogramma aspnet_regiis). Voor beheerders die dit hulpprogramma niet willen uitvoeren, kan in plaats hiervan het volgende Windows PowerShell-script worden gebruikt:

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

In het volgende voorbeeld ziet u hoe u de juiste registervermeldingen voor HKLM inricht voor een groep toepassingen die als de gebruiker example@contoso.com wordt uitgevoerd (dit is de UPN van het Windows-gebruikersaccount). Deze groep van toepassingen is een 32-bits groep van toepassingen waarop CLR v2.0 (ASP.NET 2.0 of 3.5) wordt uitgevoerd.

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

Als de groep van toepassingen een 64-bits groep van toepassingen is waarop CLR v4.0 (ASP.NET 4.0 of 4.5) wordt uitgevoerd, is de opdracht als volgt:

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

Hoewel de automatisch gegenereerde sleutels worden opgeslagen in HKLM, wordt de subregistersleutel die het geheime cryptografische materiaal van elk gebruikersaccount bevat, toegevoegd aan een toegangscontrolelijst (ACL), zodat het cryptografische materiaal niet door andere gebruikersaccounts kan worden gelezen.

Bijlage C: Het machineKey-element> in configuratiebestanden versleutelen <

Serverbeheerders willen mogelijk niet dat zeer gevoelige informatie, zoals het materiaal van de <machineKey-sleutel> , in platte tekst in configuratiebestanden wordt weergegeven. In dat geval kunnen beheerders besluiten gebruik te maken van een functie van .NET Framework die 'beveiligde configuratie' wordt genoemd. Met deze functie kunt u bepaalde secties van de .config bestanden versleutelen. Als de inhoud van deze configuratiebestanden ooit openbaar wordt gemaakt, blijft de inhoud van deze secties geheim.

Op de website van MSDN vindt u een kort overzicht van de beveiligde configuratie . Het bevat ook een zelfstudie over het beveiligen van de <connectionStrings> en <machineKey-elementen> van het Web.config bestand.