Усунення помилок у стані подання стану повідомлення автентифікації код (MAC)

Що таке стан перегляду?

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

< тип вводу = "прихований" ім'я = "_ _ VIEWSTATE" ID = "_ _ VIEWSTATE" значення = "..."/>Одним із прикладів елемента, який може зберігатися в полі _ _ VIEWSTATE, є текст кнопки керування. Якщо користувач натискає кнопку, обробник подій Button_Click зможе витягти текст кнопки з поля стан подання. Перегляньте розділ огляд стану ASP.net View на веб-сайті Microsoft для РОЗРОБНИКІВ (MSDN) для більш детального огляду стану ASP.net View. Через те, що поле _ _ VIEWSTATE містить важливі відомості, які використовуються для відновлення сторінки на передавання, переконайтеся, що зловмисник не може втрутитися в цьому полі. Якщо зловмисник, надіслано зловмисних _ VIEWSTATE корисне навантаження, зловмисник потенційно може обдурити застосування у виконання дій, які вона в іншому випадку не буде виконано. Щоб запобігти цьому виду фальсифікації атак, поле _ _ VIEWSTATE захищено код автентифікації повідомлень (MAC). ASP.NET перевіряє, MAC, який подається разом із _ _ VIEWSTATE корисне навантаження, коли відбувається передавання. Ключ, який використовується для обчислення MAC, указаний у елементі застосунку у файлі web. config. Через те, що зловмисник не може вгадати, вміст < machineKey > елемент, зловмисник не може надати дійсний MAC, якщо зловмисник намагається, щоб втрутитися, до _ VIEWSTATE корисне навантаження. ASP.NET виявить, що дійсний MAC не був наданий, і ASP.NET відхилить шкідливий запит.

Що викликає помилки перевірки MAC?

Помилка перевірки MAC, матиме такий приклад:

Помилка сервера в застосунку "/". Не вдалося виконати перевірку містять Viewstate MAC. Якщо цей застосунок розміщено веб-ферми або кластера, переконайтеся, що < machineKey > конфігурації, визначає той самий ключ для перевірки та перевірка алгоритму. Автоматичне створення не можна використовувати у кластері. Опис: сталася необроблена виняткова ситуація під час виконання поточного веб-запиту. Будь ласка, перегляньте трасування стека, щоб отримати додаткові відомості про помилку, і де вона виникла в коді. Відомості про виняток: System. Web. HttpException: перевірка містять Viewstate MAC не вдалося. Якщо цей застосунок розміщено веб-ферми або кластера, переконайтеся, що < machineKey > конфігурації, визначає той самий ключ для перевірки та перевірка алгоритму. Автоматичне створення не можна використовувати у кластері. Помилка джерела: [немає відповідних вихідних рядків] Вихідний файл:... Рядок: 0 Трасування стека: [Перегляд виняток: Неприпустимий Viewstate. IP-клієнт::: 1 Порт: 40653 Референтер: http://localhost:40643/MyPage.aspx Шлях:/MyPage.aspx Агент користувача: Mozilla/5.0 (сумісний; MSIE 10,0; Windows NT 6,2; WOW64 Тризуб/6.0) Перегляд стану:...] [HttpException (0x80004005): перевірка містять Viewstate MAC не вдалося. Якщо цей застосунок розміщено веб-ферми або кластера, переконайтеся, що < machineKey > конфігурації, визначає той самий ключ для перевірки та перевірка алгоритму. Автоматичне створення не можна використовувати у кластері. Щоб дізнатися більше, перегляньте http://go.microsoft.com/fwlink/?LinkID=314055.] System. Web. UI. Viewstate виняток. помилка (виняток внутрішній, рядок збереження, рядок помилки, Булева помилка) + 190 System. Web. UI. Viewstate виняток. повідомлення про помилку (виняток внутрішній, рядок "наполегливість") + 46 System. Web. UI. ObjectStateFormatter. Десеріалізація (рядок введеного рядка, Цільове призначення) + 861 System. Web. UI. ObjectStateFormatter. System. Web. UI. IStateFormatter2. Десеріалізація (рядкова серіалізація, Цільове призначення) + 51 System. Web. UI., Десеріалізація (IStateFormatter2 форматування, рядок Серіалізстан, мета мети) + 67 System. Web. UI. для завантаження () + 444 Система. Web. UI. Page. loadpagest368 atefiffforfi System. Web. UI. сторінка. LoadAllState () + 109 Система. Web. UI. сторінка. Обробоголовна (логічне значення, що включає в собі 7959, що в System. Web. UI. Page. Запит обробки (логічне значення, що включає в собі, що має значення, логічне Включкипісляасинхронна точка) + 429 System. Web. UI. Page. Запит обробки () + 125 System. Web. UI. Page. процес Запитуізністверджувати (HttpContext контексту) + 48 System. Web. UI. Page. Запит обробки (HttpContext контексту) + 234 ASP. mypage_aspx. Запит обробки (HttpContext контексту) в...: 0 System. Web. Callhandlerзапустіть крок. System. Web. HttpApplication. Iкат. виконання () + 1300 System. Web. HttpApplication. виконавець (етап виконання кроку, логічне &, що Повстявчастий) + 140

Причина 1: веб-застосунок працює у фермі (Multi-сервер середовищі)

ASP.NET автоматично генерує криптографічний ключ для кожної програми та зберігає ключ у кущі реєстру ХГХУ. Цей автоматично згенерований ключ використовується, якщо немає явного < machineKey > елемент конфігурації застосунку. Однак через те, що цей автоматично згенерований ключ локальний комп'ютер, який створив ключ, у цьому випадку викликає проблеми для застосунків, які працюють у фермі. Кожен сервер ферми буде генерувати свій локальний ключ, і жоден з серверів у фермі не погодиться, який ключ використовувати. Результат полягає в тому, що, якщо один сервер, генерує _ _ VIEWSTATE корисне навантаження, що інший сервер споживає, споживач буде виникати помилка перевірки MAC.

Роздільна здатність 1a: створення явний < machineKey > елемент Додавши явний < machineKey > елемент застосунку Web. config файл, розробник повідомляє, ASP.NET не використовувати автоматично згенерований криптографічний ключ. Див додаток а для отримання інструкцій про те, як створити < machineKey > елементу. Після того, як цей елемент буде додано до файлу Web. config, повторно розгорнути застосунок на кожному сервері ферми. Зверніть увагу Деякі служби веб-хостингу, наприклад, веб-сайти Microsoft Azure, вжити заходів для синхронізації автоматично створеного ключа кожної програми через їхні резервні сервери. Це дає змогу програмам, які не вказали явного < machineKey > елемент, щоб продовжити роботу в цих середовищах, навіть, якщо застосунок запущено ферми. Якщо ваша заявка працює у службі розміщення третьої сторони, зверніться до свого хостинг-провайдера, щоб визначити, чи застосовується ця ситуація.
Роздільна здатність 1B: Увімкнення близькість, у балансування навантаження Якщо веб-сайти працюють за балансувальником навантаження, можна ввімкнути сервер спорідненість, щоб тимчасово вирішити цю проблему. Це гарантує, що будь-який клієнт взаємодіє лише з одним фізичним сервером за балансувальником навантаження, тому всі криптографічні навантаження будуть генеруватися і споживаються на одному сервері. Це не слід вважати довгостроковим вирішенням проблеми. Навіть якщо сервер споріднена увімкнуто, більшість навантаження балансувальники буде перенаправляти клієнта на інший фізичний сервер, якщо вихідний сервер, до якого були affініціалізори навантаження переходить в автономному режимі. Це призводить до нового сервера, щоб відхилити криптографічних корисних навантажень (наприклад, _, перегляд, форми автентифікації, Mвенчурні анти-підробка маркери та інші служби), що в даний час клієнта. Використання явного < machineKey > елемент і повторне розгортання програми слід перевагу над дозволяючи сервер спорідненість.

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

Інформаційних служб Інтернету (IIS) 7,0 (Windows Vista, Windows Server 2008) введено посвідчення пулу застосунків, новий механізм ізоляції, який допомагає забезпечити підвищення безпеки для серверів, які запускаються ASP.net застосунків. Проте сайти, які працюють під посвідчення пулу застосунків, не мають доступу до реєстру ХПК. Це де 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 для виконання конфігурацій, необхідних для запуску керованого застосунку. Одна з цих конфігурацій створює необхідні ключі в Кущ реєстру, щоб дозволити збереження автоматично генеруються ключі машини. По-перше, потрібно визначити, який Пул застосунків використовує ваш сайт. Це можна визначити за допомогою утиліти ineggmi, яка входить до складу служб IIS. Виберіть свій сайт у перегляді дерева ліворуч, клацніть правою кнопкою миші елемент керування Website, а потім виберіть пункт додаткові настройки. Діалогове вікно, яке з'явиться, покаже назву пулу застосунків. Для Риштування відповідні розділи реєстру для пулу застосунків 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. Перейдіть до каталогу, введіть наведену нижче команду та натисніть клавішу ENTER:
  
  aspnet_regiis-GA "IIS Appoot\app-serpeім'я"
Якщо Пул застосунків, є 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. Перейдіть до каталогу, введіть наведену нижче команду та натисніть клавішу ENTER:
  
  aspnet_regiis-GA "IIS Appoot\app-serpeім'я"
Наприклад, якщо Пул застосунків називається мій пул програм (як на попередньому зображенні), виконайте таку команду:

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

Причина 3: Пул застосунків настроєно за допомогою LoadUserProfile = false

Якщо Пул застосунків запущено з настроюваним посвідченням, служба IIS не може завантажити профіль користувача для посвідчення. Це має побічний ефект прийняття реєстру ХПК недоступний для ASP.NET зберігається автоматично генеруються < machineKey >. Таким чином, новий автоматично згенерований ключ буде створено кожного разу, коли застосунок перезавантажується. Щоб отримати додаткові відомості, перегляньте розділ профіль користувача на веб-сайті Microsoft.

Резолюція 3a: використовуйте утиліту aspnet_regiis Інструкції для цього є такими ж, як і роздільна здатність 2A. Перегляньте цей розділ, щоб отримати додаткові відомості.
Роздільна здатність 3b: використання явного < machineKey > Додавши явний < machineKey > елемент застосунку Web. config файл, розробник повідомляє, ASP.NET не використовувати автоматично згенерований криптографічний ключ. Див додаток а для отримання інструкцій про те, як створити < machineKey > елементу.
Резолюція 3C: забезпечення необхідні ключі до реєстру ХПК вручну Якщо ви не можете запустити утиліту aspnet_regiis, ви можете використовувати сценарій Windows PowerShell для надання відповідних розділів реєстру в хна. Див додаток б для отримання додаткової інформації.
Роздільна здатність 3D: Set LoadUserProfile = True для цього пулу застосунків Ви також можете увімкнути завантаження профілю користувача в цьому пулі застосунків. Це робить Кущ реєстру ХПК, тимчасову папку та інші користувацькі місця зберігання, доступні для програми. Проте це може спричинити збільшення використання диска або пам'яті для робочого процесу. Перегляньте елемент , щоб отримати додаткові відомості про ввімкнення цього параметра.

Причина 4: сторінка. Viewstate Userkey властивість має неправильне значення

Розробники програмного забезпечення можуть прийняти рішення про використання сторінки. Viewstate Userkey властивість, щоб додати міжсайтових запит на захист від шахрайства для поля _ Viewstate. Якщо використовується сторінка. Viewstate Userkey властивість, як правило, встановлено значення, наприклад, ім'я користувача користувача або сеанс ідентифікатор користувача. Шаблони проекту для веб-форм застосунків у Microsoft Visual Studio 2012 і пізніших версій, містять зразки, які використовують цю властивість. Щоб отримати додаткові відомості, перегляньте розділ властивостей сторінки. Viewstate Userkey на веб-сайті корпорації Майкрософт для РОЗРОБНИКІВ (MSDN). Якщо властивість Viewstate Userkey вказано, його значення буде ЗАПИСАНО в _ _ Viewstate під час генерації. Після того, як споживається поля, що відображається, сервер перевіряє поточну сторінку, властивості користувача та перевіряє його від значення, яке було використано для створення поля _ Viewstate. Якщо значення не збігаються, запит відхилено як потенційно шкідливі. Приклад помилки Viewstate, пов'язаної з ключем, було б клієнтом, який має дві вкладки, відкриті в браузері. Клієнт реєструється як користувач A, і на першій вкладці, сторінка відображається з _ _ VIEWSTATE, чиї властивості, ключ користувача, містить "користувач A." У другій вкладці клієнт виходить із системи, а потім знову реєструє як користувач б. Клієнт повертається до першої вкладки і надсилає форму. Властивість Viewstate Userkey може містити "користувач б" (тому що це те, що в cookie-файлі аутентифікації клієнта говорить). Тим не менш, _ _ VIEWSTATE поле, що клієнт, представлений містить "користувач A." Ця невідповідність призводить до помилки.

Роздільна здатність 4 а: переконайтеся, що Viewstate Userkey встановлено правильно Якщо ваш застосунок використовує властивість Viewstate Userkey , переконайтеся, що значення властивості є однаковими, коли стан перегляду створюється, і коли він споживається. Якщо ви використовуєте поточне ім'я користувача, що реєструється, переконайтеся, що користувач все ще ввійшов до системи, і що посвідчення користувача не змінилося під час передавання. Якщо використовується ідентифікатор сеансу поточного користувача, переконайтеся, що сеанс не вичерпано. Якщо ви працюєте в середовищі ферми, переконайтеся, що < machineKey > елементи збігаються. Див додаток а для отримання інструкцій про те, як генерувати ці елементи.

Додаток A: як генерувати < 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 запиту.

Додаток B: підготовка до реєстру, щоб зберегти автоматично створених розділів

За промовчанням через те, що ASP. мережі, автоматично створюються ключі, які зберігаються в реєстрі ХПК, ці розділи може бути втрачено, якщо профіль користувача не було завантажено в IIS робочий процес і потім Пул застосунків, переробляє. Цей сценарій може вплинути на спільних хостинг-провайдерів, які працюють Пули застосунків, як стандартні облікові записи користувачів Windows. Щоб тимчасово усунути цю ситуацію, ASP.NET дозволяє збереження автоматично створених розділів у реєстрі HKLM замість того, як у реєстрі. Зазвичай це виконується за допомогою утиліти 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)
    }
  }
}

У наведеному нижче прикладі показано, як підготувати відповідні записи реєстру HKLM для пулу застосунків, який працює як користувач, 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"

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

Додаток C: шифрування < machineKey > елемент конфігураційних файлів

Адміністратори сервера можуть не хотіти високочутливої інформації, такої як < machinekey > ключовим матеріалом для Бейн форми тексту в конфігураційних файлах. Якщо це так, адміністратори можуть вирішити скористатися функцією .NET Framework, відомої як "захищена конфігурація". Ця функція дає змогу шифрувати певні розділи файлів. config. Якщо вміст цих файлів конфігурації коли-небудь розголошується, вміст цих розділів все одно залишиться секретним. Короткий огляд захищеної конфігурації можна знайти на веб-сайті MSDN. Він також містить підручник про те, як захистити < рядки > і < machineKey > елементів у файлі web. config.