Rozwiązywanie problemów z kodem uwierzytelniania wiadomości o stanie widoku (MAC)

Co to jest stan widoku?

Stan widoku to informacje wyzwalane w zaokrągleniu między stronami formularzy sieci Web (.aspx) w aplikacji ASP.NET. Znaczniki HTML dla pola __VIEWSTATE są podobne do poniższych:

<typ wejścia="ukryty" nazwa="__VIEWSTATE" id="__VIEWSTATE" wartość="..." />
Przykładem elementu, który może być przechowywany w polu __VIEWSTATE, jest tekst kontrolki Przycisk. Jeśli użytkownik kliknie przycisk, program obsługi zdarzeń Button_Click będzie mógł wyodrębnić tekst przycisku z pola stanu widoku. Znacznie bardziej szczegółowe omówienie stanu widoku ASP.NET ASP.NET można znaleźć w witrynie sieci Microsoft Developer Network (MSDN) w sieci Web.

Ponieważ pole __VIEWSTATE zawiera ważne informacje, które są używane do odtworzenia strony przy ogłaszaniu zwrotnym, upewnij się, że osoba atakująca nie może manipulować tym polem. Jeśli osoba atakująca prześle ładunek złośliwego __VIEWSTATE, osoba atakująca może potencjalnie nakłonić aplikację do wykonania akcji, której w przeciwnym razie by nie wykonała.

Aby zapobiec tego rodzaju atakom manipulacyjnym, pole __VIEWSTATE jest chronione za pomocą kodu uwierzytelniania wiadomości (MAC). ASP.NET sprawdza poprawność adresu MAC przesyłanego wraz z ładunkiem __VIEWSTATE, gdy wystąpi ogłoszenie zwrotne. Klucz używany do obliczania adresu MAC jest określony w elemencie aplikacji w pliku Web.config. Ponieważ osoba atakująca nie może odgadnąć zawartości <elementu machineKey> , osoba atakująca nie może podać prawidłowego adresu MAC, jeśli spróbuje manipulować ładunkiem __VIEWSTATE. ASP.NET wykryje, że nie podano prawidłowego adresu MAC, a ASP.NET odrzuci złośliwe żądanie.

Co powoduje błędy walidacji adresów MAC?

Błąd walidacji MAC będzie podobny do następującego przykładu:

Przyczyna 1: Aplikacja sieci Web jest uruchomiona na farmie (środowisko z wieloma serwerami)

ASP.NET automatycznie generuje klucz kryptograficzny dla każdej aplikacji i przechowuje go w gałęzi rejestru HKCU. Ten automatycznie wygenerowany klucz jest używany, jeśli w konfiguracji aplikacji nie ma jawnego <elementu machineKey> . Jednak ponieważ ten automatycznie wygenerowany klucz jest lokalny dla komputera, który go utworzył, ten scenariusz powoduje problem dla aplikacji uruchomionych w farmie. Każdy serwer w farmie wygeneruje własny klucz lokalny i żaden z serwerów w farmie nie uzgadnia klucza, którego należy użyć. W rezultacie, jeśli jeden serwer generuje ładunek __VIEWSTATE, który jest używany przez inny serwer, konsument doświadczy niepowodzenia walidacji adresu MAC.

• Rozwiązanie 1a: Utwórz jawny <element machineKey>

  Dodając jawny <element machineKey> do pliku Web.config aplikacji, deweloper informuje ASP.NET, aby nie używał automatycznie wygenerowanego klucza kryptograficznego. Zobacz Dodatek A, aby uzyskać instrukcje dotyczące generowania <elementu machineKey>. Po dodaniu tego elementu do pliku Web.config ponownie wdróż aplikację na każdym serwerze w farmie.

  Uwaga Niektóre internetowe usługi hostingowe, takie jak witryny internetowe Microsoft Azure, podejmują kroki w celu synchronizowania automatycznie wygenerowanego klucza każdej aplikacji na serwerach zaplecza. Dzięki temu aplikacje, które nie określiły jawnego <elementu machineKey> , mogą kontynuować pracę w tych środowiskach, nawet jeśli aplikacja jest uruchomiona w farmie. Jeśli Twoja aplikacja działa w usłudze hostingu innej firmy, skontaktuj się z dostawcą hostingu, aby ustalić, czy ta sytuacja dotyczy Ciebie.

• Rozwiązanie 1b: Włączanie koligacji w module równoważenia obciążenia

  Jeśli witryny działają za modułem równoważenia obciążenia, można włączyć koligację serwera, aby tymczasowo obejść ten problem. Pomaga to zapewnić, że dany klient wchodzi w interakcję tylko z jednym serwerem fizycznym za modułem równoważenia obciążenia, tak aby wszystkie ładunki kryptograficzne były generowane i używane przez ten sam serwer.

  Nie należy tego uważać za długoterminowe rozwiązanie problemu. Nawet jeśli koligacja serwera jest włączona, większość modułów równoważenia obciążenia przekieruje klienta do innego serwera fizycznego, jeśli oryginalny serwer, z którym zostały powiązane moduły równoważenia obciążenia, przejdzie w tryb offline. Powoduje to, że nowy serwer odrzuca ładunki kryptograficzne (takie jak __VIEWSTATE, bilety uwierzytelniania formularzy, MVC, tokeny zabezpieczające przed fałszerstwem i inne usługi) posiadane obecnie przez klienta.

  Użycie jawnego <elementu machineKey> i ponowne wdrożenie aplikacji powinno być preferowane przed włączeniem koligacji serwera.

Przyczyna 2: Proces roboczy używa tożsamości puli aplikacji usług IIS 7.0

W programie Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) wprowadzono tożsamość puli aplikacji, nowy mechanizm izolacji, który pomaga zwiększyć bezpieczeństwo serwerów z uruchomionymi ASP.NET aplikacjami. Jednak witryny uruchomione w ramach tożsamości puli aplikacji nie mają dostępu do rejestru HONGCU. W tym miejscu środowisko uruchomieniowe ASP.NET przechowuje automatycznie wygenerowane <klucze machineKey> . W wyniku tego nie ASP.NET można utrwalić automatycznie wygenerowanego klucza po zresetowaniu puli aplikacji. Dlatego po każdym zresetowaniu w3wp.exe generowany jest nowy klucz tymczasowy.

Uwaga Nie jest to problem programu IIS 7.5 (Windows 7, Windows Server 2008 R2) i nowszych wersji. W tych wersjach usług IIS ASP.NET może utrwalać klucze wygenerowane automatycznie w innej lokalizacji, która przetrwa resetowanie puli aplikacji.

• Rozwiązanie 2a: Użycie narzędzia aspnet_regiis

  ASP.NET instalacje zawierają narzędzie, aspnet_regiis.exe. To narzędzie umożliwia ASP.NET interfejsu z usługami IIS w celu wykonania konfiguracji wymaganych do uruchomienia aplikacji zarządzanej. Jedna z tych konfiguracji tworzy niezbędne klucze w gałęzi rejestru, aby umożliwić utrwalanie kluczy maszynowych wygenerowanych automatycznie.

  Najpierw musisz określić, z której puli aplikacji korzysta Twoja witryna. Można to ustalić przy użyciu narzędzia inetmgr dołączonego do programu IIS. Wybierz swoją witrynę w widoku drzewa po lewej stronie, kliknij prawym przyciskiem myszy pozycję Zarządzaj witrynąinternetową, a następnie kliknij pozycję Ustawienia zaawansowane. W wyświetlonym oknie dialogowym zostanie wyświetlona nazwa puli aplikacji.

  

  Aby utworzyć szkielety odpowiednie klucze rejestru dla puli aplikacji ASP.NET 4.0, wykonaj następujące kroki:

  1. Otwórz administracyjny wiersz polecenia.

  2. Znajdź odpowiedni katalog w zależności od tego, czy pula aplikacji jest 32-bitowa, czy 64-bitowa:

     • Pula aplikacji 32-bitowych: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • Pula aplikacji 64-bitowych: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. Przejdź do katalogu, wpisz następujące polecenie, a następnie naciśnij klawisz Enter:

     aspnet_regiis -ga "IIS APPPOOL\nazwa-puli-aplikacji"

  Jeśli pula aplikacji jest pulą aplikacji ASP.NET 2.0 lub 3.5, wykonaj następujące kroki:

  1. Otwórz administracyjny wiersz polecenia.

  2. Znajdź odpowiedni katalog w zależności od tego, czy pula aplikacji jest 32-bitowa, czy 64-bitowa:

     • 32-bitowa pula aplikacji: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • Pula aplikacji 64-bitowych: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. Przejdź do katalogu, wpisz następujące polecenie, a następnie naciśnij klawisz Enter:

     aspnet_regiis -ga "IIS APPPOOL\nazwa-puli-aplikacji"

  Jeśli na przykład pula aplikacji ma nazwę Moja pula aplikacji (jak na poprzednim obrazie), uruchom następujące polecenie:
   
  aspnet_regiis -ga "IIS APPPOOL\Moja pula aplikacji"

  Uwaga Możliwe, że usługi systemowe APPHOSTSVC i WAS muszą być uruchomione, aby narzędzie aspnet_regiis mogło prawidłowo rozpoznać nazwy IIS APPPOOL\*.

• Rozwiązanie 2b: Utwórz jawną <maszynęKey> element

  Dodając jawny <element machineKey> do pliku Web.config aplikacji, deweloper informuje ASP.NET, aby nie używał automatycznie wygenerowanego klucza kryptograficznego. Zobacz Dodatek A, aby uzyskać instrukcje dotyczące generowania <elementu machineKey>.

Przyczyna 3: Pula aplikacji jest skonfigurowana za pomocą polecenia LoadUserProfile=false

Jeśli pula aplikacji jest uruchomiona z tożsamością niestandardową, być może IIS nie załadował profilu użytkownika dla tej tożsamości. Ma to efekt uboczny w postaci niedostępności rejestru HKCU dla ASP.NET w celu zachowania automatycznie wygenerowanego <klucza machineKey>. W związku z tym po każdym ponownym uruchomieniu aplikacji zostanie utworzony nowy klucz wygenerowany automatycznie. Więcej informacji na ten temat można znaleźć w sekcji Profil użytkownika w witrynie internetowej firmy Microsoft.

• Rozwiązanie 3a: Użycie narzędzia aspnet_regiis

  Instrukcje są takie same jak w rezolucji 2a. Więcej informacji można znaleźć w tej sekcji.

• Rozwiązanie 3b: Użyj jawnego <klucza komputera>

  Dodając jawny <element machineKey> do pliku Web.config aplikacji, deweloper informuje ASP.NET, aby nie używał automatycznie wygenerowanego klucza kryptograficznego. Zobacz Dodatek A, aby uzyskać instrukcje dotyczące generowania <elementu machineKey>.

• Rozwiązanie 3c: Ręczne aprowizowanie wymaganych kluczy rejestru HKCU

  Jeśli nie można uruchomić narzędzia aspnet_regiis, można użyć skryptu Windows PowerShell w celu zapewnienia obsługi odpowiednich kluczy rejestru w gałęzi HKCU. Więcej informacji można znaleźć w dodatku B .

• Rozwiązanie 3d: Ustaw LoadUserProfile=true dla tej puli aplikacji

  Można również włączyć ładowanie profilu użytkownika w tej puli aplikacji. Dzięki temu gałąź rejestru HKCU, folder tymczasowy i inne specyficzne dla użytkownika lokalizacje przechowywania będą dostępne dla aplikacji. Może to jednak spowodować zwiększone użycie dysku lub pamięci przez proces roboczy. Aby uzyskać więcej informacji na temat włączania tego ustawienia, zobacz ten element .

Przyczyna 4: Właściwość Page.ViewStateUserKey ma nieprawidłową wartość

Deweloperzy oprogramowania mogą zdecydować się na użycie właściwości Page.ViewStateUserKey w celu dodania ochrony przed fałszowaniem żądań między witrynami do pola __VIEWSTATE. Jeśli używasz właściwości Page.ViewStateUserKey, zwykle jest ona ustawiana na wartość, taką jak nazwa użytkownika bieżącego użytkownika lub identyfikator sesji użytkownika. Szablony projektów dla aplikacji WebForms w programie Microsoft Visual Studio 2012 i nowszych wersjach zawierają przykłady używające tej właściwości. Aby uzyskać więcej informacji, zobacz temat właściwości Page.ViewStateUserKey w witrynie sieci Microsoft Developer Network (MSDN).

Jeśli właściwość ViewStateUserKey jest określona, jej wartość jest zapisywana w __VIEWSTATE w czasie generowania. Gdy pole __VIEWSTATE jest używane, serwer sprawdza właściwość ViewStateUserKey bieżącej strony i weryfikuje ją pod kątem wartości, która została użyta do wygenerowania pola __VIEWSTATE. Jeśli wartości nie są zgodne, żądanie jest odrzucane jako potencjalnie złośliwe.

Przykładem błędu związanego z kluczem ViewStateUserKey może być klient, który ma otwarte dwie karty w przeglądarce. Klient jest zalogowany jako użytkownik A, a na pierwszej karcie jest renderowana strona z __VIEWSTATE, której właściwość ViewStateUserKey zawiera wartość "Użytkownik A". Na drugiej karcie klient wylogowuje się, a następnie loguje ponownie jako użytkownik B. Klient wraca do pierwszej karty i przesyła formularz. Właściwość ViewStateUserKey może zawierać ciąg "Użytkownik B" (ponieważ tak mówi plik cookie uwierzytelniania klienta). Jednak pole __VIEWSTATE przesłane przez klienta zawiera nazwę "Użytkownik A". Ta niezgodność powoduje niepowodzenie.

• Rozwiązanie 4a: Sprawdź, czy parametr ViewStateUserKey jest poprawnie ustawiony

  Jeśli aplikacja używa właściwości ViewStateUserKey, sprawdź, czy wartość właściwości jest taka sama zarówno podczas generowania stanu widoku, jak i podczas jego używania. Jeśli używasz nazwy użytkownika bieżącego zalogowanego użytkownika, upewnij się, że użytkownik jest nadal zalogowany i że jego tożsamość nie zmieniła się w momencie ogłaszania zwrotnego. Jeśli używasz identyfikatora sesji bieżącego użytkownika, upewnij się, że nie upłynął limit czasu sesji.

  Jeśli korzystasz ze środowiska farmy, upewnij się, że <elementy machineKey> są zgodne. Zobacz Dodatek A, aby uzyskać instrukcje dotyczące generowania tych elementów.

          

Dodatek A: Jak wygenerować <element machineKey>

        
Aby samodzielnie wygenerować <element machineKey>, możesz użyć następującego skryptu programu 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)
  }
}

W przypadku aplikacji ASP.NET 4.0 możesz po prostu wywołać Generate-MachineKey bez parametrów, aby wygenerować <element machineKey> w następujący sposób:

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

Aplikacje ASP.NET 2.0 i 3.5 nie obsługują HMACSHA256. Zamiast tego można określić algorytm SHA1, aby wygenerować zgodny <element machineKey> w następujący sposób:

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

Gdy tylko masz <element machineKey> , możesz umieścić go w pliku Web.config. Element <machineKey> jest prawidłowy tylko w pliku Web.config w katalogu głównym aplikacji i nie jest prawidłowy na poziomie podfolderu.

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

Aby uzyskać pełną listę obsługiwanych algorytmów, uruchom Generate-MachineKey pomocy z poziomu monitu Windows PowerShell.

Dodatek B: Inicjowanie obsługi rejestru w celu utrwalenia kluczy wygenerowanych automatycznie

Domyślnie, ponieważ środowisko ASP. Klucze wygenerowane automatycznie w sieciach NET są utrwalane w rejestrze HKCU, te klucze mogą zostać utracone, jeśli profil użytkownika nie został załadowany do procesu roboczego usług IIS, a następnie pula aplikacji zostanie ponownie uruchomiona. Ten scenariusz może mieć wpływ na dostawców hostingu udostępnionego, którzy korzystają z pul aplikacji jako standardowych kont użytkowników systemu Windows.

Aby obejść tę sytuację, ASP.NET umożliwia utrwalanie kluczy wygenerowanych automatycznie w rejestrze HKLM zamiast w rejestrze HONGCU. Zazwyczaj wykonuje się to za pomocą narzędzia aspnet_regiis (zobacz instrukcje w sekcji "Rozwiązanie 2a: użycie narzędzia aspnet_regiis"). Administratorzy, którzy nie chcą uruchamiać tego narzędzia, mogą jednak użyć następującego skryptu programu 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)
    }
  }
}

W poniższym przykładzie pokazano, jak zainicjować obsługę odpowiednich wpisów rejestru HKLM dla puli aplikacji działającej jako użytkownik example@contoso.com (jest to główna nazwa użytkownika konta użytkownika systemu Windows). Ta pula aplikacji to 32-bitowa pula aplikacji uruchomiona w środowisku CLR w wersji 2.0 (ASP.NET 2.0 lub 3.5).

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

Jeśli natomiast pula aplikacji jest 64-bitową pulą aplikacji uruchomioną w środowisku CLR w wersji 4.0 (ASP.NET 4.0 lub 4.5), polecenie jest następujące:

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

Mimo że klucze wygenerowane automatycznie są przechowywane w HKLM, podklucz rejestru, który przechowuje tajny materiał kryptograficzny każdego konta użytkownika, jest dodawany do listy kontroli dostępu (ACL), aby materiał kryptograficzny nie mógł być odczytywany przez inne konta użytkowników.

Dodatek C: Szyfrowanie <elementu machineKey> w plikach konfiguracyjnych

Administratorzy serwerów mogą nie chcieć, aby wysoce poufne informacje, takie jak materiał klucza <machineKey> , znajdowały się w postaci zwykłego tekstu w plikach konfiguracyjnych. W takim przypadku administratorzy mogą zdecydować się na skorzystanie z funkcji programu .NET Framework zwanej "konfiguracją chronioną". Ta funkcja umożliwia szyfrowanie pewnych sekcji plików .config. Jeśli zawartość tych plików konfiguracyjnych zostanie kiedykolwiek ujawniona, zawartość tych sekcji nadal pozostanie tajna.

Krótkie omówienie chronionej konfiguracji można znaleźć w witrynie MSDN. Zawiera również samouczek dotyczący ochrony <elementów connectionStrings> i <machineKey> pliku Web.config.