Java, ASP или Windows: как лучше защитить Web-страницы?

Многие администраторы сетей, на узлах которых содержатся конфиденциальные отчеты или страницы обновления базы данных с ограниченным доступом, сталкивались с необходимостью защитить доступ к Web-страницам или приложения на IIS-сервере с помощью пароля. Впервые решая эту задачу для узла сети, я потратил несколько дней на изучение существующих методов и образцов программ из Internet. Почти все программы были составлены на Java или JavaScript, а верный пароль хранился в файле пароля или в базе данных.

Во многих программах отсутствовали элементарные меры безопасности, а в некоторых пароль был даже указан непосредственно в исходном тексте. Опытный пользователь мог узнать пароль и получить доступ к странице, просто просмотрев исходный текст. Даже если на экране всплывает отдельное диалоговое окно JavaScript, достаточно щелкнуть правой кнопкой мыши на адресе URL защищенной страницы и выполнить операцию Save Target As, чтобы найти исходный текст любой программы. Сохранив файл на жестком диске, пользователи могут отредактировать страницу и просмотреть исходный текст.

Есть два способа защиты Web-страниц IIS 5.0 и IIS 4.0 с помощью пароля — программный и с использованием встроенных функций безопасности IIS. В данной статье рассказывается о двух программных методах: в одном из них используется JavaScript (или JScript, версия языка JavaScript фирмы Microsoft), а в другом — приложение Active Server Pages (ASP). Я расскажу о возможностях применения и недостатках, присущих каждому из методов, а также о том, как можно быстро и просто установить пароль, используя встроенные функции Windows 2000 и IIS 5.0.

Защита Web-страниц с помощью JavaScript

Обнаруженные мною сценарии Java-Script проверяют пароль, хранящийся в отдельном файле. Этот файл должен быть надежно защищен, чтобы пользователи не могли его прочитать напрямую. В некоторых программах файл доступен для чтения Anonymous, поэтому вызванный из браузера сценарий JavaScript может открыть и прочитать файл пароля. Исследовав исходный текст, пользователи могут ввести URL файла пароля в браузер и загрузить или вывести на экран его содержимое. В некоторых программах для шифрования пароля применяются функции JavaScript, но пользователи все же могут увидеть исходный текст и алгоритм. Этот метод не так уж плох, потому что большинство пользователей не станут тратить время на разгадывание пароля, даже зная алгоритм. Подпрограмма проверяет соответствие между введенным паролем и вычисленной контрольной суммой, поэтому сценарий никогда не показывает настоящего пароля. В сценариях есть отдельная функция, запрашивающая у автора страницы пароль, который используется для генерации контрольной суммы. Затем это число сохраняется в заголовке страницы в качестве переменной пароля.

Другую интересную возможность предоставляет файл JavaScript, для которого не нужно сохранять пароль в исходном тексте или отдельном файле. В такой программе паролем служит имя защищаемой страницы без расширения HTML. Этот подход применяется во многих сценариях Java-Script. В Листинге 1 показан образец сценария, состоящий всего лишь из восьми строк текста. Примерно столько же секунд потребуется взломщику для доступа к защищенной странице после ознакомления с исходным текстом сценария.

Многие сценарии JavaScript прекрасно подойдут для узла корпоративной сети, администратор которого хочет лишь помешать сотрудникам заглядывать на защищенные страницы. Но они не станут преградой для квалифицированных взломщиков при работе в Internet. Опытные хакеры моментально устранят защиту и даже могут поиграть с администратором в кошки-мышки, подсказав, как ее можно усилить. Защитить страницу с помощью сценариев JavaScript не составляет труда, поскольку большинство программ очень просты, но существует более надежный способ использования пароля для защиты Web-страниц в IIS.

Защита Web-страниц с помощью ASP

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

Второй вариант такого приложения содержит примерно 25 строк исходного текста; для предоставления доступа к странице при повторном посещении используются cookies-файлы. Одно из дополнительных преимуществ сеансовых cookies-файлов заключается в том, что в данном случае пользователь вводит пароль только один раз. Срок действия cookies-файлов можно ограничить, чтобы предотвратить доступ с использованием пароля, сохраненного в кэше. Пароль встраивается в серверные программы ASP, а не в cookies-файл. Чтобы другие пользователи общего компьютера не могли получить доступ к странице, срок действия cookies-файлов можно сократить.

В Листинге 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 с сохранением пароля в базе данных.

Последняя мера предосторожности — позаботиться о том, чтобы пользователям было непросто обойти страницы аутентификации. Это значит, что страницы, не имеющие форм, пересылаемых самим себе, должны исполняться упорядоченно. Чтобы предотвратить обход, следует использовать сеансовые переменные или сеансовые cookies-файлы. С их помощью можно сделать так, чтобы страница устаревала немедленно и для задания немедленного устаревания страницы программа ASP выполнялась при каждом обращении к странице. Если этого не сделать, следующий пользователь сможет получить доступ к экземпляру страницы из кэша. Кэширование — один из недостатков сеансовых переменных: сеанс остается активным до тех пор, пока не будет закрыто окно браузера. Любой пользователь через это окно может получить доступ к защищенной странице.

Встроенные функции защиты Windows и IIS

Образцы программ JavaScript и ASP легко применить на практике, но так же просто защитить страницы Web-сайта при помощи встроенных функций безопасности Windows и IIS. Затратив всего несколько минут, можно защитить избранные страницы, применив учетные записи пользователей и пароли из локальной базы данных SAM. При работе с Windows 2000 можно использовать и объекты user из Active Directory (AD). Встроенные функции безопасности файловой системы Windows решают все проблемы защиты страниц или файлов и упорядоченного выполнения страниц.

Методы аутентификации назначаются из консоли Microsoft Management Console (MMC). Требуется выполнить следующие действия.

  1. Открыть MMC.
  2. Щелкнув правой кнопкой мыши на всем узле, файле или каталоге, выбрать пункт Properties.
  3. В диалоговом окне Properties щелкнуть на закладке File Security, а затем на кнопке Edit. Появится диалоговое окно Authentication Methods (см. Экран 1).
  4. После того как будет установлен флажок Anonymous access, пользователи смогут обращаться к страницам, которым назначен данный режим аутентификации.
Экран 1. Разрешение анонимного доступа.

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

  1. Щелкнуть правой кнопкой мыши на файле или приложении, которое нужно защитить, а затем выбрать пункт Properties.
  2. Щелкнуть на закладке Security.
  3. Ввести пользователя или группу пользователей, нуждающихся в доступе к ресурсу. Назначить пользователям или группе право Read (или Read & Execute, если ресурс представляет собой приложение).
  4. Удалить группу Everyone, пользователя IUSR_computername и любых других пользователей, которым следует запретить доступ (если нужно защитить виртуальный каталог, то перед удалением группы Everyone необходимо добавить группу Ad-ministrator). На экране появится диалоговое окно с сообщением, что данный пользователь не может быть удален, так как объект наследует полномочия от родителя. Нужно снять флажок Allow inheritable permissions from parent to propagate to this object (разрешить распространение наследуемых полномочий от родителя на данный объект), показанный на Экране 2.
  5. Система выдаст запрос, следует копировать ранее унаследованные права или удалить их. Поскольку удаляются все пользователи и группы, кроме группы Administrator, нужно выбрать Copy.
  6. Прежде чем окно Security будет закрыто, следует убедиться, что используемая для управления ресурсом учетная запись имеет права Full Control, иначе можно потерять контроль над элементом. Чтобы распространить параметры на все содержимое каталога и на все подкаталоги, необходимо удостовериться, что параметры могут быть переданы на все дочерние объекты.
Экран 2. Добавление и удаление пользователей из групп.

Следующий шаг — установить полномочия IIS для доступа извне. Для этого нужно открыть MMC, затем развернуть Services and 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 пользователям и группам.

Процедура назначения пароля завершена, и теперь можно испытать защиту, обеспечиваемую диалоговым окном. Необходимо удостовериться, что все конфиденциальные страницы — не только страница меню для ввода пароля — защищены от просмотра пользователем, не имеющим соответствующих прав. Если страница меню связана со страницей формы базы данных, а ее URL известен пользователю, то он может перейти на страницу формы без аутентификации.

Чтобы упростить администрирование защищенных страниц, следует создать группу, объединив в ней всех авторизованных пользователей. Можно также предоставить доступ только одной учетной записи, а затем назначить ее имя и пароль группе или подразделению пользователей. Кроме того, можно запретить кэширование паролей в IE, чтобы пользователи не могли установить флажок Save this password in your password list (сохранить этот пароль в списке паролей). Данная процедура описана в статье Microsoft «How to Disable Internet Explorer Password Caching» (http://support.microsoft.com/support/ kb/articles/q229/9/40.asp).

Преимущества IIS

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

Ли Вольф — консультант из компании Compaq Computer Customer Services, специализирующийся на Windows 2000 и Windows NT, IIS. Имеет сертификаты Master CIW, CNE, Compaq Master ASE, MCSE и MCSE+Internet. С ним можно связаться по адресу: lee.wolfe@compaq.com.

Примечание. Описанные меры защиты файлов и приложений с помощью пароля относятся к системам 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 увидят диалоговое окно аутентификации и смогут ввести пароль. Безусловно, это рискованно, так как пароль передается открытым текстом. Я не рекомендую применять данный метод на серверах в общедоступных сетях.