Налаштування забезпечення безпеки
Конфігурація ASP.NET дозволяє налаштувати весь сервер, додаток ASP.NET або окремі сторінки в підкаталогах додатки. Можна налаштувати такі можливості, як режим перевірки автентичності, кешування сторінок, параметри компілятора, спеціальні повідомлення про помилки, параметри налагодження і трасування і багато іншого. У цьому розділі описується, як, використовуючи рекомендації, оптимізувати безпеку можливостей конфігурації при налаштуванні локальних або віддалених програм ASP.NET. Додаткові відомості про захист інших можливостей ASP.NET см. В розділах, перерахованих в підрозділі Див. Також.
Наведені тут рекомендації щодо конфігурації та кодування допоможуть підвищити безпеку додатків. Але не менш важливо постійно встановлювати на сервері додатка останні оновлення засобів захисту для Microsoft Windows і служб Microsoft Internet Information Services (IIS), а також всі оновлення для Microsoft SQL Server або іншого програмного забезпечення, що забезпечує доступ до джерел даних.
Можливості системи конфігурації ASP.NET відносяться тільки до ресурсів та можливостей ASP.NET. Для настройки ресурсів, що не відносяться до ASP.NET, використовуйте можливості конфігурації служб IIS. Додаткову інформацію про створення служб IIS см. В розділах Робота з метабази (IIS 6.0) і Довідник властивостей метабази IIS.
При збереженні конфіденційних відомостей у файлі конфігурації програми слід зашифрувати конфіденційні значення, використовуючи захищену конфігурацію. Особливо конфіденційні відомості включають ключі шифрування, що зберігаються в елементі конфігурації machineKey і рядки підключень до джерела даних, що зберігаються в елементі конфігурації connectionStrings. Додаткові відомості див. У розділі Шифрування відомостей про конфігурацію за допомогою функції захищеної конфігурації.
Захист конфігурації контейнерів ключа шифрування
Критичним питанням при використанні ключа шифрування є захист файлу, який також називають контейнером, в якому зберігається ключ. Важливо пам'ятати рівень захисту, пов'язаний з контейнером. Зверніть увагу, що контейнер зберігається в звичайному файлі операційної системи, а доступ до ключа шифрування регулюється списками управління доступом до файлу. Списки управління доступом можуть успадковуватися від папки, в якій створюється файл. Контейнери ключів з локальною областю дії (useMachineContainer "true") зберігаються в прихованій папці% ALLUSERSPROFILE% \ Application Data \ Microsoft \ Crypto \ RSA \ MachineKeys.
За замовчуванням користувач, який створив контейнер, володіє повним доступом до ключу. Інші користувачі (включаючи групу Адміністратори) можуть мати або не мати доступ до контейнера, в залежності від списків управління доступом контейнера. Інші користувачі можуть отримати доступ до контейнера за допомогою ключа -pa програми реєстрації IIS для ASP.NET (Програма реєстрації IIS для ASP.NET (Aspnet_regiis.exe)). Користувачі, які намагаються зашифрувати або розшифрувати дані з вказаним ключем, повинні володіти необхідними дозволами для отримання доступу до контейнера ключа.
У деяких випадках користувач без адміністративних прав може створити ключ шифрування. Це може статися, коли програму слід шифрування конфігурації, але при цьому ключ не існує. Зверніть увагу, що якщо в цьому випадку створюється контейнер, то виконується операція шифрування.
Тоді платформа .NET Framework створює необхідний ключ і відповідний контейнер зі списками управління доступом поточного користувача. Потенційна проблема при цьому полягає в тому, що користувач з правами адміністратора може не отримати доступ до контейнера ключа шифрування. Адміністратори можуть отримати доступ до ключа, отримавши володіння фізичним файлом в папці, зазначеної вище. Описані рекомендації вказують на те, що користувач з правами адміністратора повинен створювати необхідні ключі перед їх використанням, і тим самим уникати їх створення під час шифрування.
У загальному середовищі розміщення користувачі-зловмисники можуть змінити параметри конфігурації, безпосередньо редагуючи файли конфігурації, використовуючи API конфігурації та інші засоби адміністрування і настройки. Запобігти зміна конфігурації програми можна шляхом блокування розділів конфігурації. Зробити це можна, додавши елементи location в файл Machine.config або будь-який інший файл конфігурації, розташовані в ієрархії вище, ніж файл конфігурації, який необхідно захистити. Елемент location використовується для запобігання змін параметрів дочірніх файлів конфігурації. Додаткові відомості див. У розділах Покрокове керівництво. Відключення параметрів конфігурації ASP.NET і Практичний посібник. Налаштування окремих каталогів за допомогою параметрів розташування.
За замовчуванням віддалена настройка відключена. Якщо вона включена, перевірка справжності користувача виконується на рівні DCOM і тільки локальні адміністратори мають право доступу для читання і запису даних конфігурації. Додаткові відомості див. У розділі Редагування віддалених файлів конфігурації ASP.NET.
Система конфігурації задає дозволу перед викликом для користувача обробника розділу конфігурації, і цей виклик не має довіри для платформи .NET Framework. Виклик виконується з роздільною здатністю довіри додатки. Система конфігурації ASP.NET довіряє каталогу% SystemRoot% \ Microsoft.NET \ Framework \ версія \ CONFIG, але не довіряє каталогам, розташованим нижче в ієрархії.
Для отримання дозволів для користувача обробник розділу конфігурації повинен задавати атрибути управління доступом для коду (CAS) на вимогу. Додаткові відомості див. У розділі Керування доступом для коду в ASP.NET або Основи управління доступом для коду.
Блокування файлу конфігурації
Заблокувати файл конфігурації можуть тільки кілька спроб зберегти дані в файл конфігурації або відкрити дескриптор файлу. Користувач-зловмисник може спробувати заблокувати файл Machine.config або кореневої файл Web.config, але для цього потрібно повна довіра, яке за замовчуванням вимкнено.
Використання API-конфігурації для читання файлів довільних файлів
Класи API-конфігурації не можуть зчитувати каталоги, які не є частиною домену додатки, або файли, розширення яких не .CONFIG.
Якщо IIS отримує запит на додаток ASP.NET, параметри метабази IIS застосовуються до додатка ASP.NET незалежно від параметрів конфігурації ASP.NET для цього додатка. Це обмеження може призвести до того, що додатки ASP.NET стануть недоступними для користувачів або матимуть менші обмеження доступу.
Наприклад, якщо параметри безпеки метабази IIS задані таким чином, щоб дозволяти доступ тільки користувачам, які пройшли перевірку автентичності, а параметри безпеки файлу Web.config IIS дозволяють анонімний доступ до вузла, то анонімні користувачі не отримають доступ до вузла. Щоб виправити це, слід в диспетчері служб IIS налаштувати для веб-додатки доступ анонімних користувачів.
Додаткові відомості про захист можливостей служб IIS див. Розділ Безпека в IIS 6.0.
У наступних підрозділах описано, як можна зменшити потенційні ризики системи безпеки, створювані повідомленнями несподіваних помилок і подіями.
винятки
Щоб запобігти наданню конфіденційних відомостей небажаним джерел, налаштуйте додаток так, щоб воно або не відображало докладні повідомлення про помилки, або відображало докладні повідомлення про помилки, якщо тільки клієнтом є сам веб-сервер. Додаткові відомості див. У розділі Елемент customErrors (схема параметрів ASP.NET).
Журнал подій
Спостереження за працездатністю
Успішні та невдалі спроби входу реєструються з використанням засобу спостереження за працездатністю ASP.NET. У конфігурації за замовчуванням це означає, що при невдалій спробі входу в систему в журнал подій додатків записується ім'я користувача і інша діагностична інформація. Переконайтеся, що доступ до журналу подій обмежений для забезпечення конфіденційності цих відомостей.