Разрешаване на изглед състояние съобщение за удостоверяване (MAC) грешки

Какво е състоянието на гледката?

Преглед на състоянието е информация, която е кръгла препъна между уеб формуляри (. aspx) страници в ASP.NET приложение. HTML коректури за полето "_ VIEWSTATE" подобно на следното:

< входен тип = "скрит" име = "_ * VIEWSTATE" ID = "_ * VIEWSTATE" стойност = "..."/>Един пример за елемент, който може да се съхранява в полето "_ VIEWSTATE" е текстът на контролата "бутон". Ако потребителят кликне върху бутона, манипулатора на събития на Button_Click ще може да извлича текста на бутона от полето "изглед на състояние". Вижте темата ASP.net преглед на състоянието на изгледа на уеб сайта на мрежата за разработчици на Microsoft (MSDN) за много по-подробен преглед на състоянието на ASP.net изглед. Тъй като _ * VIEWSTATE поле съдържа важна информация, която се използва за възстановяване на страницата на postback, уверете се, че атакуващият не може да се променят с това поле. Ако атакуващият подаде злонамерен _ * VIEWSTATE полезен товар, атакуващият потенциално може да измами приложението в изпълнение на действие, което в противен случай не би извършил. За да предотвратите този вид подправяне атака, най-_ VIEWSTATE поле е защитено с код за удостоверяване на съобщение (MAC). ASP.NET валидира MAC, който се подава заедно с _ * VIEWSTATE полезния товар при възникване на обратно връщане. Ключът, който се използва за изчисляване на MAC е указан в елемента на приложението във файла Web. config. Тъй като атакуващият не може да отгатне съдържанието на < machineKey > елемент, атакуващият не може да предостави валиден MAC, ако атакуващият се опитва да се опита да се променят _ * VIEWSTATE полезния товар. ASP.NET ще открие, че не е предоставен валиден MAC и ASP.NET ще отхвърли злонамереното искане.

Какво причинява грешки при проверка на MAC?

Грешка при проверка на MAC ще прилича на следния пример:

Грешка в сървъра в приложението "/". Удостоверяването на видимостта на MAC е неуспешно. Ако това приложение се хоства от уеб група или клъстер, уверете се, че < machineKey > конфигурация задава същата Потвърждаванеключ и алгоритъм за валидиране. Автогенерирането не може да се използва в клъстер. Описание: Възникна необработено изключение по време на изпълнението на текущото уеб искане. Прегледайте проследяването на стека за повече информация за грешката и когато тя произхожда от кода. Изключение подробности: система. http изключение: валидиране на имат Mac е неуспешно. Ако това приложение се хоства от уеб група или клъстер, уверете се, че < machineKey > конфигурация задава същата Потвърждаванеключ и алгоритъм за валидиране. Автогенерирането не може да се използва в клъстер. Грешка източник: [няма съответни изходни линии] Файл източник:... Ред: 0 Проследяване на стека: [Изключение от изгледите на видимост: Невалидно състояние на видимост. Клиентски IP::: 1 Порт: 40653 Референник: http://localhost:40643/MyPage.aspx Път:/Myup.Lap Потребител-агент: Mozilla/5.0 (съвместим; MSIE 10,0; Windows NT 6,2; WOW64 Тризъбец/6,0) Гледкасъстояние:...] [Http изключение (0x80004005): удостоверяването на изгледа на състоянието MAC е неуспешно. Ако това приложение се хоства от уеб група или клъстер, уверете се, че < machineKey > конфигурация задава същата Потвърждаванеключ и алгоритъм за валидиране. Автогенерирането не може да се използва в клъстер. Вижте http://go.microsoft.com/fwlink/?LinkID=314055 за повече информация.] System. Web. UI. изглед на видимост. Паггрешка (изключение вътрешно, низ за устойчиво състояние, низа грешка, булеви грешки) + 190 System. Web. UI. видимост. грешка (изключение вътрешно, низ за устойчиво състояние) + 46 System. Web. UI. Обектстраница. Деериализиране (низ inputString, цел) + 861 System. Web. UI. Обектсъстояние. System. Web. UI. IStateFormatter2. Деериксоид (низ сериен обект, цел) + 51 System. Web. UI. util. Deserializezerla (IStateFormatter2 форматер, низ serializedState, цел) + 67 System. Web. UI. Хидуденестранистраница. натоварване () + 444 System. уеб. UI. Page. Лоадпажестатефромперсистенцемедиум () + 368 System. Web. UI. страница. товарна област () + 109 System. Web. UI. процес на обработка (булеви Включениточки, булеви Включваточки на системата) + 7959 System. уеб. UI. страница. Обработказаявка (булеви Включениточки, булеви Включениточки) + 429 Система. уеб. UI. 125 страница System. уеб. UI. процес на обработване (http контекстни контекст) + 48 Система. уеб. UI. страници (http контекст контекст) + 234 ASP. mypage_aspx. Процесзаявка (http контекстни контекст) в...: 0 System. уеб. Callhandlerизпълним стъпка. System. Web. http приложение. изпълнение () + 1300 System. Web. http приложение. Изпълнителностъпка, булев & Завършисинхронно) + 140

Причина 1: уеб приложението се изпълнява в група (мулти-сървър среда)

ASP.NET автоматично генерира Криптографски ключ за всяко приложение и съхранява ключа в набора от регистри HKCU. Този автоматично генериран ключ се използва, ако няма изрични < machineKey > елемент в конфигурацията на приложението. Обаче тъй като този автоматично генериран ключ е локален компютър, който е създал ключа, този сценарий причинява проблем за приложения, които се изпълняват в група. Всеки сървър в групата ще генерира свой собствен локален ключ и никой от сървърите в групата няма да се съгласи кой клавиш да използва. Резултатът е, че ако един сървър генерира _ "VIEWSTATE полезен товар, който се консумира от друг сървър, потребителят ще изпитва грешка при проверка на MAC.

Резолюция 1a: създаване на изрично < machineKey > елемент Чрез добавяне на изрично < machineKey > елемент към файла Web. config на приложението, разработчик казва на ASP.NET да не използва автоматично генерирания шифроващ ключ. Вижте приложение а за инструкции как да генерирате < machineKey > елемент. След като този елемент се добавя към файла Web. Config, повторно разполагане на приложението на всеки сървър в сървърната група. Забележка: Някои уеб хостинг услуги, като например уеб сайтове на Microsoft Azure, предприемат стъпки за синхронизиране на автоматично генерирания ключ на всяко приложение в техните сървърни сървъри. Това позволява приложения, които не са посочили изрично < machineKey > елемент, за да продължите да работите в тези среди, дори ако приложението се изпълнява в група. Ако вашето приложение се изпълнява на хостинг услуга на трета страна, моля, свържете се с вашия доставчик на хостинг, за да определите дали тази ситуация се отнася за вас.
Разделителна способност 1 б: разрешаване на афинитет в балансиращ товар Ако сайтовете ви работят зад балансиращ товар, можете да разрешите сървърния афинитет, за да заобиколите временно проблема. Това помага да се гарантира, че всеки клиент взаимодейства само с един физически сървър зад балансиране на натоварването, така че всички криптографските натоварвания ще бъдат генерирани от и консумирани от същия сървър. Това не трябва да се счита за дългосрочно решение на проблема. Дори когато сървърът афинитет е разрешена, повечето балансиращи натоварването ще пренасочи клиента към друг физически сървър, ако оригиналният сървър, към който са били инициализирани натоварването е офлайн. Това води до нов сървър да отхвърли криптографските натоварвания (като _ * VIEWSTATE, формуляри билети за удостоверяване, MVCs анти-фалшифициране маркери и други услуги), които клиентът в момента. Използване на изрично < machineKey > елемент и пренасочване на приложението трябва да се предпочита чрез разрешаване на сървъра афинитет.

Причина 2: работният процес използва идентичност на набора приложения на IIS 7,0

Интернет информационни услуги (IIS) 7,0 (Windows Vista, Windows Server 2008) въведена идентичностна набора приложения, нов механизъм за изолиране, който спомага за осигуряване на повишена защита за сървъри, които изпълняват ASP.net приложения. Обаче сайтовете, които се изпълняват под самоличността на набора приложения нямат достъп до системния регистър HKCU. Това е мястото, където ASP.NET Runtime съхранява своите автоматично генерирани < machineKey > клавиши. Резултатът е, че ASP.NET не може да запази автоматично генерирания ключ, когато се нулира набора приложения. Затова всеки път, когато се нулира w3wp. exe, се генерира нов временен ключ. Забележка: Това не е проблем в IIS 7,5 (Windows 7, Windows Server 2008 R2) и по-нови версии. На тези версии на IIS ASP.NET може да запази своите автоматично генерирани клавиши на друго място, което оцелява приложение набор нулира.

Резолюция 2a: използване на помощната програма за aspnet_regiis ASP.NET инсталации съдържат полезност, aspnet_regiis. exe. Тази помощна програма позволява ASP.NET интерфейс с IIS за извършване на конфигурации, които са необходими за изпълнение на управлявано приложение. Една от тези конфигурации създава необходимите ключове в набора от раздели на системния регистър, за да позволи персистиране на автоматично генерирани машинни клавиши. Първо трябва да определите кой набор приложения сайтът ви използва. Това може да се определи с помощта на помощната програма inetmgr , която е ВКЛЮЧЕНА в IIS. Изберете сайта си в дървовиден изглед вляво, щракнете с десния бутон върху управление на website и след това щракнете върху Разширени настройки. Диалоговият прозорец, който се появява, ще покаже името на набора приложения. Да скелеан съответните ключове на системния регистър за ASP.NET 4,0 набор приложения, изпълнете следните стъпки:
1. Отворете административен команден прозорец.
2. Намерете съответната директория, в зависимост от това дали набора приложения е 32-bit или 64-bit:
  - 32-битов набор приложения: CD/d%WINDIR%\Microsoft.NET\Framework\v4.0.30319
  - 64-битов набор приложения: CD/d%WINDIR%\Microsoft.NET\Framework64\v4.0.30319
3. Преместване в директорията, въведете следната команда и натиснете ENTER:
  
  aspnet_regiis-GA "IIS приложения \ App
Ако набора приложения е ASP.NET 2,0 или 3,5 набор приложения, изпълнете следните стъпки:
1. Отворете административен команден прозорец.
2. Намерете съответната директория, в зависимост от това дали набора приложения е 32-bit или 64-bit:
  - 32-битов набор приложения: CD/d%WINDIR%\Microsoft.NET\Framework\v2.0.50727
  - 64-битов набор приложения: CD/d%WINDIR%\Microsoft.NET\Framework64\v2.0.50727
3. Преместване в директорията, въведете следната команда и натиснете ENTER:
  
  aspnet_regiis-GA "IIS приложения \ App
Например ако вашия набор приложения е наименуван моя набор приложения (както в предишното изображение), изпълнете следната команда:

aspnet_regiis-GA "IIS apppool \ моя набор приложения" Забележка: Системните услуги APPHOSTSVC и е възможно да се наложи да се изпълнява aspnet_regiis помощната програма за разрешаване на IIS APPPOOL \ * имена по подходящ начин.
Резолюция 2 б: създаване на изрично < machineKey > елемент Чрез добавяне на изрично < machineKey > елемент към файла Web. config на приложението, разработчик казва на ASP.NET да не използва автоматично генерирания шифроващ ключ. Вижте приложение а за инструкции как да генерирате < machineKey > елемент.

Причина 3: набора от приложения е конфигуриран с помощта на товарни потребителски профил = FALSE

Ако набор приложения се изпълнява с персонализирана идентичност, IIS може да не са заредени потребителския профил за самоличност. Това е страничен ефект от вземане на системния регистър HKCU недостъпен за ASP.NET да запази автоматично генерирания < machineKey >. Затова ще се създаде нов автоматично генериран ключ всеки път, когато приложението се рестартира. За повече информация вижте раздела за потребителски профили в уеб сайта на Microsoft.

Разделителна способност 3a: използване на помощната програма за aspnet_regiis Инструкциите за това са същите като резолюция 2 а. Вижте тази секция за повече информация.
Разделителна способност 3b: използвайте изрично < machineKey > Чрез добавяне на изрично < machineKey > елемент към файла Web. config на приложението, разработчик казва на ASP.NET да не използва автоматично генерирания шифроващ ключ. Вижте приложение а за инструкции как да генерирате < machineKey > елемент.
Разделителна способност 3c: осигуряване на необходимите HKCU ключове на системния регистър ръчно Ако не можете да стартирате aspnet_regiis помощната програма, можете да използвате скрипт на Windows PowerShell за осигуряване на съответните ключове на системния регистър в HKCU. За повече информация вижте допълнение б .
Разделителна способност 3D: Задаване на натоварванепрофил = True за този набор приложения Можете също да разрешите зареждането на потребителския профил в този набор приложения. Това прави набора от системния регистър HKCU, временната папка и други специфични за потребителя места за съхранение, налични за приложението. Обаче това може да доведе до увеличен диск или памет за работния процес. Вижте елемента за повече информация как да разрешите тази настройка.

Причина 4: свойството Page. Viewstate Userkey е неправилна стойност

Разработчиците на софтуер могат да решат да използват страницата. свойство на Viewstate Userkey за добавяне на заявка за подправяне на кръстосани сайтове в полето _ ' viewstate. Ако използвате страницата. свойството Viewstate Userkey , обикновено е зададена стойност, като например потребителското име на текущия потребител или идентификатора на сесията на потребителя. Шаблоните на проекта за уеб формуляри приложения в Microsoft Visual Studio 2012 и по-нови версии съдържат проби, които използват това свойство. Вижте страницата. изгледи свойството Viewstate Userkey на уеб сайта за разработчици на Microsoft (MSDN) за повече информация. Ако свойството Viewstate Userkey е зададено, стойността му се ЗАПИСВА в _ * viewstate в поколение време. Когато най-_ ' VIEWSTATE поле се консумира, сървърът проверява свойството на текущата страница Viewstate Userkey и го валидира срещу стойността, която е използвана за генериране на _ * viewstate поле. Ако стойностите не съвпадат, искането се отхвърля като потенциално злонамерен. Пример за изгледи, свързани с viewstate User Key, ще бъде клиент, който има два раздела, отворени в браузъра. Клиентът е влязъл като потребител а, и в първия раздел, страница се рендира с О1 viewstate, чийто изглед свойство съдържа "потребител а." Във втория раздел клиентът излиза и след това се регистрира отново като потребител б. Клиентът се връща към първия раздел и подава формуляра. Свойството Viewstate Userkey може да съдържа "потребител б" (защото това е, което казва "бисквитка" на клиента за удостоверяване). Обаче най-_ VIEWSTATE поле, който клиентът подаде съдържа "потребител а." Това несъответствие води до неуспех.

Резолюция 4A: Проверете дали Viewstate Userkey е настроен правилно Ако вашето приложение използва свойството Viewstate Userkey , проверете дали стойността на свойството е същата както при показване на състоянието се генерира и когато се консумира. Ако използвате текущото потребителско име за регистриран потребител, уверете се, че потребителят все още е влязъл и че самоличността на потребителя не се е променило по време на постбек. Ако използвате текущия потребителски идентификатор на сесия, уверете се, че сесията не е изтекла. Ако работите в среда на група, уверете се, че < machineKey > елементи съвпадат. Вижте приложение а за инструкции как да генерирате тези елементи.

Допълнение а: как да генерирате < machineKey > елемент

Предупреждение за сигурността Има много уеб сайтове, които ще генерират < machineKey > елемент за вас с кликване на бутон. Никога не използвайте < machineKey > елемент, който сте получили от един от тези сайтове. Невъзможно е да се знае дали тези клавиши са били създадени сигурно или ако те се записват в тайна база данни. Трябва някога да използвате < machineKey > конфигурационни елементи, които сте създали сами.

За генериране на < machineKey > елемент сами, можете да използвате следния скрипт на 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)
  }
}

За ASP.NET 4,0 приложения, можете просто да се обадите генерират-machinekey без параметри за генериране на < machinekey > елемент, както следва:

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

ASP.NET 2,0 и 3,5 приложения не поддържат HMACSHA256. Вместо това можете да укажете SHA1 да генерира съвместим < machineKey > елемент, както следва:

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

Веднага след като имате < machineKey > елемент, можете да го поставите във файла Web. config. Елементът < machineKey > е валиден само във файла Web. config в корена на вашето приложение и не е валиден на ниво подпапка.

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

За пълен списък на поддържаните алгоритми стартирайте помощ генериране на MachineKey от Windows PowerShell подкана.

Допълнение б: осигуряване на системния регистър да запазят автоматично генерирани клавиши

По подразбиране, защото ASP. мрежи автоматично генерирани ключове се запазват в системния регистър HKCU, тези клавиши могат да бъдат загубени, Ако потребителският профил не е зареден в IIS работният процес и след това набора рециклира. Този сценарий може да засегне споделени хостинг доставчици, работещи набори приложения като стандартни Windows потребителски акаунти. За да заобиколите тази ситуация, ASP.NET позволява персистиращ автоматично генерирани ключове в системния регистър HММ вместо HKCU системния регистър. Това обикновено се извършва с помощта на помощната програма aspnet_regiis (вижте инструкциите в раздела "резолюция 2a: използвайте помощната програма за aspnet_regiis"). Обаче за администратори, които не искате да изпълните тази помощна програма, може да се използва следния скрипт на 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)
    }
  }
}

Следващият пример показва как да се предвиди съответните HKKS записи в системния регистър за набора приложения, който се изпълнява като потребител, example@contoso.com (това е UPN на потребителския акаунт на Windows). Този набор приложения е 32-битов набор приложения, който се изпълнява CLR v 2.0 (ASP.NET 2,0 или 3,5).

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

Ако набора приложения вместо това е 64-битов набор приложения, който работи CLR v 4.0 (ASP.NET 4,0 или 4,5), командата е както следва:

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

Въпреки че автоматично генерирани клавиши се съхраняват в HKKA, подключ на системния регистър, който съдържа всеки потребителски акаунт таен криптографски материал се добавя към списък за контрол на достъпа (ACL), така че криптографски материал не може да се чете от други потребителски акаунти.

Допълнение в: шифроване на < machineKey > елемент в конфигурационните файлове

Сървърните администратори може да не искат силно чувствителна информация, като например < machineKey > ключов материал, за да бъде обикновен формуляр в конфигурационни файлове. Ако случаят е такъв, администраторите могат да решат да се възползвате от функцията на .NET Framework, известна като "защитена конфигурация". Тази функция ви позволява да шифровате определени секции на. config файлове. Ако съдържанието на тези конфигурационни файлове са оповестени някога, съдържанието на тези секции все още ще остане тайна. Можете да намерите кратък преглед на защитена конфигурация на уеб сайта на MSDN. Той също така съдържа урок за това как да защитите < Връзканизове > и < machineKey > елементи на файла Web. config.