Устранение ошибок, связанных с состоянием вида кода проверки подлинности сообщения (MAC)

Переводы статьи Переводы статьи
Код статьи: 2915218 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

Что такое состояние вида?

Состояние вида — это данные, связанные между страницами веб-форм (ASPX) в приложении ASP.NET. Разметка HTML для поля __VIEWSTATE имеет следующий вид:

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

Например, одним из элементов, которые может содержать поле __VIEWSTATE, является текст кнопки. Если пользователь нажмет кнопку, обработчик события Button_Click извлекает текст кнопки из поля состояния просмотра. Более подробное описание состояния просмотра ASP.NET см. в разделе Обзор состояния просмотра ASP.NET на веб-сайте MSDN (Microsoft Developer Network).

Поскольку поле __VIEWSTATE содержит важные сведения для воссоздания страницы с обратной передачей, убедитесь, что злоумышленник не имеет доступа к этому полю. Если злоумышленник подал полезные данные вредоносного поля __VIEWSTATE, он потенциально может обмануть приложение, выполнив действие, которое в противном случае не было бы выполнено.

Для предотвращения мошеннических атак такого типа поле __VIEWSTATE защищено кодом проверки подлинности сообщения (MAC). При обратной передаче ASP.NET подтверждает код MAC, который подается вместе с полезными данными __VIEWSTATE. Ключ, используемый для вычисления кода MAC, указан в разделе приложения <machineKey> в файле Web.config. Поскольку злоумышленник не может угадать содержимое раздела <machineKey>, он не сможет указать допустимый код MAC при попытке получения доступа к полезным данным __VIEWSTATE. ASP.NET обнаружит, что допустимый код MAC не указан, и отклонит запрос злоумышленника.

Что приводит к появлению ошибок проверки кода MAC?

Ошибка проверки кода MAC выглядит подобным образом:

"Ошибка сервера в '/' приложении"

Проверка состояние вида MAC не удалась. Если приложение управляется модулем Web Farm или кластером, убедитесь, что конфигурация <machineKey> указывает на тот же проверочный ключ validationKey и алгоритм проверки. Функция AutoGenerate не может быть использована в кластере.

Описание: Необработанное исключение при выполнении текущего веб-запроса. Изучите трассировку стека для получения дополнительных сведений о данной ошибке и о вызвавшем ее фрагменте кода.

Сведения об исключении: System.Web.HttpException: Проверка состояние вида MAC не удалась. Если приложение управляется модулем Web Farm или кластером, убедитесь, что конфигурация <machineKey> указывает на тот же проверочный ключ validationKey и алгоритм проверки. Функция AutoGenerate не может быть использована в кластере.

Источник ошибки: [Отсутствуют соответствующие исходные строки]

Исходный файл: ... Строка: 0

Трассировка стека:

[ViewStateException: Неверное состояние вида.
IP-адрес клиента: ::1
Порт: 40653
Источник ссылки: http://localhost:40643/MyPage.aspx
Путь: /MyPage.aspx
Агент пользователя: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
Состояние вида: ...]

[HttpException (0x80004005): Проверка состояние вида MAC не удалась. Если приложение управляется модулем Web Farm или кластером, убедитесь, что конфигурация <machineKey> указывает на тот же проверочный ключ validationKey и алгоритм проверки. Функция AutoGenerate не может быть использована в кластере.

Для получения дополнительных сведений см. 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

Причина 1. Веб-приложение запущено в ферме (мультисерверной среде)

ASP.NET автоматически создает криптографический ключ для каждого приложения и сохраняет его в кусте реестра HKCU. Данный автоматически создаваемый ключ используется в том случае, если в конфигурации приложения не содержится явный элемент <machineKey>. Однако поскольку автоматически создаваемый ключ является локальным для компьютера, который его создал, подобная ситуация вызывает проблемы в приложениях, запущенных в ферме. Каждым сервером в ферме создается свой локальный ключ. Ни один сервер в ферме не согласится использовать общий ключ. В результате, если одним сервером будут созданы полезные данные __VIEWSTATE для использования другим сервером, пользователь столкнется с отказом проверки кода MAC.
  • Решение 1a. Создание явного элемента <machineKey>

    Добавив явный элемент <machineKey> в файл приложения Web.config, разработчик указывает ASP.NET на необходимость отказа от использования автоматически создаваемого криптографического ключа. Для получения инструкций по созданию элемента <machineKey> см. Приложение A. После добавления элемента в файл Web.config выполните повторное развертывание приложения в каждом из серверов в ферме.

    Примечание. Некоторые имеющиеся в Интернете службы, такие как веб-сайты Microsoft Azure, синхронизируют автоматически создаваемые ключи всех приложений на всех своих фоновых серверах. Это позволяет приложениям, в которых не указан явный элемент <machineKey>, продолжать работу в этой среде, даже если приложение запущено в ферме. Если приложение запущено в сторонних службах размещения, обратитесь к поставщику услуг размещения, чтобы узнать, применима ли данная ситуация в вашем случае.

  • Решение 1b. Включение параметра соответствия в подсистеме балансировки нагрузки

    Если веб-сайты работают вне подсистемы балансировки нагрузки, для временного решения проблемы можно включить параметр соответствия сервера. Это поможет обеспечить взаимодействие клиента только с одним физическим сервером вне подсистемы балансировки нагрузки. Таким образом, все криптографические полезные нагрузки будут создаваться и использоваться одним и тем же сервером.

    Это решение проблемы не должно рассматриваться как окончательное. Даже при включенном параметре соответствия сервера большинство подсистем балансировки нагрузки будут перенаправлять клиента на другой физический сервер, если исходный сервер, на котором были связаны подсистемы балансировки нагрузки, перейдет в автономный режим. Это приведет к отклонению новым сервером криптографических полезных нагрузок (таких как __VIEWSTATE, билеты проверки подлинности с помощью форм, маркеры против подделки MVC и другие службы), имеющихся у клиента в настоящее время.

    Использование явного элемента <machineKey> и выполнение повторного развертывания приложения должны быть предпочтительнее, чем включение параметра соответствия сервера.

Причина 2. В рабочем процессе используется удостоверение пула приложений IIS 7.0

Службы IIS версии 7.0 (Windows Vista, Windows Server 2008) представили удостоверение пула приложений, новый механизм изоляции, позволяющий обеспечить повышенную безопасность серверов, на которых запущены приложения ASP.NET. При этом у веб-сайтов, работающих с удостоверением пула приложений, нет доступа к реестру HKCU. В нем среда выполнения ASP.NET хранит автоматически создаваемые ключи <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. В представлении в виде дерева слева выберите ваш сайт, правой кнопкой мыши щелкните Управление веб-сайтом, а затем выберите пункт Дополнительные параметры. В открывшемся диалоговом окне будет указано имя пула приложений.

    Свернуть это изображениеРазвернуть это изображение
    Дополнительные параметры


    Чтобы сформировать соответствующие разделы реестра для пула приложений ASP.NET 4.0, выполните указанные ниже действия.
    1. Откройте командную строку администрирования.
    2. Найдите необходимый каталог в зависимости от типа пула приложений (32 или 64-разрядный):
      • 32-разрядный пул приложений: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • 64-разрядный пул приложений: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Откройте папку, введите следующую команду и нажмите клавишу ВВОД:

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

    Если это пул приложений ASP.NET 2.0 или 3.5, выполните следующие действия.
    1. Откройте командную строку администрирования.
    2. Найдите необходимый каталог в зависимости от типа пула приложений (32 или 64-разрядный):
      • 32-разрядный пул приложений: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • 64-разрядный пул приложений: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Откройте папку, введите следующую команду и нажмите клавишу ВВОД:

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

    Например, если имя вашего пула приложений My App Pool (как на предыдущем изображении), запустите следующую команду:
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Примечание. Системные службы APPHOSTSVC и WAS могут не работать надлежащим образом для разрешения имен IIS APPPOOL\* при помощи средства aspnet_regiis.

  • Решение 2b. Создание явного элемента <machineKey>

    Добавив явный элемент <machineKey> в файл приложения Web.config, разработчик указывает ASP.NET на необходимость отказа от использования автоматически создаваемого криптографического ключа. Для получения инструкций по созданию элемента <machineKey> см. Приложение A


Причина 3. Пул приложений настроен при помощи LoadUserProfile=false

Если пул приложений запущено с использованием настраиваемого удостоверения, возможно, службы IIS не загрузили профиль пользователя для удостоверения. Побочным эффектом этого может стать отключение реестра HKCU для ASP.NET в целях сохранения автоматически создаваемого раздела <machineKey>. Поэтому новый автоматически создаваемый ключ будет создаваться при каждом перезапуске приложения. Дополнительные сведения см. на веб-сайте Майкрософт в разделе Профиль пользователя.
  • Решение 3a. Использование средства aspnet_regiis

    Инструкции для выполнения этого решения те же, что и для решения 2a. Дополнительные сведения см. в соответствующем разделе.

  • Решение 3b. Использование явного элемента <machineKey>

    Добавив явный элемент <machineKey> в файл приложения Web.config, разработчик указывает ASP.NET на необходимость отказа от использования автоматически создаваемого криптографического ключа. Для получения инструкций по созданию элемента <machineKey> см. Приложение A

  • Решение 3c. Подготовка необходимых разделов реестра HKCU вручную

    Если не удается запустить средство aspnet_regiis, для подготовки необходимых разделов реестра HKCU можно использовать сценарий Windows PowerShell. Для получения дополнительных сведений см. Приложение Б.

  • Решение 3d. Установка значения LoadUserProfile=true для данного пула приложений

    Вы также можете разрешить загрузку профиля пользователя в данный пул приложений. Это откроет приложению доступ к кусту реестра HKCU, временной папке и другим личным системам хранения пользователя. Однако это может привести к повышенному потреблению памяти или использованию диска во время рабочего процесса. Для получения дополнительных сведений о включении данного параметра см. элемент <processModel>.

Причина 4. Неправильное значение свойства Page.ViewStateUserKey

Разработчики программного обеспечения могут использовать свойство Page.ViewStateUserKey для добавления в поле __VIEWSTATE средства защиты от подделок межсайтовых запросов. Если вы используете свойство Page.ViewStateUserKey, то обычно для него установлено значение, соответствующее имени текущего пользователя или идентификатору сеанса пользователя. Шаблоны проектов для приложений WebForms в Microsoft Visual Studio 2012 и более поздних версий содержат примеры, в которых используется данное свойство. Для получения дополнительных сведений см. раздел Свойство Page.ViewStateUserKey на веб-сайте MSDN (Microsoft Developer Network).

Если указано свойство ViewStateUserKey, то во время создания его значение совмещается с полем __VIEWSTATE. Если поле __VIEWSTATE использовано, сервер проверяет свойство ViewStateUserKey текущей страницы и соотносит его со значением, которое использовалось для создания поля __VIEWSTATE. Если значения не совпадают, запрос будет отклонен как потенциально вредоносный.

Проблема, связанная со свойством ViewStateUserKey, может возникнуть у клиента, у которого в браузере открыты две вкладки. Клиент вошел в систему как Пользователь А, на первой вкладке страница отображена с полем __VIEWSTATE, свойство ViewStateUserKey которого содержит "Пользователь A." На второй вкладке клиент вышел из системы, а затем повторно вошел как Пользователь Б. Клиент возвращается на первую вкладку и отправляет форму. Свойство ViewStateUserKey может содержать "Пользователь Б" (так как об этом говорится в файле cookie для проверки подлинности клиента). Однако поле __VIEWSTATE, отправленное клиентом, содержит "Пользователь A". Это несоответствие приводит к возникновению проблемы.
  • Решение 4a. Проверка правильности настройки ViewStateUserKey

    Если приложением используется свойство ViewStateUserKey, проверьте, не изменяется ли значение свойства при создании состояния вида и при его использовании. Если вы используете имя текущего пользователя, вошедшего в систему, убедитесь, что он все еще в системе и что его удостоверение не изменилось во время обратной передачи. Если вы используете идентификатор сеанса текущего пользователя, убедитесь в том, что сеанс не был завершен.

    Если вы работаете в среде фермы, проверьте соответствие элементов <machineKey>. Для получения инструкций по созданию этих элементов см. Приложение A.

Приложение А. Создание элемента <machineKey>

Предупреждение системы безопасности

Многие веб-сайты могут создавать элемент <machineKey> с помощью всего одного нажатия кнопки. Никогда не используйте элемент <machineKey>, полученный на одном из этих веб-сайтов. Узнать, были ли созданы эти ключи безопасным путем или же записаны в секретную базу данных, невозможно. Всегда используйте элементы конфигурации <machineKey>, которые вы создали сами.


Чтобы создать элемент <machineKey> самостоятельно, воспользуйтесь указанным ниже сценарием Windows PowerShell:

# Создание элемента <machineKey> с возможностью копирования и вставки в файл 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)
  }
}

Для приложений ASP.NET 4.0 достаточно вызвать следующую команду Generate-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>

Чтобы ознакомиться с полным списком поддерживаемых алгоритмов, запустите help Generate-MachineKey из командной строки Windows PowerShell.

Приложение Б. Подготовка реестра для сохранения автоматически создаваемых ключей

По умолчанию автоматически создаваемые ключи ASP.NET хранятся в реестре HKCU. Они могут быть утрачены, если профиль пользователя не был загружен в рабочий процесс служб IIS, после чего пул приложений будет перезапущен. Данный сценарий может негативно повлиять на общих поставщиков услуг размещения, которые используют пулы приложений как обычные учетные записи пользователей Windows.

В качестве временного решения этой проблемы ASP.NET разрешает сохранение автоматически создаваемых ключей в реестре HKLM вместо того, чтобы хранить их в реестре HKCU. Обычно это выполняется с использованием средства aspnet_regiis (см. инструкции в разделе "Решение 2a. Использование средства aspnet_regiis"). Администраторы, которые не хотят использовать данное средство, могут воспользоваться следующим сценарием Windows PowerShell:

# Подготовка реестра HKLM таким образом, чтобы автоматически создаваемые ключи могли храниться в указанной учетной записи пользователя.
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 {
    # Для продолжения необходимо иметь права администратора.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "Для выполнения данного командлета необходимы права администратора."
        return
    }
    # Открытие HKLM с соответствующим видом в реестре
    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)
    # Открытие базового ключа 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)
    # Создание подключа AutoGenKeys (если он не существует)
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Получение идентификатора безопасности нужного пользователя, что позволит получить его подключ AutoGenKeys
    $sid = (System.Security.Principal.WindowsIdentity($upn)) New-Object.User.Value
    # Получение полного доступа СИСТЕМОЙ, АДМИНИСТРАТОРАМИ и целевым идентификатором безопасности
    $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) {
        # Подключ не существует; создание его и списка управления доступом
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Подключ имеется; проверка правильности списков управления доступом
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

Ниже приведен пример подготовки соответствующих записей в реестре HKLM для пула приложений, запущенных от имени пользователя, example@contoso.com (это основное имя участника-пользователя учетной записи Windows). Данный пул приложений является 32-разрядным и использует среду CLR v2.0 (ASP.NET 2.0 или 3.5).

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

Если пул приложений является 64-разрядным и использует среду CLR v4.0 (ASP.NET 4.0 или 4.5), команда будет выглядеть следующим образом:

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

Несмотря на то, что автоматически создаваемые ключи хранятся в реестре HKLM, подключ реестра, отвечающий за секретные криптографические материалы каждой учетной записи пользователя, добавляется в список управления доступом (ACL), чтобы эти материалы не были доступны с других учетных записей пользователей.

Приложение В. Шифрование элемента <machineKey> в файлах конфигурации

Возможно, администраторы сервера не хотят, чтобы конфиденциальные данные (например, материал ключа <machineKey>) хранились в форме обычного текста в файлах конфигурации. В таком случае можно воспользоваться функцией платформы .NET Framework под названием "защищенная конфигурация". Эта функция позволяет шифровать определенные разделы файлов с расширением CONFIG. Если содержимое этих файлов конфигурации будет раскрыто, то содержимое указанных разделов — нет.

Ознакомиться с кратким обзором защищенной конфигурации можно на веб-сайте MSDN. Кроме того, он содержит руководство о том, как защитить элементы <connectionStrings> и <machineKey> в файле Web.config.
Примечание. Это ЭКСПРЕСС-ПУБЛИКАЦИЯ, подготовленная непосредственно службой технической поддержки Майкрософт . Сведения, содержащиеся в данном документе, предоставлены в качестве отклика на возникшие проблемы. Из-за срочности в материалах могут быть опечатки, и в любое время и без уведомления в них могут быть внесены изменения. Чтобы получить дополнительные сведения, см. Условия использования.

Свойства

Код статьи: 2915218 - Последний отзыв: 20 июня 2014 г. - Revision: 2.0
Информация в данной статье относится к следующим продуктам.
  • 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
Ключевые слова: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218

Отправить отзыв

 

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