Lösa Visa tillstånd meddelande autentisering kod (MAC) fel

Vad är visningsläge?

Visa tillstånd är information som är avrunda mellan WebForms-sidor (. aspx) i ett ASP.NET-program. HTML-koden för fältet _ "VIEWSTATE" liknar följande:

< input type = "dold" namn = "_ _ VIEWSTATE" ID = "_ _ VIEWSTATE" value = "..."/>Ett exempel på ett objekt som kan lagras i fältet _ _ VIEWSTATE är texten i en knappkontroll. Om en användare klickar på knappen kommer Button_Click-händelsehanteraren att kunna extrahera knappens text från fältet vytillstånd. Se avsnittet ASP.net Visa tillstånds översikt på webbplatsen Microsoft Developer Network (MSDN) för en mycket mer detaljerad översikt över läget ASP.net vy. Eftersom fältet ' _ VIEWSTATE ' innehåller viktig information som används för att återskapa sidan vid återanvisnings, kontrollera att en angripare inte kan manipulera det här fältet. Om en angripare har skickat en skadlig "_" VIEWSTATE nyttolast kan angriparen potentiellt lura programmet att utföra en åtgärd som annars inte skulle ha utförts. För att förhindra den här typen av manipulations angrepp skyddas fältet _ "VIEWSTATE" av en meddelandeautentiseringskod (MAC). ASP.NET validerar MAC-datorn som skickas tillsammans med "_" VIEWSTATE nyttolasten när en återpostback inträffar. Nyckeln som används för att beräkna MAC-datorn anges i programmets element i Web. config-filen. Eftersom angriparen inte kan gissa innehållet i < machineKey >-elementet, kan angriparen inte ange en giltig MAC om angriparen försöker manipulera med "_" VIEWSTATE nyttolasten. ASP.NET kommer att upptäcka att en giltig MAC inte har tillhandahållits, och ASP.NET kommer att avvisa den skadliga begäran.

Vad orsakar MAC valideringsfel?

Ett fel i MAC-validering kommer att likna följande exempel:

Server fel i programmet '/'. Valideringen av viewstate MAC misslyckades. Om det här programmet är värd för en webbservergrupp eller ett kluster, se till att < machineKey > konfiguration anger samma validationKey och validering algoritm. Det går inte att använda AutoGenerate i ett kluster. Beskrivning: ett ohanterat undantag inträffade under körningen av den aktuella webbegäran. Läs igenom stackspårningen om du vill ha mer information om felet och var det uppstod i koden. Undantagsinformation: system. Web. HttpException: validering av viewstate MAC misslyckades. Om det här programmet är värd för en webbservergrupp eller ett kluster, se till att < machineKey > konfiguration anger samma validationKey och validering algoritm. Det går inte att använda AutoGenerate i ett kluster. Källfel: [inga relevanta källrader] Källfil:... Rad: 0 Stackspårning: [ViewStateException: ogiltigt ViewState. Klient-IP::: 1 Port: 40653 Referer: http://localhost:40643/MyPage.aspx Sökväg:/MyPage.aspx User-Agent: Mozilla/5.0 (kompatibel; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): valideringen av viewstate MAC misslyckades. Om det här programmet är värd för en webbservergrupp eller ett kluster, se till att < machineKey > konfiguration anger samma validationKey och validering algoritm. Det går inte att använda AutoGenerate i ett kluster. Se http://go.microsoft.com/fwlink/?LinkID=314055 för mer information.] System. Web. UI. ViewStateException. ThrowError (undantag inre, sträng persistedState, sträng errorPageMessage, booleska macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (undantag inre, sträng persistedState) + 46 System. Web. UI. ObjectStateFormatter. Deserialize (String inputString, syfte syfte) + 861 System. Web. UI. ObjectStateFormatter. system. Web. UI. IStateFormatter2. Deserialize (String serializedState, syfte syfte) + 51 System. Web. UI. util. DeserializeWithAssert (IStateFormatter2 Formatter, String serializedState, syfte syfte) + 67 System. Web. UI. HiddenFieldPageStatePersister. load () + 444 System. Web. UI. Page. LoadPageStateFromPersistenceMedium () + 368 System. Web. UI. Page. LoadAllState () + 109 System. Web. UI. Page. ProcessRequestMain (booleska includeStagesBeforeAsyncPoint, booleska includeStagesAfterAsyncPoint) + 7959 System. Web. UI. Page. ProcessRequest (booleska includeStagesBeforeAsyncPoint, booleska includeStagesAfterAsyncPoint) + 429 System. Web. UI. Page. ProcessRequest () + 125 System. Web. UI. Page. ProcessRequestWithNoAssert (HttpContext kontext) + 48 System. Web. UI. Page. ProcessRequest (HttpContext kontext) + 234 ASP. mypage_aspx. ProcessRequest (HttpContext-kontext) i...: 0 System. Web. CallHandlerExecutionStep. system. Web. HttpApplication. IExecutionStep. Execute () + 1300 System. Web. HttpApplication. ExecuteStep (IExecutionStep steg, booleska & completedSynchronously) + 140

Orsak 1: webbprogrammet körs i en servergrupp (miljö med flera servrar)

ASP.NET genererar automatiskt en kryptografisk nyckel för varje program och lagrar nyckeln i registerdatafilen HKCU. Den här automatiskt genererade nyckeln används om det inte finns något explicit < machineKey > element i programmets konfiguration. Men eftersom den här automatiskt genererade nyckeln är lokal för den dator som skapade nyckeln, orsakar det här scenariot ett problem för program som körs i en servergrupp. Varje server i gruppen kommer att generera sin egen lokala nyckel och ingen av servrarna i servergruppen kommer överens om vilken nyckel som ska användas. Resultatet är att om en server genererar en _ _ VIEWSTATE nyttolasten som en annan server förbrukar, kommer konsumenten att uppleva ett fel i MAC-valideringen.

Lösning 1a: skapa en explicit < machineKey > element Genom att lägga till ett explicit < machineKey > element i programmets Web. config-fil, säger utvecklaren ASP.NET att inte använda den automatiskt genererade kryptografiska nyckeln. Se bilaga A för instruktioner om hur du skapar en < machineKey > element. När det här elementet har lagts till i filen Web. config, distribuera programmet till varje server i gruppen. Notera Vissa webbhotell tjänster, till exempel Microsoft Azure Websites, vidta åtgärder för att synkronisera varje programs automatiskt genererade nyckel över deras backend-servrar. På så sätt kan program som inte har angett en explicit < machineKey > element för att fortsätta arbeta i dessa miljöer, även om programmet körs i en servergrupp. Om ditt program körs på en tredje parts värdtjänst, kontakta din Värdleverantör för att avgöra om denna situation gäller för dig.
Upplösning 1b: Aktivera tillhörighet i belastningsutjämnaren Om webbplatserna fungerar bakom en belastningsutjämnare kan du aktivera server tillhörighet för att tillfälligt kunna arbeta runt problemet. Detta bidrar till att säkerställa att en given klient endast interagerar med en fysisk server bakom belastningsutjämnaren så att alla kryptografiska nyttolaster kommer att både genereras av och förbrukas av samma server. Detta bör inte betraktas som en långsiktig lösning på problemet. Även när Server tillhörighet är aktiverad omdirigerar de flesta belastningsutjämnare klienten till en annan fysisk server om den ursprungliga servern som belastningsutjämnarna var besläktade till kopplas från. Detta medför att den nya servern att avvisa kryptografiska nyttolaster (till exempel _ _ VIEWSTATE, formulär autentiseringsbiljetter, MVCs anti-förfalskning token och andra tjänster) som klienten har för närvarande. Använda en explicit < machineKey > elementet och omdistribuera programmet bör vara att föredra framför Aktivera server tillhörighet.

Orsak 2: arbetsprocessen använder IIS 7,0 programpoolsidentitet

Internet Information Services (IIS) 7,0 (Windows Vista, Windows Server 2008) introducerade programpoolsidentitet, en ny isoleringsmetod som hjälper till att ge ökad säkerhet för servrar som kör ASP.NET-program. Webbplatser som körs under programpoolsidentiteten har dock inte åtkomst till registret HKCU. Det är där ASP.NET Runtime lagrar sin automatiskt genererade < machineKey > nycklar. Resultatet är att ASP.NET inte kan spara den automatiskt genererade nyckeln när programpoolen återställs. Därför varje gång W3wp. exe återställs, genereras en ny temporär nyckel. Notera Detta är inte ett problem i IIS 7,5 (Windows 7, Windows Server 2008 R2) och senare versioner. På dessa versioner av IIS kan ASP.NET spara sina automatiskt genererade nycklar på en annan plats som överlever programpoolens återställs.

Lösning 2a: Använd verktyget Aspnet_regiis ASP.NET-installationer innehåller ett verktyg, Aspnet_regiis. exe. Det här verktyget kan ASP.NET gränssnitt med IIS för att utföra de konfigurationer som krävs för att köra ett hanterat program. En av dessa konfigurationer skapar nödvändiga nycklar i registreringsdatafilen för att aktivera persistence av automatiskt genererade datornycklar. Först måste du bestämma vilken programpool din webbplats använder. Detta kan bestämmas med hjälp av verktyget inetmgr som ingår i IIS. Välj din webbplats i trädvyn till vänster, högerklicka på Hantera website och klicka sedan på Avancerade inställningar. Den dialogruta som visas visar programpoolens namn. Om du vill byggnadsställning lämpliga registernycklar för en ASP.NET 4,0 programpool, så här:
1. Öppna en administrativ kommandotolk.
2. Leta reda på lämplig katalog, beroende på om programpoolen är 32-bitars eller 64-bitars:
  - 32-bitars programpool: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bitars programpool: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Flytta till katalogen, Skriv följande kommando och tryck sedan på RETUR:
  
  Aspnet_regiis-ga "IIS Apppool\app-pool-namn"
Om programpoolen är en ASP.NET 2,0 eller 3,5 programpool, så här:
1. Öppna en administrativ kommandotolk.
2. Leta reda på lämplig katalog, beroende på om programpoolen är 32-bitars eller 64-bitars:
  - 32-bitars programpool: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bitars programpool: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Flytta till katalogen, Skriv följande kommando och tryck sedan på RETUR:
  
  Aspnet_regiis-ga "IIS Apppool\app-pool-namn"
Till exempel om din programpool heter min app pool (som i föregående bild), kör du följande kommando:

Aspnet_regiis-ga "IIS Apppool\min app pool" Notera Systemtjänsterna APPHOSTSVC och WAS kan behöva köras för verktyget Aspnet_regiis för att matcha IIS APPPOOL \ *-namn på rätt sätt.
Lösning 2b: skapa en explicit < machineKey > element Genom att lägga till ett explicit < machineKey > element i programmets Web. config-fil, säger utvecklaren ASP.NET att inte använda den automatiskt genererade kryptografiska nyckeln. Se bilaga A för instruktioner om hur du skapar en < machineKey > element.

Orsak 3: programpoolen har konfigurerats med hjälp av LoadUserProfile = false

Om programpoolen körs med en anpassad identitet kan det hända att IIS inte har laddat användarprofilen för identiteten. Detta har bieffekt av att göra HKCU registret otillgänglig för ASP.NET att bevara den automatiskt genererade < machineKey >. Därför skapas en ny automatiskt genererad nyckel varje gång programmet startas om. Mer information finns i avsnittet användarprofil på Microsofts webbplats.

Lösning 3a: Använd verktyget Aspnet_regiis Instruktionerna för detta är desamma som resolution 2a. Se avsnittet för mer information.
Lösning 3B: Använd en explicit < machineKey > Genom att lägga till ett explicit < machineKey > element i programmets Web. config-fil, säger utvecklaren ASP.NET att inte använda den automatiskt genererade kryptografiska nyckeln. Se bilaga A för instruktioner om hur du skapar en < machineKey > element.
Lösning 3c: etablera nödvändiga HKCU registernycklar manuellt Om du inte kan köra verktyget Aspnet_regiis kan du använda ett Windows PowerShell-skript för att etablera lämpliga registernycklar i HKCU. Se bilaga B för mer information.
Upplösning 3D: Ange LoadUserProfile = True för den här programpoolen Du kan också aktivera inläsning av användarprofilen i den här programpoolen. Detta gör att HKCU-registerfilen, den temporära mappen och andra användarspecifika lagringsplatser är tillgängliga för programmet. Detta kan dock orsaka ökad disk-eller minnesanvändning för arbetsprocessen. Mer information om hur du aktiverar den här inställningen finns i elementet .

Orsak 4: egenskapen Page. ViewStateUserKey har ett felaktigt värde

Programvaruutvecklare kan välja att använda egenskapen Page. ViewStateUserKey för att lägga till skydd för begäran av Cross-Site-förfalskning i fältet _ "ViewState". Om du använder egenskapen Page. ViewStateUserKey anges den vanligtvis till ett värde som den aktuella användarens användarnamn eller användarens sessions-ID. Projektmallarna för WebForms-program i Microsoft Visual Studio 2012 och senare versioner innehåller exempel som använder den här egenskapen. Mer information finns i egenskapsavsnittet Page. ViewStateUserKey på webbplatsen Microsoft Developer Network (MSDN). Om egenskapen ViewStateUserKey har angetts, bränns dess värde i "_" ViewState vid generations tiden. När fältet ' _ VIEWSTATE ' är förbrukat kontrollerar servern den aktuella sidans ViewStateUserKey -egenskap och validerar den mot det värde som användes för att generera fältet _ "ViewState". Om värdena inte matchar avvisas begäran som potentiellt skadlig. Ett exempel på ett ViewStateUserKey-relaterat fel skulle vara en klient som har två flikar öppna i webbläsaren. Klienten är inloggad som användare A, och på den första fliken återges en sida med en _ _ VIEWSTATE vars ViewStateUserKey egenskapen innehåller "användare a". På den andra fliken loggar klienten ut och loggar sedan in igen som användare B. Klienten går tillbaka till den första fliken och skickar formuläret. Egenskapen ViewStateUserKey kan innehålla "användare B" (eftersom det är vad klientens autentiseringscookie säger). Men fältet ' _ VIEWSTATE ' som klienten skickade innehåller "användare A". Den här matchningsfel orsakar felet.

Lösning 4a: Kontrollera att ViewStateUserKey är korrekt inställt Om ditt program använder den ViewStateUserKey egenskapen, kontrollera att egenens värde är detsamma både när Visa tillstånd genereras och när den förbrukas. Om du använder den aktuella inloggade användarens användarnamn, kontrollera att användaren fortfarande är inloggad och att användarens identitet inte har ändrats vid tidpunkten för postback. Om du använder den aktuella användarens sessions-ID, kontrollera att sessionen inte har timeout. Om du kör i en servergruppmiljö, kontrollera att den < machineKey > element matchar. Se bilaga A för instruktioner om hur du skapar dessa element.

Bilaga A: så här skapar du en < machineKey > element

Säkerhetsvarning Det finns många webbplatser som kommer att generera en < machineKey > element för dig med ett klick på en knapp. Använd aldrig ett < machineKey-> element som du har hämtat från någon av dessa platser. Det är omöjligt att veta om dessa nycklar har skapats på ett säkert sätt eller om de registreras till en hemlig databas. Du bör bara använda < machineKey > konfigurationselement som du själv har skapat.

Om du vill skapa en < machineKey > elementet själv kan du använda följande Windows PowerShell -skript:

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

För ASP.NET 4,0 program, kan du bara anropa generate-machineKey utan parametrar för att generera en < machinekey > element enligt följande:

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

ASP.NET 2,0 och 3,5-program stöder inte HMACSHA256. I stället kan du ange SHA1 för att generera en kompatibel < machineKey > element på följande sätt:

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

Så snart du har en < machineKey > element, kan du placera den i Web. config-filen. Elementet < machineKey > är endast giltigt i filen Web. config i roten på ditt program och är inte giltigt på undermappsnivå.

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

En fullständig lista över algoritmer som stöds kör Hjälp generera MachineKey från Windows PowerShell-prompten.

Bilaga B: etablera registret för att spara automatiskt genererade nycklar

Som standard eftersom ASP. NETs automatiskt genererade nycklar sparas i registret HKCU, kan dessa nycklar förloras om användarprofilen inte har lästs in i IIS-arbetsprocessen och sedan återvinner programpoolen. Det här scenariot kan påverka delade värdleverantörer som kör programpooler som standard Windows-användarkonton. Undvik den här situationen genom ASP.NET kan spara automatiskt genererade nycklar i HKLM-registret i stället för HKCU-registret. Detta utförs vanligtvis med hjälp av verktyget Aspnet_regiis (se instruktioner i avsnittet "lösning 2a: Använd verktyget Aspnet_regiis"). Men för administratörer som inte vill köra det här verktyget kan följande Windows PowerShell -skript användas i stället:

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

I följande exempel visas hur du etablerar lämpliga HKLM-registerposter för en programpool som körs som användare, example@contoso.com (detta är UPN-namnet för Windows-användarkontot). Den här programpoolen är en 32-bitars programpool som kör CLR v 2.0 (ASP.NET 2,0 eller 3,5).

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

Om programpoolen i stället är en 64-bitars programpool som kör CLR v 4.0 (ASP.NET 4,0 eller 4,5) är kommandot följande:

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

Även om de automatiskt genererade nycklarna lagras i HKLM, läggs registerundernyckeln som innehåller varje användarkontos hemliga kryptografiska material till i en åtkomstkontrollista (ACL) så att det kryptografiska materialet inte kan läsas av andra användarkonton.

Bilaga C: kryptera < machineKey > elementet i konfigurationsfilerna

Server administratörer kanske inte vill ha mycket känslig information, till exempel < machineKey > nyckelmaterial till Bein klartext form i konfigurationsfiler. Om så är fallet kan administratörer välja att utnyttja en .NET Framework-funktion som kallas "skyddad konfiguration". Med den här funktionen kan du kryptera vissa delar av. config-filerna. Om innehållet i dessa konfigurationsfiler någonsin avslöjas, kommer dessa avsnitt innehåll fortfarande hemlig. Du hittar en kort översikt över skyddad konfiguration på MSDN-webbplatsen. Den innehåller också en handledning om hur du skyddar < connectionStrings > och < machineKey > element i filen Web. config.