Захист паролем Web-сторінок у IIS 5

Java, ASP або Windows: як краще захистити веб-сторінки?

Захист Web-сторінок за допомогою ASP

За останні кілька років було розроблено низку рішень для захисту Web-сторінок за допомогою пароля на базі ASP. Програми ASP для керування доступом добре інтегруються з існуючими ASP-сторінками, що залежать від введених даних, і тому є кращими для адміністраторів IIS. У багатьох ASP-програмах автентифікації пароль користувача зберігається в базах даних Microsoft Access або Microsoft SQL Server, звідки його набагато складніше дістати. Винахідливі адміністратори створюють ASP-рішення довжиною всього близько десятка рядків з використанням HTML-форми, яка пересилається сама собі. За допомогою методу POST форма перевіряє пароль, прихований у вихідному серверному тексті ASP, недоступному для користувача.

Другий варіант такої програми містить приблизно 25 рядків вихідного тексту; для надання доступу до сторінки при повторному відвідуванні використовуються файли cookie. Одна з додаткових переваг сеансових файлів cookie-файлів полягає в тому, що в даному випадку користувач вводить пароль тільки один раз. Термін дії cookies-файлів можна обмежити, щоб запобігти доступу з використанням пароля, збереженого в кеші. Пароль вбудовується в серверні програми ASP, а не в файл cookie. Щоб інші користувачі спільного комп'ютера не могли отримати доступ до сторінки, термін дії файлів cookie можна скоротити.

У Лістингу 2 показаний зразок програми protect.asp, що містить 11 рядків тексту VBScript і стандартну форму, що надсилається самій собі. Доступ за паролем збережено у змінній сеансу з ім'ям SecureAccess. Поки поточний сеанс користувача активний, змінна SecureAccess має значення Yes, таКористувач може звертатися до сторінки, не вводячи пароль повторно. Сценарій перевіряє значення прихованого поля у формі та продовжить перевірку пароля лише в тому випадку, якщо форма надіслала правильне значення.

Вихідний текст Лістингу 2 слід вставити на початок сторінки перед тегами HTML та

або текстом ASP. Сторінка має дати ім'я, визначене у методі POST action=filename (у разі — protect.asp). Потім можна змінити пароль у рядку If Password=. Оскільки вихідний текст ASP розміщено на сервері, пароль не можна побачити у браузері користувача. Не можна дозволяти користувачам переглядати цей каталог, оскільки вони можуть клацнути на імені файлу правою кнопкою миші та зберегти весь вміст на локальному диску. Зберігши файл на локальній машині, користувачі можуть вивести його на екран, у тому числі вихідний текст ASP та пароль. Якщо ви ввели неправильний пароль, форма з'явиться знову. Такий метод краще, ніж виведення повідомлень про помилку 404 File not found або Maximum Retries Exceeded. Після введення правильного пароля користувач отримує доступ до захищеної частини сторінки.

Інший метод захисту за допомогою пароля на основі ASP - зберігання пароля у базі даних або файлі. Користувач повинен ввести у форму ім'я та пароль. Система порівнює ім'я користувача та пароль із записами в базі даних або відшукує відповідне значення у файлі паролів. Цей метод загалом надійніший, ніж розглянуті вище програми, оскільки вихідний текст ASP і паролі зберігаються у різних місцях. На веб-сайтах Internet можна знайти безліч прикладів сценаріїв ASP зі збереженням пароля в базі даних.

Останній запобіжний захід - подбати про те, щоб користувачам було непросто обійти сторінки аутентифікації. Це означає, що сторінки, які не мають форм, що пересилаються самимсобі повинні виконуватися впорядковано. Щоб запобігти обходу, слід використовувати сеансові змінні або сеансові файли cookie. З їх допомогою можна зробити так, щоб сторінка застаріла негайно і для завдання негайного старіння сторінки ASP виконувалася при кожному зверненні до сторінки. Якщо цього не зробити, наступний користувач зможе отримати доступ до екземпляра сторінки з кешу. Кешування — один із недоліків сеансових змінних: сеанс залишається активним доти, доки не буде закрито вікно браузера. Будь-який користувач через це вікно може отримати доступ до захищеної сторінки.

Вбудовані функції захисту Windows та IIS

Методи автентифікації призначаються з консолі Microsoft Management Console (MMC). Потрібно виконати такі дії.

Відкрити MMC.
Клацнувши правою кнопкою миші по всьому вузлу, файлі або каталозі, вибрати пункт Properties.
У діалоговому вікні Properties натисніть на закладці File Security, а потім на кнопці Edit. З'явиться діалогове вікно Authentication Methods (див. Екран 1).
Після того, як буде встановлено прапорець Anonymous access, користувачі зможуть звертатися до сторінок, яким призначено цей режим аутентифікації.

Екран 1. Дозвіл анонімного доступу.

Перш ніж розпочати захист веб-сторінок за допомогою пароля, слід розмістити захищені файли на диску NTFS. Необхідно переконатися, що wwwroot, як і всі віртуальні каталоги, захищені паролем IIS, розташований на томі NTFS. Щоб захистити паролем файли та програми, слід виконати такі дії.

Наступний крок – встановити повноваження IIS для доступу ззовні. Для цього потрібно відкрити MMC, а потім розгорнути Servicesand Applications, Internet Information Services і Web-узел, який передбачається захистити паролем. Клацнувши правою кнопкою миші на каталозі або файлі, що захищається, слід вибрати пункт Properties. Щоб заборонити анонімний доступ для всіх файлів каталогу, клацніть правою кнопкою на каталозі в лівій панелі MMC, а потім вибрати Properties. Потім потрібно послідовно натиснути File Security та Edit. Щоб змусити IIS видати користувачеві діалогове вікно для введення пароля, слід скинути прапорець Anonymous Access у діалоговому вікні Authentication Methods, а потім встановити прапорець Basic authentication (password is sent in clear text) — базова автентифікація (пароль пересилання). Після того, як зроблено ці зміни, користувачі не зможуть отримати доступ до облікового запису IUSR_computername; відкриваючи файл чи каталог, їм доведеться автентифікувати себе.

Якщо користувачі реєструються в домені і працюють із Microsoft Internet Explorer (IE), можна призначити режими автентифікації Basic і Integrated Windows. В результаті автентифіковані користувачі IE одержують доступ, передаючи шифроване ім'я та пароль без виведення на екран діалогового вікна (користувачі Netscape отримають запит для введення імені та пароля). Але якщо захищена сторінка є вхідом у форму оновлення бази даних або захищеною програмою, то діалогове вікно на екрані послужить нагадуванням, що користувач вступає в контрольовану область. Діалогове вікно також не дасть скористатися чужим комп'ютером, автентифікованим у мережі, для доступу до сторінки або програми.

Завершуючи процес призначення пароля, слід запустити програму Local Security Policy на панелі керування Control Panel. Розгорнувши Local Policies, потрібно відкрити папку User Rights Assignment(Див. Екран 3), а потім двічі клацніть на записі Log on locally. Необхідно переконатися, що користувач або група користувачів, яким було надано доступ до захищених файлів, мають право Log on locally. Якщо користувач або група не представлені на екрані, потрібно натиснути на кнопку Add і вказати їх. Користувач або група з'являться у вікні Assigned To із призначеним параметром Local Policy Setting.

Екран 3. Надання повноважень Log on locally користувачам та групам.

Переваги IIS

Метод вбудованого IIS захисту має переваги перед обома програмними способами захисту Web-сторінок. При використанні такого методу порядок виконання сторінок не має значення, оскільки всі сторінки конфіденційні захищені. Крім того, користувачеві доводиться вводити пароль лише один раз, і немає необхідності задіяти сеансові файли cookie або відстежувати сеансові змінні. І нарешті, можна контролювати доступ за допомогою індивідуальних облікових записів, груп та засобів безпеки NTFS, а захищені сторінки не потрібно доповнювати спеціальними програмами чи файлами.

Примітка.Описані заходи захисту файлів та програм за допомогою пароля відносяться до систем Windows 2000 Server та Windows 2000 Advanced Server. Діалогові вікна та прапорці трохи відрізняються у разі Windows NT 4.0 та IIS 4.0. Наприклад, у IIS 4.0 після клацання правою кнопкою миші на файлі або каталозі, що захищається, слід вибрати Properties, Security, а потім клацнути на закладці Permissions. На цій закладці потрібно перевірити, чи має група Administrator повноваження Full Control, а потім видалити групи Everyone та IUSR_computername, як у випадку з IIS 5.0. Потім потрібно вказати користувачів та групи,які матимуть доступ до захищеного файлу, каталогу або додатку. Для каталогу, що захищається, слід встановити відповідні прапорці, що забезпечують поширення повноважень на файли та підкаталоги.

Примітка.Якщо робота ведеться в режимі Basic authentication with clear text, користувачі Netscape побачать діалогове вікно аутентифікації та зможуть ввести пароль. Безперечно, це ризиковано, оскільки пароль передається відкритим текстом. Я не рекомендую використовувати цей метод на серверах у загальнодоступних мережах.

Поділіться матеріалом з колегами та друзями