Rešavanje grešaka koda za potvrdu identiteta (MAC) poruke o stanju prikaza

Šta je to stanje prikaza?

Stanje prikaza je informacija koja se zaobilazi između WebForms (.aspx) stranica u ASP.NET aplikaciji. HTML naznaka za __VIEWSTATE polje podseća na sledeće:

<input tipe ="skriveno" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
Jedan primer stavke koja može biti uskladištena u polju __VIEWSTATE je tekst kontrole dugmeta. Ako korisnik klikne na dugme, Button_Click rukovalac događajem će moći da izdvoji tekst dugmeta iz polja "Stanje prikaza". Pogledajte temu ASP.NET Pregled stanja prikaza na veb lokaciji Microsoft Developer Network (MSDN) da biste dobili detaljniji pregled stanja prikaza ASP.NET.

Pošto __VIEWSTATE polje sadrži važne informacije koje se koriste za rekonstrukciju stranice o postback-u, uverite se da napadač ne može neovlašćeno izmeniti ovo polje. Ako je napadač prosledio zlonamerni __VIEWSTATE korisni teret, on bi potencijalno mogao prevariti aplikaciju da izvrši radnju koju inače ne bi izvršio.

Da bi se sprečila ova vrsta neovlašćenog napada, __VIEWSTATE polje je zaštićeno kodom za potvrdu identiteta poruka (MAC). ASP.NET proverava MAC koji je prosleđen zajedno sa __VIEWSTATE korisnim teretom kada dođe do naknadnog objavljivanja. Ključ koji se koristi za izračunavanje MAC kóda naveden je u elementu aplikacije u Web.config datoteci. Pošto napadač ne može da pogodi sadržaj elementa <machineKei> , napadač ne može da obezbedi važeći MAC ako napadač pokuša da neovlašćeno menja __VIEWSTATE korisni teret. ASP.NET će otkriti da važeći MAC nije obezbeđen i ASP.NET će odbiti zlonamerni zahtev.

Šta uzrokuje greške u validaciji MAC uređaja?

Greška u validaciji MAC izgleda kao u sledećem primeru:

1. uzrok: Veb aplikacija je pokrenuta na farmi (u okruženju sa više servera)

ASP.NET automatski generiše kriptografski ključ za svaku aplikaciju i čuva ga u košnici registratora HKCU. Ovaj automatski generisan ključ se koristi ako nema eksplicitnog <elementa machineKey> u konfiguraciji aplikacije. Međutim, pošto je ovaj automatski generisani ključ lokalno na računaru koji je kreirao ključ, ovaj scenario stvara problem za aplikacije koje se pokreću na farmi. Svaki server na farmi će generisati sopstveni lokalni ključ i nijedan server na farmi se neće složiti koji ključ da koristi. Rezultat toga je: ako jedan server generiše __VIEWSTATE korisni teret koji koristi drugi server, potrošač će naići na neuspešnu proveru valjanosti MAC adresa.

• Rezolucija 1a: Kreirajte eksplicitni <machineKey> element

  Dodavanjem eksplicitnog <machineKey> elementa u Web.config datoteku aplikacije, projektant ASP.NET govori da ne koriste automatski generisani kriptografski ključ. Pogledajte Dodatak A za uputstva o tome kako da generišete element>.< Kada se ovaj element doda u Web.config datoteku, ponovo primenite aplikaciju na svaki server na farmi.

  Napomena: Neke usluge veb hostinga, kao što su Microsoft Azure veb lokacije, preduzimaju korake za sinhronizaciju automatski generisanog ključa svake aplikacije na pozadinskim serverima. To omogućava aplikacijama koje nisu navele eksplicitni <element machineKey> da nastave sa radom u tim okruženjima, čak i ako je aplikacija pokrenuta na farmi. Ako je vaša aplikacija pokrenuta u usluzi hostinga nezavisnog proizvođača, obratite se dobavljaču usluge hostinga da biste utvrdili da li se ova situacija odnosi na vas.

• Rezolucija 1b: Omogućite affinity u balanseru opterećenja

  Ako sajtovi rade iza balansera opterećenja, možete da omogućite afinitet servera da biste privremeno rešili problem. Time se obezbeđuje da svaki klijent stupi u interakciju samo sa jednim fizičkim serverom iza balansera opterećenja, tako da isti server generiše i troši sva kriptografska korisnih opterećenja.

  To ne treba smatrati dugoročnim rešenjem problema. Čak i kada je omogućen afinitet servera, većina balansera opterećenja će preusmeriti klijenta na drugi fizički server ako se isključi prvobitni server na koji su raspoređivači opterećenja povezani. Zbog toga novi server odbija kriptografske korisni teret (kao što su __VIEWSTATE, obrasci, karte za potvrdu identiteta, MVC-ovi, tokeni protiv falsifikovanja i druge usluge) koje klijent trenutno poseduje.

  Korišćenje eksplicitnog <elementa machineKey> i ponovna primena aplikacije trebalo bi da imaju prednost u odnosu na omogućavanje afiniteta servera.

2. uzrok: Radni proces koristi identitet radnog prostora aplikacije usluge IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) uveo je identitet grupe aplikacija, novi mehanizam izolacije koji pomaže u pružanju povećane bezbednosti serverima koji rade na ASP.NET aplikacijama. Međutim, sajtovi koji se izvršavaju u okviru identiteta radnog prostora nemaju pristup HKCU registratoru. Ovde ASP.NET runtime skladišti automatski generisane <ključeve machineKey> . Rezultat je da ASP.NET ne može da zadrži automatski generisan ključ kada se uspostavi početno stanje prostora aplikacija. Stoga, svaki put kada se w3wp.exe resetuje, generiše se novi privremeni ključ.

Napomena: To nije problem u IIS 7.5 (Windows 7, Windows Server 2008 R2) i novijim verzijama. U ovim verzijama IIS-a ASP.NET može da zadrži svoje automatski generisane ključeve na drugoj lokaciji koja preživi uspostavljanje početnih vrednosti prostora aplikacija.

• Rezolucija 2a: Koristite uslužni program aspnet_regiis

  ASP.NET instalacije sadrže uslužni program aspnet_regiis.exe. Ovaj uslužni program omogućava ASP.NET interfejs sa IIS-om radi izvršavanja konfiguracija potrebnih za pokretanje kontrolisane aplikacije. Jedna od ovih konfiguracija kreira neophodne ključeve u košnici registratora kako bi se omogućila trajnost automatski generisanih ključeva mašine.

  Prvo morate da utvrdite koju grupu aplikacija koristi vaša lokacija. To se može utvrditi pomoću uslužnog programa inetmgr koji je uključen uz IIS. Izaberite sajt u prikazu stabla sa leve strane, kliknite desnim tasterom miša na dugme "Upravljaj vebom", a zatim izaberite stavku "Napredne postavke". Dijalog koji se pojavljuje prikazaće ime grupe aplikacija.

  

  Da biste kreirali odgovarajuće ključeve registratora za ASP.NET 4.0 grupu aplikacija, pratite ove korake:

  1. Otvorite administratorsku komandnu liniju.

  2. Pronađite odgovarajući direktorijum, u zavisnosti od toga da li je grupa aplikacija 32-bitna ili 64-bitna:

     • 32-bitna grupa aplikacija: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • 64-bitna grupa aplikacija: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. Premestite se u direktorijum, otkucajte sledeću komandu, a zatim pritisnite taster Enter:

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

  Ako je grupa aplikacija ASP.NET 2.0 ili 3.5, sledite ove korake:

  1. Otvorite administratorsku komandnu liniju.

  2. Pronađite odgovarajući direktorijum, u zavisnosti od toga da li je grupa aplikacija 32-bitna ili 64-bitna:

     • 32-bitna grupa aplikacija: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • 64-bitna grupa aplikacija: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. Premestite se u direktorijum, otkucajte sledeću komandu, a zatim pritisnite taster Enter:

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

  Na primer, ako se grupa aplikacija zove "Moje grupljanje aplikacija" (kao na prethodnoj slici), pokrenite sledeću komandu:
   
  aspnet_regiis -ga "IIS APPPOOL\My App Pool"

  Napomena: sistemske usluge APPHOSTSVC i WAS možda moraju biti pokrenute da bi uslužni program aspnet_regiis rešio IIS APPPOOL\* imena na odgovarajući način.

• Rezolucija 2b: Kreiranje eksplicitnog <elementa machineKey>

  Dodavanjem eksplicitnog <machineKey> elementa u Web.config datoteku aplikacije, projektant ASP.NET govori da ne koriste automatski generisani kriptografski ključ. Pogledajte Dodatak A za uputstva o tome kako da generišete element>.<

3. uzrok: Grupa aplikacija je konfigurisana pomoću LoadUserProfile=false

Ako je grupa aplikacija pokrenuta sa prilagođenim identitetom, IIS možda nije učitao korisnički profil za identitet. To ima sporedni efekat toga što HKCU registar postaje nedostupan za ASP.NET da biste zadržali automatski generisani <machineKey>. Zato će se novi automatski generisan ključ kreirati svaki put kada se aplikacija ponovo pokrene. Više informacija potražite u odeljku "Korisnički profil " na Microsoft veb lokaciji.

• Rezolucija 3a: Koristite uslužni program aspnet_regiis

  Uputstva za ovo su ista kao u Rezoluciji 2a. Više informacija potražite u tom odeljku.

• Rezolucija 3b: Korišćenje eksplicitne <mašineKljuč>

  Dodavanjem eksplicitnog <machineKey> elementa u Web.config datoteku aplikacije, projektant ASP.NET govori da ne koriste automatski generisani kriptografski ključ. Pogledajte Dodatak A za uputstva o tome kako da generišete element>.<

• Rešenje 3c: Ručno obezbeđivanje potrebnih HKCU ključeva registratora

  Ako ne možete da pokrenete aspnet_regiis uslužni program, možete da koristite Windows PowerShell skriptu da biste obezbedili odgovarajuće ključeve registratora u HKCU-u. Pogledajte Dodatak B za više informacija.

• Rezolucija 3D: Postavite LoadUserProfile=true za ovu grupu aplikacija

  Takođe možete da omogućite učitavanje korisničkog profila unutar ove grupe aplikacija. Na ovaj način će aplikacija učiniti dostupnom košnicu HKCU registratora, privremenu fasciklu i druge lokacije za skladištenje specifične za korisnika. Međutim, to može da dovede do povećane upotrebe diska ili memorije za radni proces. Pogledajte element za više informacija o tome kako da omogućite ovu postavku.

4. uzrok: Svojstvo Page.ViewStateUserKey ima netačnu vrednost

Projektanti softvera mogu da odluče da koriste svojstvo Page.ViewStateUserKey da bi dodali zaštitu od falsifikovanja zahteva na više lokacija u polje za __VIEWSTATE. Ako koristite svojstvo Page.ViewStateUserKey, ono se obično postavlja na vrednost kao što je korisničko ime trenutnog korisnika ili identifikator sesije korisnika. Predlošci projekta za WebForms aplikacije u programu Microsoft Visual Studio 2012 i novijim verzijama sadrže uzorke koji koriste ovo svojstvo. Više informacija potražite u temi "Svojstvo Page.ViewStateUserKey " na veb sajtu Microsoft Developer Network (MSDN)".

Ako je navedeno svojstvo ViewStateUserKey, njegova vrednost se spaljuje u __VIEWSTATE u vreme generisanja. Kada se __VIEWSTATE polje potroši, server proverava svojstvo ViewStateUserKey trenutne stranice i proverava njegovu valjanost u odnosu na vrednost koja je korišćena za generisanje __VIEWSTATE polja. Ako se vrednosti ne podudaraju, zahtev se odbija kao potencijalno zlonameran.

Primer otkazivanja povezanog sa ViewStateUserKey-om bi bio klijent koji ima dve otvorene kartice u pregledaču. Klijent je prijavljen kao korisnik A, a na prvoj kartici se prikazuje stranica sa __VIEWSTATE čije svojstvo ViewStateUserKey sadrži "Korisnik A". Na drugoj kartici klijent se odjavljuje, a zatim ponovo prijavljuje kao korisnik B. Klijent se vraća na prvu karticu i prosleđuje obrazac. Svojstvo ViewStateUserKey može da sadrži "Korisnik B" (zato što to kaže kolačić za potvrdu identiteta klijenta). Međutim, __VIEWSTATE polje koje je prosledio klijent sadrži "Korisnik A". Ova nepodudaranja uzrokuje neuspeh.

• Rešenje 4a: Proverite da li je ispravno podešena postavka ViewStateUserKey

  Ako aplikacija koristi svojstvo ViewStateUserKey, potvrdite da je vrednost svojstva ista i kada se generiše stanje prikaza i kada se konzumira. Ako koristite korisničko ime korisnika koji je trenutno prijavljen, uverite se da je korisnik još uvek prijavljen i da se identitet korisnika nije promenio u trenutku objavljivanja. Ako koristite identifikator sesije trenutnog korisnika, uverite se da sesija nije istekla.

  Ako radite u okruženju farme, uverite se da se elementi <machineKey> podudaraju. Uputstva o tome kako da generišete ove elemente potražite u Dodatku A .

          

Dodatak A: Kako generisati <element machineKey>

        
Da biste sami generisali <element machineKey>, možete da koristite sledeću skriptu programa 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)
  }
}

Za ASP.NET 4.0 aplikacije možete jednostavno da pozovete Generate-MachineKey bez parametara da biste generisali <element machineKey> na sledeći način:

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

ASP.NET 2.0 i 3.5 aplikacije ne podržavaju HMACSHA256. Umesto toga, možete da navedete SHA1 da biste generisali kompatibilan <element machineKey> na sledeći način:

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

Čim imate <element machineKey> , možete da ga stavite u Web.config datoteku. Element <machineKey> je važeći samo u datoteci Web.config u osnovi aplikacije, a nije važeći na nivou potfascikle.

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

Za kompletnu listu podržanih algoritama pokrenite Generate-MachineKey pomoći iz Windows PowerShell upita.

Dodatak B: Obezbeđivanje registratora za zadržavanje automatski generisanih ključeva

Prema podrazumevanim postavkama, zato što ASP. Automatski generisani NEN ključevi su trajni u HKCU registratoru, ovi ključevi mogu biti izgubljeni ako korisnički profil nije učitan u IIS radni proces, a zatim se grupa aplikacija reciklira. Ovaj scenario može da utiče na dobavljače deljenog hostinga koji koriste grupe aplikacija kao standardne Windows korisničke naloge.

Da biste rešili ovu situaciju, ASP.NET omogućava zadržavanje automatski generisanih ključeva u HKLM registratoru umesto u HKCU registratoru. Ovo se obično izvršava pomoću uslužnog programa za aspnet_regiis (pogledajte uputstva u odeljku "Rešenje 2a: Koristite uslužni program za aspnet_regiis"). Međutim, za administratore koji ne žele da pokrenu ovaj uslužni program, umesto nje može da se koristi sledeća Windows PowerShell skripta:

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

Sledeći primer pokazuje kako da obezbedite odgovarajuće stavke HKLM registratora za grupu aplikacija koja radi kao korisnik example@contoso.com (ovo je UPN Windows korisničkog naloga). Ova grupa aplikacija je 32-bitna grupa aplikacija koja pokreće CLR v2.0 (ASP.NET 2.0 ili 3.5).

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

Ako je grupa aplikacija umesto toga 64-bitna grupa aplikacija koja koristi CLR v4.0 (ASP.NET 4.0 ili 4.5), komanda glasi ovako:

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

Iako su automatski generisani ključevi uskladišteni u HKLM-u, potključ registra koji sadrži tajni kriptografski materijal svakog korisničkog naloga dodaje se na listu za kontrolu pristupa (ACL) tako da drugi korisnički nalozi ne mogu čitati kriptografski materijal.

Dodatak C: Šifrovanje elementa <machineKey> u konfiguracionim datotekama

Administratori servera možda ne žele da veoma osetljive informacije, kao što je materijal ključa machineKey <,> budu u obliku čistog teksta u konfiguracionim datotekama. Ako je to slučaj, administratori mogu da odluče da iskoriste pogodnost funkcije .NET Framework poznate kao "zaštićena konfiguracija". Ova funkcija vam omogućava da šifrujete određene odeljke .config datoteka. Ako se sadržaj ovih datoteka za konfiguraciju ikada otkrije, sadržaj tih odeljaka i dalje će ostati tajan.

Kratak pregled zaštićenih konfiguracija možete da pronađete na MSDN veb lokaciji. Takođe sadrži tutorijal o tome kako da zaštitite elemente connectionStrings <> i <machineKey> Web.config datoteke.