Usuwanie błędów związanych z kodami uwierzytelniania komunikatów (MAC) stanu widoku

Tłumaczenia artykułów Tłumaczenia artykułów
Numer ID artykułu: 2915218 - Zobacz jakich produktów dotyczą zawarte w tym artykule porady.
Rozwiń wszystko | Zwiń wszystko

Co to jest stan widoku?

Stan widoku to informacja wymieniana (w ramach rundy) między stronami WebForms (aspx) w aplikacji ASP.NET. Tagi HTML dla pola __VIEWSTATE przypominają następujące:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

Przykładem elementu, który może być przechowywany w polu __VIEWSTATE jest tekst kontrolki przycisku (Button). Gdy użytkownik kliknie przycisk, program obsługi zdarzenia Button_Click będzie mógł wyodrębnić tekst przycisku z pola stanu widoku. Temat z omówieniem stanu widoku platformy ASP.NET w witrynie Microsoft Developer Network (MSDN) w sieci Web zawiera więcej szczegółów.

Pole __VIEWSTATE zawiera ważne informacje używane do ponownego konstruowania strony podczas ogłaszania zwrotnego, dlatego należy zadbać o to, aby osoba atakująca nie mogła go naruszyć. Osoba atakująca, która wysłała złośliwy ładunek pola __VIEWSTATE, może spowodować, że aplikacja wykona akcję, która w innej sytuacji nie zostałaby zrealizowana.

Aby zapobiec tego rodzaju atakom z naruszeniami, pole __VIEWSTATE jest chronione za pomocą kodu uwierzytelniania komunikatów (MAC, Message Authentication Code). Platforma ASP.NET potwierdza, że podczas ogłaszania zwrotnego wraz z ładunkiem __VIEWSTATE został przesłany kod MAC. Klucz służący do obliczenia kodu MAC jest określony w elemencie <machineKey> aplikacji w pliku Web.config. Osoba atakująca nie może odgadnąć zawartości elementu <machineKey>, nie może więc podać prawidłowego kodu MAC podczas próby naruszenia ładunku __VIEWSTATE. Platforma ASP.NET wykryje, że nie podano prawidłowego kodu MAC, i odrzuci złośliwe żądanie.

Co powoduje błędy weryfikacji kodu MAC?

Błąd weryfikacji kodu MAC będzie podobny do następującego:

Błąd serwera w aplikacji „/”.

Walidacja MAC stanu widoku nie powiodła się. Jeśli ta aplikacja znajduje się na farmie lub w klastrze sieci Web, należy pamiętać, że w konfiguracji <machineKey> musi być zdefiniowany taki sam element validationKey i algorytm walidacji. Nie można używać polecenia AutoGenerate w klastrze.

Opis: Podczas wykonywania bieżącego żądania sieci Web wystąpił nieobsługiwany wyjątek. Aby uzyskać dodatkowe informacje o błędzie i miejscu jego występowania w kodzie, przejrzyj ślad stosu.

Szczegóły wyjątku: System.Web.HttpException: Walidacja MAC stanu widoku nie powiodła się. Jeśli ta aplikacja znajduje się na farmie lub w klastrze sieci Web, należy pamiętać, że w konfiguracji <machineKey> musi być zdefiniowany taki sam element validationKey i algorytm walidacji. Nie można używać polecenia AutoGenerate w klastrze.

Błąd źródła: [Brak istotnych wierszy źródłowych]

Plik źródłowy: ... Wiersz: 0

Ślad stosu:

[ViewStateException: Nieprawidłowy stan wyświetlania.
Adres IP klienta: ::1
Port: 40653
Odnośnik: http://localhost:40643/MyPage.aspx
Ścieżka: /MyPage.aspx
Użytkownik-agent: Mozilla/5.0 (zgodny; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): Walidacja MAC stanu widoku nie powiodła się. Jeśli ta aplikacja znajduje się na farmie lub w klastrze sieci Web, należy pamiętać, że w konfiguracji <machineKey> musi być zdefiniowany taki sam element validationKey i algorytm walidacji. Nie można używać polecenia AutoGenerate w klastrze.

Aby uzyskać więcej informacji, zobacz http://go.microsoft.com/fwlink/?LinkID=314055.]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +190
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +46
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +861
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +51
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +67
System.Web.UI.HiddenFieldPageStatePersister.Load() +444
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +368
System.Web.UI.Page.LoadAllState() +109
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7959
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +429
System.Web.UI.Page.ProcessRequest() +125
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +48
System.Web.UI.Page.ProcessRequest(HttpContext context) +234
ASP.mypage_aspx.ProcessRequest(HttpContext context) in ...:0
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +140

Przyczyna 1. Aplikacja sieci Web działająca w farmie (środowisko z wieloma serwerami)

Platforma ASP.NET automatycznie generuje klucze kryptograficzne dla poszczególnych aplikacji i zapisuje je w gałęzi rejestru HKCU. Wygenerowany automatycznie klucz jest używany, jeśli w konfiguracji aplikacji nie podano jawnie elementu <machineKey>. Ponieważ jednak ten wygenerowany automatycznie klucz ma charakter lokalny na komputerze, który go utworzył, ten scenariusz powoduje problem w przypadku aplikacji działających w farmie. Każdy serwer w farmie generuje własny klucz lokalny i nie są one w stanie uzgodnić, którego klucza należy używać. W wyniku tego wygenerowanie przez jeden serwer ładunku __VIEWSTATE, z którego ma skorzystać inny serwer, spowoduje na tym drugim serwerze błąd weryfikacji kodu MAC.
  • Rozwiązanie 1a. Utworzenie jawnego elementu <machineKey>

    Dodając jawny element <machineKey> do pliku Web.config aplikacji, deweloper informuje platformę ASP.NET, że nie należy używać wygenerowanego automatycznie klucza kryptograficznego. Dodatek A zawiera instrukcje dotyczące generowania elementu <machineKey>. Po dodaniu tego elementu do pliku Web.config należy ponownie wdrożyć aplikację na poszczególnych serwerach w farmie.

    Uwaga Niektóre usługi hostingu sieci Web, takie jak witryny sieci Web systemu Microsoft Azure, synchronizują wygenerowane automatycznie klucze poszczególnych aplikacji między serwerami wewnętrznymi. Dzięki temu aplikacje bez określonych jawnych elementów <machineKey> mogą nadal działać w tych środowiskach, nawet w farmach. Jeśli dana aplikacja działa w usłudze hostingu innego producenta, należy skontaktować się z nim w celu ustalenia, czy takie rozwiązanie jest używane.

  • Rozwiązanie 1b. Włączenie koligacji z usługą równoważenia obciążenia

    Jeśli witryny działają za usługą równoważenia obciążenia, można włączyć koligację serwera, aby tymczasowo obejść ten problem. Pozwala to zapewnić, że każdy klient wchodzi w interakcje z tylko jednym serwerem fizycznym za usługą równoważenia obciążenia, więc wszystkie ładunki kryptograficzne będą zarówno generowane, jak i używane przez ten sam serwer.

    Nie powinno to być uważane za długoterminowe rozwiązanie problemu. Nawet po włączeniu koligacji serwera większość usług równoważenia obciążenia przekierowuje klientów do innych serwerów fizycznych, jeśli serwery pierwotne skoligacone z tymi usługami przechodzą do trybu offline. W wyniku tego nowy serwer odrzuca bieżące ładunki kryptograficzne klienta (takie jak __VIEWSTATE, bilety uwierzytelniania formularzy, tokeny zapobiegające fałszowaniu MVC i inne usługi).

    Zastosowanie jawnego elementu <machineKey> i ponowne wdrożenie aplikacji jest lepszym rozwiązaniem niż włączenie koligacji serwera.

Przyczyna 2. Proces roboczy używa tożsamości puli aplikacji IIS 7.0

W programie Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) wprowadzono tożsamość puli aplikacji, nowy mechanizm izolacji ułatwiający zapewnianie większego bezpieczeństwa serwerów aplikacji ASP.NET. Jednak witryny działające w ramach tożsamości puli aplikacji nie mają dostępu do rejestru HKCU. W tym miejscu środowisko wykonawcze platformy ASP.NET przechowuje wygenerowane automatycznie klucze <machineKey>. Skutkiem tego platforma ASP.NET nie może utrwalić wygenerowanych automatycznie kluczy, gdy pula aplikacji zostaje zresetowana. Każde zresetowanie pliku w3wp.exe powoduje wygenerowanie nowego klucza tymczasowego.

Uwaga Nie jest to problemem w programie IIS 7.5 (Windows 7, Windows Server 2008 R2) ani w nowszych wersjach. W tych wersjach programu IIS platforma ASP.NET może utrwalać wygenerowane automatycznie klucze w innej lokalizacji, która jest zachowywana po zresetowaniu puli aplikacji.
  • Rozwiązanie 2a. Zastosowanie narzędzia aspnet_regiis

    Instalacje platformy ASP.NET zawierają narzędzie aspnet_regiis.exe. To narzędzie umożliwia platformie ASP.NET komunikację z programem IIS w celu utworzenia konfiguracji wymaganych do uruchamiania aplikacji zarządzanej. Jedna z tych konfiguracji tworzy niezbędne klucze w gałęzi rejestru w celu włączenia utrwalania wygenerowanych automatycznie kluczy komputerów.

    Najpierw należy ustalić, której puli aplikacji używa witryna. Można to zrobić za pomocą narzędzia inetmgr dołączonego do programu IIS. Po wybraniu witryny w widoku drzewa po lewej stronie należy kliknąć prawym przyciskiem myszy pozycję Zarządzaj witryną sieci Web, a następnie kliknąć polecenie Ustawienia zaawansowane. W wyświetlonym oknie dialogowym będzie podana nazwa puli aplikacji.

    Zwiń ten obrazekRozwiń ten obrazek
    Ustawienia zaawansowane


    Aby wstępnie utworzyć odpowiednie klucze rejestru dla puli aplikacji ASP.NET 4.0, wykonaj następujące czynności:
    1. Otwórz administracyjny wiersz polecenia.
    2. Odszukaj odpowiedni katalog (stosownie do tego, czy pula aplikacji jest 32-, czy 64-bitowa):
      • 32-bitowa pula aplikacji: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • 64-bitowa pula aplikacji: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

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

      aspnet_regiis -ga "IIS APPPOOL\nazwa_puli_aplikacji"

    W przypadku puli aplikacji platformy ASP.NET 2.0 lub 3.5 wykonaj te czynności:
    1. Otwórz administracyjny wiersz polecenia.
    2. Odszukaj odpowiedni katalog (stosownie do tego, czy pula aplikacji jest 32-, czy 64-bitowa):
      • 32-bitowa pula aplikacji: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • 64-bitowa pula aplikacji: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Przejdź do odpowiedniego 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 (na poprzedniej ilustracji: My App Pool), uruchom następujące polecenie:
     
    aspnet_regiis -ga "IIS APPPOOL\moja_pula_aplikacji"


    Uwaga Do poprawnego rozpoznania nazw IIS APPPOOL\* przez narzędzie aspnet_regiis może być wymagane działanie usług systemowych APPHOSTSVC i WAS.

  • Rozwiązanie 2b. Utworzenie jawnego elementu <machineKey>

    Dodając jawny element <machineKey> do pliku Web.config aplikacji, deweloper informuje platformę ASP.NET, że nie należy używać wygenerowanego automatycznie klucza kryptograficznego. Dodatek A zawiera instrukcje dotyczące generowania elementu <machineKey>.


Przyczyna 3. Pulę aplikacji skonfigurowano za pomocą parametru LoadUserProfile=false

Jeśli pula aplikacji działa z tożsamością niestandardową, program IIS mógł nie załadować profilu użytkownika tej tożsamości. Jest to efekt uboczny tego, że rejestr HKCU nie jest dostępny dla platformy ASP.NET na potrzeby utrwalania wygenerowanych automatycznie elementów <machineKey>. W wyniku tego każde ponowne uruchomienie aplikacji spowoduje utworzenie nowego wygenerowanego automatycznie klucza. Więcej informacji można znaleźć w sekcji Profil użytkownika w witrynie firmy Microsoft w sieci Web.
  • Rozwiązanie 3a. Zastosowanie narzędzia aspnet_regiis

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

  • Rozwiązanie 3b. Zastosowanie jawnego elementu <machineKey>

    Dodając jawny element <machineKey> do pliku Web.config aplikacji, deweloper informuje platformę ASP.NET, że nie należy używać wygenerowanego automatycznie klucza kryptograficznego. Dodatek A zawiera instrukcje dotyczące generowania elementu <machineKey>.

  • Rozwiązanie 3c. Ręczne zapewnienie obsługi administracyjnej kluczy rejestru

    Jeśli nie można uruchomić narzędzia aspnet_regiis, obsługę odpowiednich kluczy rejestru w gałęzi HKCU można zapewnić za pomocą skryptu programu Windows PowerShell. Więcej informacji można znaleźć w Dodatku B.

  • Rozwiązanie 3d. Ustawienie parametru LoadUserProfile=true dla tej puli aplikacji

    Można też włączyć ładowanie profilu użytkownika w tej puli aplikacji. Udostępni to aplikacji gałąź rejestru HKCU, folder tymczasowy i inne lokalizacje magazynowania charakterystyczne dla użytkowników. Może to jednak zwiększyć użycie dysku lub pamięci przez proces roboczy. Aby uzyskać więcej informacji o tym, jak włączyć to ustawienie, zobacz Element <processModel>.

Przyczyna 4. Właściwość Page.ViewStateUserKey ma nieodpowiednią wartość

Deweloperzy oprogramowania mogą używać właściwości Page.ViewStateUserKey w celu dodawania ochrony przed fałszowaniem żądań międzywitrynowych do pola __VIEWSTATE. W razie używania wartości Page.ViewStateUserKey ma ona zwykle ustawioną wartość nazwy bieżącego użytkownika albo identyfikatora sesji użytkownika. Szablony projektów aplikacji WebForms w programie Microsoft Visual Studio 2012 i nowszych wersjach zawierają przykłady stosowania tej właściwości. Więcej informacji można znaleźć w temacie Właściwość Page.ViewStateUserKey w witrynie Microsoft Developer Network (MSDN) w sieci Web.

Jeśli określono właściwość ViewStateUserKey, jej wartość jest umieszczana w polu __VIEWSTATE w czasie generowania. Podczas używania pola __VIEWSTATE serwer sprawdza właściwość ViewStateUserKey bieżącej strony i weryfikuje ją, porównując z wartością, za pomocą której wygenerowano pole __VIEWSTATE. Jeśli wartości są niezgodne, żądanie jest odrzucane jako potencjalnie złośliwe.

Przykładem niepowodzenia związanego z właściwością ViewStateUserKey jest sytuacja, w której klient ma otwarte w przeglądarce dwie karty. Klient jest zalogowany jako użytkownik A, a w pierwszej karcie renderowana jest strona z polem __VIEWSTATE, którego właściwość ViewStateUserKey zawiera wartość „Użytkownik A”. W drugiej karcie klient wylogowuje się i loguje ponownie jako użytkownik B. Klient wraca do pierwszej karty i ponownie przesyła formularz. Właściwość ViewStateUserKey może zawierać wartość „Użytkownik B” (ponieważ taka informacja znajduje się w pliku cookie uwierzytelniania klienta). Jednak przesłane przez klienta pole __VIEWSTATE zawiera wartość „Użytkownik A”. Ta niezgodność jest przyczyną niepowodzenia.
  • Rozwiązanie 4a. Zweryfikowanie poprawnego ustawienia właściwości ViewStateUserKey

    Jeśli aplikacja używa właściwości ViewStateUserKey, należy upewnić się, że jej wartość jest taka sama zarówno podczas generowania stanu widoku, jak i podczas używania go. Jeśli jest używana nazwa użytkownika obecnie zalogowanego użytkownika, należy upewnić się, że ten użytkownik jest nadal zalogowany i że jego tożsamość się nie zmieniła w czasie ogłaszania zwrotnego. Jeśli jest używany identyfikator sesji bieżącego użytkownika, należy się upewnić, że ta sesja nie wygasła.

    W przypadku środowiska farmy należy się upewnić, że elementy <machineKey> są zgodne. Dodatek A zawiera instrukcje dotyczące generowania tych elementów.

Dodatek A. Jak wygenerować element <machineKey>

Ostrzeżenie dotyczące zabezpieczeń

Wiele witryn sieci Web generuje element <machineKey> po kliknięciu przycisku. Nigdy nie należy używać elementu <machineKey> uzyskanego z takiej witryny. Nie można ustalić, czy te klucze utworzono w sposób bezpieczny ani czy nie są rejestrowane w tajnej bazie danych. Należy zawsze używać tylko samodzielnie utworzonych elementów konfiguracji <machineKey>.


Aby samodzielnie wygenerować element <machineKey>, można użyć poniższego skryptu programu Windows PowerShell:

# Generuje element <machineKey>, który można skopiować i wkleić w pliku Web.config.
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żna wywołać tylko funkcję Generate-MachineKey bez parametrów w celu wygenerowania elementu <machineKey>, w ten sposób:

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

Aplikacje ASP.NET 2.0 i 3.5 nie obsługują szyfrowania HMACSHA256. Zamiast tego można określić szyfrowanie SHA1 w celu wygenerowania zgodnego elementu <machineKey>, w ten sposób:

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

Od razu po uzyskaniu elementu <machineKey> można umieścić go w pliku Web.config. Element <machineKey> jest prawidłowy tylko w pliku Web.config w katalogu głównym aplikacji (nie jest prawidłowy na poziomie podfolderu).

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

Pełną listę obsługiwanych algorytmów można uzyskać, uruchamiając polecenie help Generate-MachineKey w wierszu polecenia programu Windows PowerShell.

Dodatek B. Zapewnianie obsługi administracyjnej utrwalania generowanych automatycznie kluczy w rejestrze

Ponieważ generowane automatycznie klucze platformy ASP.NET są utrwalane w rejestrze HKCU, mogą zostać utracone w konfiguracji domyślnej, jeśli profilu użytkownika nie załadowano w procesie roboczym programu IIS i nastąpi odzyskanie puli aplikacji. Ten scenariusz może wpłynąć na dostawców hostingu współużytkowanego uruchamiających pule aplikacji jako standardowe konta użytkowników systemu Windows.

Aby objeść ten problem, platforma ASP.NET umożliwia utrwalanie wygenerowanych automatycznie kluczy w rejestrze HKLM zamiast w rejestrze HKCU. Zwykle jest to realizowane za pomocą narzędzia aspnet_regiis (zobacz instrukcje w sekcji „Rozwiązanie 2a. Zastosowanie narzędzia aspnet_regiis”). Jednak administratorzy, którzy nie chcą korzystać z tego narzędzia, mogą użyć tego skryptu programu Windows PowerShell:

# Zapewnia obsługę administracyjną rejestru HKLM: określone konto użytkownika może utrwalać wygenerowane automatycznie klucze komputerów.
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 {
    # Do kontynuowania wymagane są uprawnienia administracyjne.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "To polecenie cmdlet wymaga uprawnień administracyjnych."
        return
    }
    # Otwarcie rejestru HKLM w odpowiednim widoku rejestru
    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)
    # Otwarcie klucza podstawowego ASP.NET
    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)
    # Utworzenie podklucza AutoGenKeys, jeśli jeszcze nie istnieje
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Pobranie identyfikatora SID dla danego użytkownika, co pozwoli na uzyskanie jego podklucza AutoGenKeys
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORZY i docelowy identyfikator sesji (SID) uzyskują pełny dostęp
    $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) {
        # Podklucz nie istniał. Utworzenie go i dodanie odpowiedniej listy ACL
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Podklucz istniał. Zapewnienie poprawności list ACL
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

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

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

Jeśli pula aplikacji jest 64-bitowa i działa w środowisku CLR 4.0 (ASP.NET 4.0 lub 4.5), polecenie wygląda tak:

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

Mimo że wygenerowane automatycznie klucze są przechowywane w gałęzi HKLM, podklucze rejestru zawierające tajne wartości kryptograficzne poszczególnych użytkowników są dodawane do listy kontroli dostępu (ACL, Access Control List), więc inne konta użytkowników nie mogą odczytać tych wartości kryptograficznych.

Dodatek C. Szyfrowanie elementu <machineKey> w plikach konfiguracji

Administratorzy serwerów mogą nie chcieć podawać w plikach konfiguracji wysoce poufnych informacji, takich jak wartości kluczy <machineKey>, w postaci zwykłego tekstu. W takim przypadku administrator może skorzystać z funkcji programu .NET Framework o nazwie „konfiguracja chroniona”. Ta funkcja umożliwia szyfrowanie określonych sekcji plików typu config. W razie ujawnienia zawartości tych plików konfiguracji zawartość tych sekcji pozostanie tajna.

Krótkie omówienie konfiguracji chronionej można znaleźć w witrynie MSDN w sieci Web. Jest w niej też dostępny samouczek dotyczący zapewniania ochrony elementów <connectionStrings> i <machineKey> w pliku Web.config.
Uwaga: Niniejszy artykuł, przeznaczony do „SZYBKIEJ PUBLIKACJI”, został utworzony bezpośrednio przez organizację pomocy technicznej firmy Microsoft. Zawarte w nim informacje są udostępniane „w stanie takim, w jakim są” w odpowiedzi na pojawiające się problemy. W wyniku przyspieszonego trybu udostępniania materiały mogą zawierać błędy typograficzne i mogą zostać poprawione w dowolnym momencie bez uprzedzenia. Więcej informacji można znaleźć w Warunkach użytkowania.

Właściwości

Numer ID artykułu: 2915218 - Ostatnia weryfikacja: 20 czerwca 2014 - Weryfikacja: 2.0
Informacje zawarte w tym artykule dotyczą:
  • Microsoft .NET Framework 4.5.1 Release Candidate
  • Microsoft .NET Framework 4.5.1
  • Microsoft .NET Framework 4.5
  • Microsoft .NET Framework 4.0
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 1.1 Service Pack 1
Słowa kluczowe: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218

Przekaż opinię

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com