Коммерческие сайты, особенно сайты электронной коммерции, требуют регулярного обновления информации о ценах на продукты, о специальных предложениях или нуждаются в интерактивных веб-страницах, структура которых зависит от запроса, полученного веб-сервером. Динамическое или активное содержимое позволяет изменять страницы для отображения результатов поиска или вывода информации, взятой из базы данных. На HTML-страницах можно разместить сложные объекты – фильмы и Java-апплеты. Динамическое содержимое "оживляет" сайты, делает их более интересными и успешными. Активное содержимое обеспечивает индивидуальный подход к каждому пользователю. Однако с точки зрения безопасности статический сайт более защищен, так как активное содержимое требует наличия еще одной службы IIS, что ведет к появлению новых уязвимых мест.

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

В IIS при автоматическом создании веб-страниц данные передаются другому приложению для обработки, после чего они возвращаются на веб-страницу (например, номер подтверждения заказа). Метод передачи данных в прямом и обратном направлениях между сервером и приложением называется общим шлюзовым интерфейсом (CGI), и основополагающим механизмом CGI является HTTP. К сожалению, мощь и функциональные возможности этой технологии негативно влияют на общую безопасность, так как они в буквальном смысле создают шлюз на вашем сервере. CGI функционирует независимо, и защита IIS на него не распространяется.

Администратору IIS необходимо реализовать доставку активного содержимого, причем не в ущерб безопасности сервера IIS; этим вопросам и посвящена данная лекция.

Технологии активного содержимого

CGI, ASP и Perl являются самыми распространенными технологиями, используемыми в IIS для обеспечения активного содержимого. ASP (Активные страницы сервера) является технологией серверной части, разработанной Microsoft, которая позволяет комбинировать HTML, сценарии и компоненты многоразового пользования ActiveX или COM для создания динамических веб-страниц. Решение о создании генерируемого сервером содержимого в IIS принимается веб-разработчиками. Давайте рассмотрим создание ASP с помощью CGI.

Общий шлюзовой интерфейс

Технология CGI представляет собой мощную систему, на компьютерах UNIX с ее помощью создается веб-содержимое в реальном времени. Однако каждое приложение является скомпилированной программой, и поэтому каждый раз после внесения изменений требуется перекомпиляция исполняемого файла. Для этого разработаны языки сценариев серверной части, интерпретируемые и исполняемые машиной сценариев с результирующими выходными данными, отправляемыми в приложение веб-сервера через CGI.

Сценарии CGI используются для расширения возможностей веб-серверов, чаще всего для обработки форм. Сценарий выступает в роли моста между ресурсом и сервером; ресурсом в данном случае является объект, обеспечивающий работу службы, например, программа электронной почты или база данных. Сценарий переводит предоставляемую ресурсом информацию в HTML-формат, чтобы сделать ее читабельной для запрашивающего браузера. Это расширяет возможности веб-сервера для обработки информации из всевозможных источников, расположенных на различных узлах.

Информация передается приложению CGI посредством указания имени приложения в адресе URL. Например:

Здесь URL указан в виде части тега FORM. После получения данных формы сервер ваш_сервер.com передаст управление приложению CGI (в данном случае это интерпретатор Perl, обозначенный файловым расширением .pl), которое обработает сценарий processorder.pl и запрос, после чего вернет страницу, созданную на базе полученных из формы данных.

IIS обеспечивает поддержку сценариев и программ CGI, однако предлагает более интегрированные технологии по работе с динамическим содержимым. IIS поддерживает интерфейс программирования серверных приложений ISAPI для более эффективной работы исполняемых файлов по сравнению со стандартным приложением CGI. ISAPI обеспечивает расширенный доступ к пространству памяти IIS по сравнению с простыми функциями stdin и stdout, на которых основаны многие технологии, например, Perl. Вследствие этого реализуется связь ASP с IIS через интерфейс ISAPI. Сценарии ASP могут непосредственно добавляться в HTML-страницы и выполнять все действия, реализуемые сценариями CGI. Рассмотрим технологию ASP и способы безопасной работы активного содержимого.

Активные страницы сервера (ASP)

Страницей ASP является HTML-страница, содержащая один или более сценариев, обрабатываемых IIS перед передачей пользователю. ASP взаимодействует с IIS через ISAPI и asp.dll (динамически подсоединяемая библиотека ASP), которые являются сопровождающими приложениями в том же пространстве памяти, что и IIS. Это обеспечивает малое время реагирования, так как asp.dll имеет прямой доступ к значениям памяти IIS. Asp.dll выполняется с привилегиями учетной записи IWAM_имя-компьютера. IIS настроен на использование ASP по умолчанию, поэтому для создания динамического содержимого не нужно устанавливать дополнительное программное обеспечение.

Совет. ASP также является сокращением от Application Service Providers (Поставщики услуг приложений). Они обеспечивают управление компьютерными услугами из удаленных центров через интернет или частную сеть.

ASP вызывает компоненты Component Object Model (COM) для обеспечения лучшей функциональности с помощью обработки ресурсов серверной части, однако эта возможность представляет угрозу безопасности. Следует отключить или удалить все ненужные для работы сайта компоненты COM, например, File System Object (Объект файловой системы), предоставляющий веб-приложениям доступ к жестким дискам. Для отключения File System Object выполните следующую команду:

Для получения более подробной информации о приложениях COM используйте апплет Component Services (Службы компонентов) из папки Administrative Tools (Администрирование).

Совет. Технология COM в интернете известна как ActiveX – программная архитектура, позволяющая создавать приложения из программных компонентов многоразового использования. Метод создания и использования компонентов формирует базу для высокоуровневых программных служб, таких как OLE (сокр. от object linking and embedding – связывание и внедрение объектов), обеспечивающих межпрограммное использование сценариев и передачу данных.

Директивы вставок серверной части (SSI)

Серверная часть представляет собой ограниченный тип приложения CGI. На самом деле ASP распознает элементы SSI просто в виде инструкции при обработке файла. На странице ASP можно использовать инструкцию #include для замещения этой инструкции содержимым другого файла. Следующая строка кода обеспечивает включение файла postalrates.inc в нужное место:

Для обработки директивы SSI #include используется библиотека ssinc.dll, а затем asp.dll интерпретирует всю страницу. Это очень удобно при повторном использовании нескольких строк кода на различных страницах. Microsoft рекомендует применять вставку файлов для облегчения работы с ним, так как в этом случае для изменения кода на нескольких страницах требуется изменение только одной. Однако при открытии файла вставки непосредственно в браузере злоумышленник получит доступ к исходному коду, так как файлы вставок не обрабатываются ASP. Для предотвращения этого следует либо связать файлы вставок с расширением .inc с ASP, либо переименовать их, указав расширения .asp, чтобы обеспечить выполнение всего кода сценариев и возврат в веб-браузер только результатов обработки. (Обратитесь к разделу "Совместимость с приложением" в этой лекции.)

IIS поддерживает пять директив SSI:

Нельзя применять эти директивы на странице ASP. Вместо этого используйте одно из специальных расширений HTML, по умолчанию настроенных на употребление директив SSI в IIS: .stm, .shtm и .shtml. На защищаемом сервере директива #exec должна быть отключена, так как она позволяет выполнять программы командной строки или CGI в контексте веб-сервера в отдельном пространстве памяти. IIS по умолчанию отключает эту директиву, но следует убедиться, что следующий параметр реестра установлен на нуль (или отсутствует): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters\SSIEnableCmdDirective.

ActivePerl

Технология ActivePerl разработана фирмой ActiveState и доступна бесплатно на сайте http://www.activeperl.com/. Perl является популярным языком программирования, в особенности среди разработчиков для платформы UNIX. Windows-версия ActivePerl обеспечивает дополнительные возможности платформы IIS – PerlScript и Perl для ISAPI. Рекомендуется использовать ActivePerl при перемещении веб-сайта с сервера UNIX или по желанию разработчиков.

ASP взаимодействует с IIS через ISAPI и ASP DLL, а Perl использует интерпретатор – комбинированный исполняемый файл Perl.exe. Perl.exe работает как независимое приложение, используя дополнительные ресурсы сервера при каждом его вызове веб-сервером для обработки запроса, что снижает эффективность. При возникновении ошибки внутри сценария веб-сервер будет ожидать истечения срока запроса, так как он не может контролировать Perl. А сценарий CGI тем временем продолжит использование системных ресурсов и в конечном итоге вызовет сбой в работе сервера (сам Perl не влияет на работу веб-сервера).

В отличие от большинства версий Perl PerlScript позволяет внедрять теги сценариев непосредственно в веб-страницу, аналогично VBScript в страницах ASP. При установке ActivePerl выберите инсталляцию Perl для ISAPI, чтобы ActivePerl выполнялось как приложение ISAPI, аналогично ASP.

Совет. Ознакомьтесь с бесплатными безопасными сценариями Perl, которые обеспечивают нужную функциональность и предотвращают возникновение пробелов в безопасности, на веб-сайте http://superscripts.com/resources.

Структура папок для активного содержимого

В лекции 4 говорилось о настройке разрешений Windows NTFS для веб-сайтов, папок и отдельных файлов для контроля доступа пользователей к веб-содержимому. Вместо установки разрешений на каждый файл легче и безопаснее создать папки для файлов определенных типов, например, для статического содержимого или сценариев. Хорошо продуманная структура каталогов веб-сайта упрощает управление разрешениями веб-содержимого, так как они устанавливаются на уровне папки. Для стандартного веб-сайта создайте следующие папки (см. лекцию 3).

Такая структура сайта не обязательно является образцом для веб-дизайнеров, однако с точки зрения безопасности мы рекомендуем именно этот подход.

Важно. На разрабатываемом сервере используйте неинформативные имена папок со сценариями и исполняемыми файлами.

Разрешения файлов сценариев

После создания папок для веб-содержимого установите разрешения для каждой папки. Ниже приведены рекомендуемые настройки разрешений NTFS для структуры папок:

Параметры приложения

Для разрешения выполнения сценариев на сервере нужно настроить параметры приложения IIS на главном уровне, уровне сайта или уровне виртуального каталога. Приложением IIS является любой файл (набор файлов), реализующий некоторую функцию и выполняющийся внутри определенных папок веб-сайта, используя границы папки для определения области действия приложения. Каждый файл или папка, находящиеся в "стартовой" папке веб-сайта, являются частью приложения, пока не будет найдена другая стартовая папка. С одним веб-сайтом можно связать несколько приложений. Приложение распределяет информацию среди своих файлов. Например, приложения ASP распространяют информацию о контексте, состоянии сеанса и настройке переменных среди страниц приложения.

Стартовые точки приложения

В консоли Internet Services Manager (Диспетчер служб интернета) значок коробки (см. рис. 11.1) означает стартовую точку приложения с подкаталогами, являющимися частью приложения.

Веб-сайт по умолчанию, созданный при установке IIS, представляет собой стартовую точку приложения или корень приложения (см. рис. 11.2). Используйте Internet Services Manager (Диспетчер служб интернета) для назначения каталога стартовой точке приложения. Для этого откройте окно главных свойств, веб-свойств или свойств виртуального каталога щелчком правой кнопкой мыши на соответствующем объекте в ISM, затем выберите пункт Properties во всплывающем меню, затем – вкладку Home Directory (Домашний каталог). IIS поддерживает приложения ASP, ISAPI, CGI, IDC (Internet Database Connector) и SSI.

Разрешения на выполнение

Если сайт состоит только из статического содержимого, убедитесь в том, что в ниспадающем меню Execute Permissions (Разрешения на выполнение) выбран параметр None (Нет) в окне Default Web Site Properties (Свойства веб-узла по умолчанию). Для разрешения выполнения связанного со сценариями приложения (например, ASP) выберите параметр Scripts Only (Только сценарии). Не выбирайте опцию Scripts And Executables (Сценарии и исполняемые файлы), если на сервере не нужно выполнять исполняемые файлы.

Существует разница между разрешениями веб-сервера и разрешениями NTFS. Разрешения веб-сервера применимы ко всем пользователям, осуществляющим доступ к сайту.

Разрешения NTFS применяются только к определенному пользователю или группе пользователей с корректными учетными записями Windows, они определяют доступ к физическим каталогам на сервере; веб-разрешения управляют доступом к виртуальным каталогам на веб-сайте. Они применяются ко всем пользователям независимо от их прав доступа. Например, установка разрешения Read (Чтение) на виртуальный каталог позволяет его просматривать, если разрешения NTFS не налагают ограничения на этот просмотр.

По умолчанию учетная запись анонимного пользователя (IUSR_имя-компьютера) наделяется разрешениями NTFS для папок, из которых состоит веб-сайт. Если веб-разрешения и разрешения NTFS для каталога или файла отличаются, то используются параметры с большей степенью ограничения.

Безопасность приложения

IIS предоставляет три возможных процесса для выполнения приложения.

• Процесс, используемый веб-службами (Inetinfo.exe).
• Объединенный процесс, являющийся отдельным вхождением DLLHost.exe.
• Процесс, отдельный от веб-служб (DLLHost.exe).

Они обеспечивают различные уровни защиты. При возникновении ошибки в приложении процесс, в котором оно выполняется, перестает отвечать на запросы. По умолчанию inetinfo.exe выполняется в своем собственном процессе, а другие приложения – в одном и том же объединенном процессе. Необходимо найти оптимальное соотношение между производительностью и уровнем защиты приложения. Приложения, выполняющиеся в веб-службах, обрабатывают результат с большей производительностью, но и с большей вероятностью того, что неправильно функционирующее приложение сделает недоступными веб-службы. Следовательно, inetinfo.exe выполняется в собственном процессе, жизненно важные приложения – в своих процессах (высокий уровень безопасности), остальные приложения – в объединенном процессе (средний уровень безопасности).

Совместимость с приложением

Для вызова нужного интерфейса ISAPI или программы CGI при обработке определенных типов файлов их расширения связываются с соответствующими программами. При получении сервером адреса URL, обозначающего файл со связанным расширением, сервер вызовет связанную с файлом программу для обработки запроса. IIS изначально настроен на поддержку общих связей с приложениями. Для корректной работы сценариев нужно добавить или изменить связи между файловыми расширениями и программами/интерпретаторами, которые их обрабатывают. (Необходимость устранения любых ненужных связей обсуждалась в лекции 3 и лекции 10.)

Связи с приложением устанавливаются в стартовой точке приложения на вкладке App Mappings (Связь с приложениями) окна Application Configuration (Настройка приложения). Выполните следующие действия.

1. Откройте Internet Services Manager (Диспетчер служб интернета) и выберите веб-сайт или папку стартовой точки приложения.
2. Откройте окно Properties (Свойства), щелкнув правой кнопкой мыши на объекте и выбрав команду Properties.
3. Откройте вкладку Home Directory (Домашний каталог), Virtual Directory (Виртуальный каталог) или Directory (Каталог).
4. Нажмите на кнопку Configuration (Настройка) для открытия окна Application Configuration (Настройка приложения) и откройте вкладку App Mappings (Связь с приложениями) (см. рис. 11.3). На рисунке 11.3 показано, что IIS вызовет программу Perl.exe для обработки любых запросов с файловыми расширениями .pl.
5. Для добавления связи с приложением нажмите на кнопку Add (Добавить). Откроется диалоговое окно Add/Edit Application Extension Mapping (Добавить/Изменить связь приложения с расширением) (см. рис. 11.4).
6. В поле Executable (Исполняемый файл) введите путь к нужной программе ISAPI или CGI (.exe или .dll). Она должна располагаться в локальном каталоге на веб-сервере.
7. В поле Exstension (Расширение) введите файловое расширение для связи с программой, указанной в поле Executable (Исполняемый файл). В окне на рисунке 11.4 добавлен тип файлов .inc.

    

   
   
   Рис. 11.3.  Убедитесь в том, что установлены связи только с теми приложениями, которые используются IIS

    

    

    

   
   
   Рис. 11.4.  Обеспечьте выполнение кода, содержащегося в файлах вставки, перед отправкой клиенту, установив связь файлов .INC с ASP

    

    
8. Укажите команды, которые можно передавать приложению. Не выбирайте опцию All Verbs (Все команды), а добавьте только разрешенные команды в поле Limit To (Разрешить). Для ASP разрешите команды HTTP GET, HEAD и POST, указав их через запятую. Если все сценарии размещены в одной папке, не выбирайте опцию Script Engine (Машина сценариев). Эта опция требуется для выполнения приложений в папке без разрешений Execute (Выполнение), что существенно ослабляет контроль над разрешениями.

   Совет. Обратитесь к разделу "Инструмент безопасности URLScan" в этой лекции для получения подробной информации о том, какие команды необходимо разрешать для работы отдельных приложений.

9. Отметьте опцию Check That File Exists (Проверить наличие этого файла), чтобы IIS проверял наличие запрошенного файла сценария и разрешение на доступ к нему. Если сценарий не существует, или пользователь не имеет соответствующего разрешения, то в браузере отобразится сообщение с предупреждением, и механизм обработки сценариев не запустится. Эта опция полезна для сценариев, связанных не с CGI-программами, а, например, с интерпретатором Perl, который не отправляет ответ CGI в случае недоступности файла сценария. Так как сценарий открывается дважды – сервером и машиной сценариев – произойдет некоторое снижение производительности.

Для удаления связи с приложением выберите расширение файла на вкладке App Mappings (Связь с приложениями) и нажмите на кнопку Remove (Удалить).

Управление исходными файлами

Для предотвращения случайного изменения файлов веб-разработчиками необходимо контролировать исходные файлы. Например, если файл вставки удален или перемещен без страниц, которые обновлялись с использованием этого файла, то при доступе к этим страницам возникнет ошибка, и откроется доступ к информации о системе.

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

Программное обеспечение для контроля над исходными файлами

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

Программное обеспечение, предназначенное для контроля над исходными файлами, можно интегрировать с IIS, если установлены серверные расширения FrontPage Server Extensions (FPSE). FPSE представляет собой набор программ и сценариев, поддерживающих разработку в FrontPage (популярный редактор веб-страниц от Microsoft) и расширяющих функциональные возможности IIS. Для установки FPSE прочтите раздел "Серверные расширения FrontPage" далее в этой лекции. Не рекомендуется устанавливать FPSE на веб-серверах.

Если расширения FPSE установлены, включите контроль версий файлов.

1. Откройте консоль Internet Services Manager (Диспетчер служб интернета) и в дереве консоли щелкните правой кнопкой мыши на веб-объекте, для которого включается контроль исходных файлов.
2. Во всплывающем меню выберите Properties (Свойства), после чего откройте вкладку Server Extensions (Серверные расширения) (см. рис. 11.5).

    

   
   
   Рис. 11.5.  Отслеживайте редактирование веб-содержимого с помощью включения контроля версий

    

    
3. Отметьте опцию Enable Authoring (Включить разработку) и в поле Version Control (Контроль версий) выберите Use External (Использовать внешнюю программу) при наличии программы контроля над исходными файлами (например, Visual SourceSafe) или Use Built-In (Использовать встроенную программу) для использования базового контроля FrontPage.

Программа Visual SourceSafe (см. рис. 11.6) представляет собой приложение уровня предприятия для контроля над изменением исходных файлов; она дополнительно обеспечивает отслеживание версий и функции отката. Для получения информации об интеграции Visual SourceSafe с программой FrontPage обратитесь к разделу "Контроль исходных файлов серверных расширений" в Microsoft FrontPage Server Extensions Resource Kit.

FrontPage предоставляет два метода контроля над исходными файлами: встроенную упрощенную функцию контроля и интеграцию с внешней программой, совместимой с FrontPage (например, Visual SourceSafe). Упрощенный контроль над исходными файлами обеспечивает меры по контролю над пользователями, управляющими страницами веб-сайта с функциями приписки и отписки. Перед использованием этого компонента FrontPage на IIS необходимо установить FPSE.

Резервные копии

В зависимости от используемого средства разработки проверьте, не засорена ли система файлами .bak. Такие средства, как Microsoft Visual InterDev и Allaire HomeSite, создают резервные копии содержимого в автоматическом режиме. Если разработчикам разрешено сохранение работы непосредственно на сервере (настоятельно не рекомендуется), резервные файлы с расширением .bak также будут сохраняться на сервере. Любой пользователь, открывший один из .bak-файлов, сможет прочесть весь текст сценария и просмотреть исходный код, так как IIS не будет обрабатывать страницу, и теги сценариев останутся нетронутыми. Поэтому убедитесь, что .bak-файлы удаляются каждый раз при завершении обновления файлов разработчиками, и свяжите их с машиной сценариев, чтобы обеспечить выполнение страниц и отправку клиенту только результатов этой работы.

Защита авторских прав

Иногда в интернете попадаются сайты с предупреждениями о том, что копирование содержимого сайта запрещено. Часто для защиты авторских прав используются скрываемые панели инструментов веб-браузера и панели инструментов перехода, а также сценарии JavaScript, отключающие всплывающие меню. Тем не менее, для опытных пользователей эти методы защиты авторских прав являются не только раздражающими, но и легко преодолимыми при помощи целого ряда способов.

Совет. Если вы добавляете в свой код уведомление об авторских правах, то в любом судебном процессе это облегчит доказательство того, что результат вашего труда был скопирован нелегально. Для получения дополнительной информации обратитесь к разделу "Кодировщик сценариев" далее в этой лекции.

Следует всегда добавлять строку уведомления об авторских правах внизу каждой веб-страницы. Например, "© 2002, ваше_имя/компания. Все права защищены". Эту строку можно добавить, выбрав опцию Enable Document Footer (Включить нижний колонтитул документа) на вкладке Documents (Документы) окна Properties (Свойства) веб-сайта (см. рис. 11.7). IIS будет автоматически прилагать нижний колонтитул ко всем отправляемым страницам, хотя это несколько снизит производительность.

Совет. Следует регистрировать авторские права для имен доменов, связанных с сайтом; зарегистрировать сайт целиком можно в офисе авторских прав США по адресу http://lcweb.loc.gov/copyright/.

Проверка вводимых пользователем данных

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

В языке HTML для отличия текста от тегов разметки используются некоторые символы. Например, символ "меньше чем" ("<") означает начало тега HTML. Когда веб-браузер считывает символ "<", он осуществляет поиск корректного тега HTML, располагающегося после этого символа. Если на странице HTML требуется отобразить сам символ "<", разработчику нужно заменить "<" на <.

Теги могут либо управлять форматом содержимого страницы, либо представлять программу для выполнения (например, тег <SCRIPT> представляет код различных языков сценариев). Хакер может вставить в поле формы вредоносный код вместо ожидаемого содержимого. Например, вместо указания адреса электронной почты в гостевой книге веб-сайта ввести следующий код:

Если код не будет проверен, то сценарий возвратит эти данные каждому пользователю, просматривающему комментарии посетителей в гостевой книге, и отобразит гиперссылку: "Щелкните здесь – специальное предложение". Пользователь, щелкнувший на этой ссылке, перенаправится на сайт www.плохой_сервер.com. Все будет выглядеть так, будто вредоносный код поступил с вашего сайта. При отправке и отображении вредоносного сценария (так называемая "подстановка сценариев") хакер потенциально может захватить управление сайтом.

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

Фильтрация вводимых данных

Вводимыми данными называются данные, передаваемые сценариям для обработки; они обычно поступают из веб-формы, из базы данных или из другого источника. Фильтрация ввода работает посредством удаления специальных символов из вводимой информации, которые позволяют генерировать сценарий в потоке данных HTML. Ниже приведены специальные символы:

Конкретная ситуация может потребовать фильтрацию дополнительных символов, помимо указанных.

Проверка клиентской части

IIS передает данные, отправленные веб-формой, сценариям для обработки, и первой возможностью проверки и фильтрации этих данных является веб-браузер пользователя. Эта проверка называется проверкой клиентской части. Она реализуется с помощью сценариев JavaScript, так как они могут выполняться и в Internet Explorer, и в Netscape. Эта проверка подтверждает, что данные, обрабатываемые сценарием, действительно введены в полях формы. В примере функция JavaScript проверяет ввод номера телефона в поле формы с именем Telephone:

Данные, введенные в поле формы Telephone, проверяются перед отправкой на сервер посредством вызова функции ValidateFormData в методе onSubmit формы следующим образом:

Следующий фильтр, написанный на JavaScript, является примером того, как следует удалять специальные символы:

Еще одним способом контроля вводимых данных является указание предельного размера данных в полях ввода; это ограничение устанавливается добавлением атрибута MAXLENGTH в теги ввода текста. Например, если поле предназначено для ввода восьмизначного числа, следует ограничить вводимые пользователем данные:

Такая блокировка усложняет хакеру задачу по вводу вредоносного кода. Тег <applet></applet> или <script></script> сам по себе занимает 17 символов.

Проверка клиентской части вводимых данных предотвращает их ненужную обработку, если пользователь допустил ошибку. Однако эта проверка не является столь же функциональной, как проверка серверной части. При использовании сценариев для получения вводимых данных <TEXT> из формы HTML их тип неизвестен, и некоторые символы, в обычной ситуации отбрасываемые фильтром, могут оказаться приемлемыми.

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

Элементы управления проверкой ASP.NET. Так как проверка вводимых пользователем данных очень важна с точки зрения безопасности, ASP.NET (последняя версия ASP от Microsoft для платформы .NET) обеспечивает серверные элементы управления, проверяющие вводимые пользователем данные и отображающие сообщения об ошибках при обнаружении некорректных данных. Элементы управления обычно выполняют проверку в коде сервера либо, при работе с веб-браузером, поддерживающим DHTML, – и на клиенте.

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

При передаче адреса электронной почты неправильного формата отображается содержимое ErrorMessage. ASP.NET предоставляет целый набор подобных элементов управления, связанных с безопасностью. В случае переноса сайта на ASP.NET разработчики должны уметь применять эти дополнительные меры безопасности в коде, с которым они работают.

Проверка серверной части

Сценарий должен проверять и очищать данные перед их обработкой, что обеспечит удаление всех некорректных данных и правильное выполнение кода. Очень важно реализовать проверку серверной части, так как некоторые данные передаются внутри самого URL, который не проверяется на клиентской части. Для проверки данных используются и более мощные алгоритмы. Язык сценариев VBScript версии 5.0 и выше работает с регулярными выражениями с целью фильтрации и очистки входящих данных. Посредством создания шаблонов, соответствующих конкретным строкам, осуществляется поиск и замена введенных пользователем данных для проверки их на наличие черт вредоносного характера. Синтаксис шаблона VBScript заимствован из языка Perl.

Следующий пример кода выполняет удаление всех символов, не лежащих в диапазонах 0 – 9, a – z, A – Z и не являющихся пробелом, из строки strTainted:

Совет. Для получения более подробной информации о написании общих регулярных выражений с помощью VBScript посетите страницу http://msdn.microsoft.com/workshop/languages/clinic/scripting051099.asp. Общая информация о сценариях Windows находится по адресу http://msdn.microsoft.com/scripting/.

При запросе сценарием информации из базы данных, скорее всего, осуществляется сохранение процедуры. Общий объем данных, переданных сохраненным процедурам, не должен превышать установленный максимум. Все отправляемые запросы нужно проверить на превышение максимально допустимого размера.

Данные, передаваемые базе данных, должны проходить фильтрацию. Злоумышленник в запросах SQL может отправить групповые символы ("%" и "_"), разрешенные в выражениях SQL, и получить все записи из таблицы SQL. Осуществляйте фильтрацию этих символов в любых вводимых пользователем запросах к базе данных.

Кодировка HTML

IIS передает документ HTML веб-браузеру в виде потока байтов, а браузер воспринимает их как последовательность символов. Для правильного отображения этого потока все HTML-страницы и страницы с активным содержимым должны содержать дополнительную информацию о кодировке символов. Если в страницах не будет указана используемая кодировка, веб-браузер отформатирует их некорректно, и на странице может выполниться вредоносный код. Так как наборы символов имеют несколько представлений, применяемых в виде тегов HTML (например, "<" или ">"), фильтр может исключать не все вхождения символов, в результате чего вредоносный код останется незамеченным.

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

Чтобы установить кодировку символов на веб-странице, необходимо включить в код страницы тег МЕТА, который должен стоять как можно выше в коде страницы, по возможности сразу после тега <HEAD>. В этом примере веб-браузер будет использовать для отображения страницы кодировку ISO-8859-1:

Широко используемыми в интернете кодировками являются: ISO-8859-1, называемая Latin-1 (данная кодировка подходит для большинства языков с латинским алфавитом), ISO-8859-5, поддерживающая кириллицу, SHIFT_JIS или EUC_JP (представляют японский язык). Многие HTML-редакторы автоматически добавляют данный тег, полагая, что это очередное ненужное добавление, сделанное редактором. При изменении этого тега следует принимать во внимание территориальное расположение страниц.

Кодировка выходных данных для специальных символов

Все входные данные нужно кодировать при записи в виде HTML. Этот подход частично эффективен для тех данных, которые нельзя быстро проверить при вводе. Представьте себе, что в базе данных отсутствует контроль над процессом ввода информации. Недовольный зарплатой сотрудник организации может ввести вредоносный код в поле базы данных, который отобразится при вызове из сценария. Большая часть языков сценариев содержит функцию кодировки, например, методы объекта сервера ASP HTMLEncode и URLEncode. Разработчики должны помнить об этой форме кодировки серверной части и применять ее в тех местах, где это требуется. Такой подход аналогичен фильтрации за исключением того, что здесь кодируются данные, записываемые для отправки клиенту. Более подробная информация об обработке вводимых данных расположена на сайте CERT по адресу www.cert.org/tech_tips/malicious_code_mitigation.html.

Перечень девяти аспектов безопасности, о которых должен знать разработчик

Убедитесь, что разработчики выполняют следующие девять правил при создании динамического содержимого для сервера IIS.

1. Указывать кодировку в начале каждой страницы.
2. Фильтровать и кодировать все данные формы. Разработчикам следует обратиться к материалу CERT за информацией о вредоносных тегах HTML по адресу www.cert.org/advisories/CA-2000-02.html, затем изучить следующие статьи базы знаний Microsoft Knowledge Base:
   • Q252985 HOWTO: Prevent Cross-Site Scripting Security Issues;
   • Q253119 HOWTO: Review ASP Code for CSSI Vulnerability.
    
3. Фильтровать и кодировать все данные cookie. Значения, считываемые из элементов cookie, не должны восприниматься как доверенное содержимое, поэтому они должны фильтроваться и кодироваться согласно пункту 2 данного перечня. Никогда не храните важную информацию в постоянных элементах cookie.
4. Использовать шифрование SSL для отправки и приема любой важной информации. Пароли, информация о кредитных картах и любые персональные данные идентификации должны передаваться только через защищенное SSL-соединение.
5. Отключить функцию автозавершения в Internet Explorer для полей паролей. Добавьте атрибут AUTOCOMPLETE=OFF в тег <FORM> или <INPUT> всех форм, используемых для запроса паролей. Например: <INPUT TYPE=password NAME=Password SIZE=16 MAXLENGTH=16 AUTOCOMPLETE=OFF>
6. Завершать сеансы после пятиминутного простоя. По умолчанию значение параметра Connection Timeout (Время простоя соединения) в IIS равно 900 секундам. Смените это значение на 300 секунд с помощью Internet Services Manager (Диспетчер служб интернета). В качестве альтернативы, если пользователи осуществляют вход на сайт, вводите следующий код вверху каждой страницы:
   <SCRIPT Language="JavaScript">
   <!--
   window.setTimeout("window.navigate('Logoff.asp')", 300000);
   //--></SCRIPT>
    
   Пользователи будут перенаправляться на страницу Logoff.asp после пяти минут отсутствия каких-либо действий.
7. Удалять из кода все комментарии. Хорошие разработчики всегда качественно комментируют создаваемый ими код, однако эти комментарии необходимо удалять на страницах, загружаемых на веб-сервер, потому что они могут стать подсказками для хакеров.
8. Использовать компонент COM+ для хранения информации о подключениях к базе данных. Многие разработчики сохраняют информацию о подключениях базы данных в файле global.asa. Эта информация содержит имя сервера, имя базы данных, имя пользователя и пароль базы данных, поэтому она должна быть защищена. Обратитесь к разделу "Parsing the COM+ Constructor String" по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnduwon/html/d5bizdev.asp для получения дополнительных сведений.
9. Использовать сохраненные процедуры для доступа к базе данных. Сохраненные процедуры обеспечивают больший уровень контроля над данными и производительностью работы SQL-выражений.

Фильтры ISAPI

Фильтры ISAPI отличаются от приложений тем, что они управляются событиями веб-сервера, а не запросами клиентов. Фильтр ISAPI закрепляется в системе и отслеживает определенные события при попытках клиентов открыть страницу на сервере. Приложение фильтра располагается между подключением к клиенту и серверу HTTP, что позволяет контролировать обмен данными между IIS и клиентом, а также расширять функциональные возможности сервера посредством реализации дополнительных журналов HTTP и шифрования. Работа фильтров ISAPI основывается на уведомлениях об этапах, которые проходит каждый запрос, передаваемый сервером IIS фильтру ISAPI. Каждое уведомление поддерживает собственный тип данных, соответствующий определенному этапу процедуры запроса. При приеме уведомления от IIS фильтр ISAPI управляет данными уведомления и способом дальнейшей обработки запроса IIS. Программа URLScan, о которой пойдет речь ниже, является примером использования фильтров ISAPI для повышения уровня безопасности IIS.

Важно. Если вы заключаете контракт со сторонними разработчиками для построения интранет-сайта или веб-сайта, или если на сервере используются готовые библиотеки ISAPI DLL, обратитесь к заметке "Проверки сторонних программ" в лекции 9.

Средство безопасности URLScan

URLScan представляет собой средство безопасности, работающее вместе с программой IIS Lockdown (см. лекции 3) и обеспечивающее отключение ненужных функций и ограничение типов HTTP-запросов, обрабатываемых IIS. Как и фильтр ISAPI, программа URLScan выявляет все входящие на сервер запросы и фильтрует их согласно установленным правилам. Посредством фильтрации всех необычных запросов программа запрещает доступ к серверу IIS потенциально опасных запросов и обеспечивает обработку только корректных. Для получения информации о настройке URLScan, о командах HTTP, которые необходимо разрешить для работы отдельных приложений, посетите страницу www.microsoft.com/technet/security/URLScan.asp.

Настройка фильтров ISAPI

Окно Properties (Свойства) фильтров ISAPI позволяет выбирать фильтры для работы на IIS (см. рис. 11.8). Фильтры ISAPI работают для всех веб-сайтов, так как они устанавливаются на главном уровне; они выполняются именно в том порядке, в котором перечислены в диалоговом окне. Можно установить глобальные фильтры для всех сайтов на сервере или фильтры только для отдельных веб-сайтов. Когда несколько фильтров зарегистрированы для обработки одного и того же события, они вызываются последовательно, причем в первую очередь – фильтры с более высоким приоритетом. Для добавления фильтра в консоли ISM выберите веб-сервер или веб-сайт, откройте окно Properties (Свойства) и откройте вкладку ISAPI Filters.

Совет. При добавлении фильтров для веб-сайта в окне Properties отобразятся только фильтры, установленные для данного веб-сайта, несмотря на то, что могут существовать глобальные фильтры, наследуемые из главных настроек веб-сервера.

Нажмите на кнопку Add (Добавить) и введите название фильтра в поле Filter Name (Имя фильтра). Найдите файл ISAPI DLL в поле Executable, после чего нажмите на OK. Для изменения порядка загрузки фильтров используйте кнопки со стрелками.

После добавления или изменения глобального фильтра необходимо остановить и перезапустить веб-сервер, чтобы загрузить новые фильтры в память. Фильтр, добавляемый на уровне веб-сайта, автоматически загружается после добавления.

Защита кода собственной разработки с помощью фильтра ISAPI

Большая часть сценариев JavaScript включается в веб-страницы или содержится в файле JavaScript (.js), и код сценариев доступен каждому пользователю, который просматривает исходный код файла. Как правило, это не представляет серьезной проблемы, однако что делать, если вы разработали свои собственные сценарии JavaScript, которые не должны быть доступны для просмотра? В этом случае следует использовать фильтр ISAPI.

Отслеживая уведомления OnUrlMap, фильтр ISAPI обеспечивает тот факт, что сценарий JavaScript серверной части будет доступен для чтения только серверу IIS. Когда IIS сопоставит логический путь устройства с физическим путем, произойдет вызов уведомления OnURLMap, что позволит фильтру ISAPI определить, кто осуществляет попытку чтения файла JavaScript. Если кто-либо попытается получить непосредственный доступ к файлу, фильтр заблокирует запрос, в то время как запрос на просмотр HTML-страницы, связанной со сценарием JavaScript, обработается в обычном порядке, так как он отправлен сервером IIS. Пример такого фильтра расположен на странице http://www.15seconds.com/issue/010104.htm. Этот метод обеспечивает доступ IIS только к файлам, содержащим системные пароли доступа к ресурсам, например, к базам данных. Следует избегать непосредственного указания паролей в общих сценариях.

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

Кодировщик сценариев

Одним из недостатков использования сценариев является то, что любые алгоритмы и код собственной разработки видны любому пользователю, которому разрешено редактировать файл, так как они хранятся в виде обычного текста. Этот недостаток в защите интеллектуальной собственности очень имеет большое значение, если вы предоставляете услуги веб-разработки другим пользователям или используете стороннюю помощь в поддержке сайта, так как у посторонних пользователей появляется возможность копирования кода. Кодировщик сценариев представляет собой простую утилиту командной строки, которую можно бесплатно загрузить с сайта http://msdn.microsoft.com/scripting/. Эта утилита позволяет кодировать сценарии серверной части, чтобы их исходный код был недоступен для просмотра или изменения.

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

Следующий пример кода на языке VBScript демонстрирует использование маркера для кодирования всего кода, кроме сообщения об авторских правах:

При выполнении кодировщика сценариев весь текст сценария до стартового маркера не кодируется, а данные, находящиеся после маркера, будут закодированы. По завершении процесса кодирования указатель языка в теге <SCRIPT> сменится на

Дополнительные методы обеспечения безопасности веб-содержимого

Некоторые из динамических элементов веб-содержимого могут быть секретными или разрешенными для доступа только тем пользователям, которые зарегистрировались для использования предоставляемой услуги. Можно контролировать доступ к таким страницам посредством создания списков контроля доступа (ACL) и учетных записей Windows. Но такой подход не применишь на сайте, связанном с электронной коммерцией, так как у него будут тысячи пользователей. Посредством использования сценариев легко осуществляется контроль доступа к страницам без создания учетных записей пользователей Windows.

Обеспечение безопасности страниц при помощи ASP

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

Данные, введенные в форме, передаются странице logon.asp в папке scripts с помощью действия POST. Если содержимое, к которому осуществляется доступ, является особо секретным, например, содержит информацию о кредитных картах или учетных записях, данные входа и любое секретное содержимое должны передаваться через соединение SSL. Сценарий logon.asp сверяет имя пользователя и пароль с информацией, находящейся в базе данных зарегистрированных пользователей. В случае соответствия сценарий logon.asp устанавливает сеансовую переменную и направляет клиента на страницу со специальными предложениями. Если соответствующей информации в базе данных не обнаруживается, это означает, что пользователь еще не зарегистрирован, и происходит его перенаправление на страницу регистрации.

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

Всякий пользователь, попытавшийся осуществить доступ к такой странице и не прошедший аутентификацию, будет перенаправлен на страницу accessdenied.asp. На этой странице можно разместить сообщение о том, что пользователь не зарегистрирован, и предложение пройти процедуру регистрации.

Важно. Всегда используйте метод POST для отправки секретной информации из формы. При использовании метода GET введенные в форме данные будут отображаться в адресе URL, который видит каждый пользователь.

Файловая система с шифрованием

Файловая система с шифрованием (EFS) обеспечивает внутреннее шифрование файлов, используемое файловой системой Windows 2000 и позволяющее шифровать файлы и папки в томах NTFS. EFS включается для документов в Windows 2000 посредством дополнительного файлового атрибута. Для шифрования содержимого папки перейдите к папке в Windows Explorer (Проводник Windows), щелкните правой кнопкой мыши на папке и выберите команду Properties (Свойства), чтобы открыть соответствующее окно (см. рис. 11.9).

Нажмите на кнопку Advanced (Дополнительно) и отметьте опцию Encrypt Contents To Secure Data (Шифровать содержимое для защиты данных) (см. рис. 11.10). Нажмите на OK, чтобы вернуться в Windows Explorer.

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

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

Итак, каким же образом используется EFS для защиты секретного содержимого на веб-сайте? Наиболее часто EFS применяется в корпоративных сетях, в которых каждый пользователь имеет свою собственную веб-папку для публикации документов. Создав зашифрованную подпапку, каждый пользователь имеет доступ к частным документам через интрасеть, но остальным пользователям эти документы недоступны, даже если на сайте включена анонимная аутентификация. Причина в том, что шифруемые EFS файлы являются частными файлами, и к ним имеет доступ только пользователь, зашифровавший их. В качестве метода аутентификации используется встроенная аутентификация Windows или смешанная аутентификация в зависимости от настроек веб-сайта.

Важно. При использовании EFS следует шифровать папки, а не отдельные файлы, так как приложения создают временные файлы в тех же папках, где находятся исходные, особенно в процессе редактирования. При использовании шифрования на уровне папки временные файлы не будут сохраняться в виде открытого текста. По этой же причине следует применить шифрование к папке Temp, расположенной по адресу %SystemRoot%\TEMP.

Отладка активного содержимого

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

Например, при поиске в системе Altavista (www.altavista.com) по строке "Microsoft VBScript runtime error + .inc" появятся сотни результатов поиска, и во многих будет указан полный путь и имя файла вставки (.inc). Если присоединить это имя к имени узла и вызвать страницу по получившемуся адресу в веб-браузере, то велика вероятность того, что отобразится содержимое файла вставки.

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

Перехват ошибок

Обычно веб-разработчики ограничены во времени и, как правило, ставят на первое место внешний вид, удобство работы и функциональность, а о безопасности думают далеко не в первую, если не в последнюю, очередь. В лекции 9 говорилось о том, что такой подход недопустим при разработке содержимого для интернета. Разработка и тестирование должны проводиться в автономном режиме для успешного устранения всех угроз безопасности создаваемых сценариев, а это возможно при таком выполнении сценария, когда семантические ошибки программирования выявляются сами по себе.

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

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

Поскольку идеально написанного кода не существует, необходимо обеспечить поддержку активным содержимым непредвиденных ошибок и отображение соответствующих уведомлений об их возникновении. По умолчанию файл 500-100.asp обрабатывает все ошибки, возникающие при компиляции или запуске файлов .asp. При возникновении ошибки ASP IIS возвращает файл 500-100.asp с информацией о ней, например, номер строки, в которой произошла ошибка, и ее описание.

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

Обработка ошибок устанавливается на главном уровне, веб-уровне или уровне каталога посредством изменения свойств сообщений об ошибках HTTP, передаваемых клиентам при их возникновении.

Для настройки IIS на отображение сообщения об ошибке откройте консоль Internet Services Manager (Диспетчер служб интернета) и щелкните правой кнопкой мыши на нужном сервере или веб-сайте. Выберите команду Properties (Свойства), откройте вкладку Custom Errors (Другие ошибки) и прокрутите вниз список сообщений об ошибках, чтобы отобразить HTTP Error 500;100 (см. рис. 11.11).

Нажмите на кнопку Edit Properties (Изменить параметры) для изменения параметров сообщения об ошибке, указав созданную или измененную страницу с текстом уведомления (см. рис. 11.12).

Совет. Убедитесь, что файл обработки ошибок не содержит синтаксических ошибок или ошибок времени выполнения; если в коде присутствуют ошибки, они отобразятся в веб-браузере. Строка 5 приведенного выше кода On Error Resume Next обеспечивает выполнение файла без возникновения ошибок.

Ошибки ASP и журнал событий Windows

Ошибки ASP можно передавать в журнал событий Windows, если указаны соответствующие параметры в окне Process Options Properties (Свойства обработки). Для настройки этих параметров откройте окно WWW Service Master Properties (Главные свойства службы WWW), щелкнув правой кнопкой мыши на сервере в Internet Services Manager (Диспетчер служб интернета). Откройте вкладку Home Directory (Домашний каталог), после чего нажмите на кнопку Configuration (Настройка). Откроется окно Application Configuration Properties (Настройка конфигурации приложения). Откройте вкладку Process Options (Обработки опций) (см. рис. 11.13).

Отметьте опцию Write Unsuccessful Client Requests To Event Log (Заносить неудачные запросы клиентов в журнал событий), и наиболее серьезные ошибки ASP будут фиксироваться в журнале событий Windows.

Опция Enable Debug Exception Catching (Включить перехват исключений при отладке) отмечается только при отладке, так как она фиксирует любые сообщения об ошибках, поступающие от компонента. Так как отладка должна осуществляться только на сервере разработки, убедитесь, что данная опция отключена.

ПРОБЛЕМА

Иван, молодой разработчик, работающий над новым сайтом электронной коммерции, создает сценарии ASP для подключения веб-сайта к базе данных Microsoft SQL Server, содержащей информацию о клиентах, т.е. их имена, адреса, заказы и т.д. В понедельник утром Иван заявляет, что немедленно увольняется из компании и начинает новую карьеру. Время, отведенное на разработку сайта, неумолимо истекает, поэтому необходимо привлечь на место Ивана другого сотрудника. Вас устраивало качество выполнения Иваном своей работы, однако нужно удостовериться в том, что ее можно использовать.

Первым делом запретите Ивану доступ к файлам ASP и всей сети организации. Проинформируйте сетевого администратора о том, что учетная запись Windows, принадлежащая Ивану, должна быть удалена. Это запретит бывшему сотруднику доступ к сети. В дополнение к этому все члены команды разработки должны сменить свои пароли при следующем входе в систему. Это мера предосторожности необходима на тот случай, если Иван знает пароли других разработчиков компании.

Так как Иван имел доступ к базе данных SQL Server, он знает имя пользователя и пароль доступа, используемый страницами ASP для открытия соединения. У него могла быть и своя собственная учетная запись SQL Server с повышенными привилегиями, позволявшими ему проводить работу по разработке. Проинформируйте администратора базы данных о том, что учетная запись Ивана в базе данных должна быть удалена, а также об изменении пароля, используемого страницами ASP. Кроме этого, необходимо сменить остальные системные пароли, которые мог знать Иван.

Следующая задача состоит в том, чтобы провести обзор всей выполненной Иваном работы. Несмотря на то, что написанный им код хорошо закомментирован, нужно просмотреть каждую строку и выяснить следующее.

• Каждая страница содержит в начале строку, устанавливающую кодировку.
• Все данные, вводимые пользователем в формы, или данные из элементов cookie проверяются на наличие запрещенных символов.
• Все данные, получаемые из базы данных для отображения на веб-странице, подвергаются кодировке.
• В коде отсутствует опасный или вредоносный код, например, ненужный вызов почтового сервера.
• В коде не используются системные пароли, доступ к ним осуществляется с помощью компонента COM+.
• Все вызовы базы данных выполняются посредством сохраненных процедур.

После того как код Ивана пройдет эту проверку, протестируйте его на сервере разработки для выявления синтаксических или семантических ошибок. Проверка должна включать в себя передачу данных сценариям (не только корректных значений, но и величин, превышающих максимально допустимые значения или соответствующих граничным условиям). Например, проверьте, каким образом осуществляется поддержка заказа на сумму, равную точно $500, если максимально разрешенной суммой покупки является $500.

Хотя Иван мог и вовсе не включать в код ненужные или вредоносные фрагменты, процедура проверки необходима, так как Иван осуществлял активный доступ к вашей сети и ее ресурсам.

Подписывание кода

Java-апплеты или элементы ActiveX повышают уровень функциональности сайта, реализовывая ниспадающие меню или бегущую строку. Так как пользователям интернета известны уязвимые места таких апплетов, то после их разработки и тестирования нужно убедить посетителей в том, что содержимому сайта можно доверять, и что он безопасен. Многие сетевые экраны настроены на блокирование апплетов без доверия, а политики безопасности предусматривают запрет установки и выполнения сторонних апплетов на компьютерах сети. Самым простым способом убедиться в безопасности апплета или макроса является подпись объекта при помощи цифрового сертификата подписи кода.

Сертификат идентифицирует организацию и выпускается бюро сертификатов только после того, как оно подтвердит наличие организации и ее сферу деятельности. Примером бюро сертификатов является компания VeriSign. Сертификаты для подписывания кода (в VeriSign они называются цифровыми идентификаторами) позволят разработчикам ставить цифровую подпись на программное обеспечение и макросы для обеспечения безопасности их доставки через интернет. Любой пользователь, загрузивший подписанный цифровым сертификатом элемент ActiveX, Java-апплет, динамически подсоединяемую библиотеку, файлы .cab или .jar, может быть уверен в том, что загружаемый код действительно поступает от вас, а также в том, что он не был изменен или поврежден с момента создания и подписи. Подписывание программ выступает в роли упаковки, в которую "заворачивается" программное обеспечение, так как в случае изменения программы цифровая подпись станет недействительной аналогично тому, как поврежденная пленка на запакованных продуктах предупреждает потребителя о том, что с товаром что-то произошло.

К сожалению, необходимо использовать различные сертификаты для подписи кода от двух основных поставщиков активного содержимого – Microsoft и Netscape. Технология Microsoft Authenticode позволяет ставить цифровую подпись на файлах .exe, .cab, .dll и .ocx; средства Netscape Object Signing позволяют заверять цифровой подписью Java-апплеты, сценарии JavaScript, надстройки и любые файлы JAR. Authenticode заверяет программы, предназначенные только для браузеров Microsoft Internet Explorer, а сертификаты Object Signing действительны только для браузеров Netscape. Вам понадобятся дополнительные сертификаты для подписи макросов для Office 2000/XP и объектов VBA, а также содержимого, созданного с помощью Macromedia Director Shockwave Studio или Macromedia Flash.

Многоцелевые сертификаты для подписывания программ можно получить, например, от бюро сертификатов Thawte по адресу http://www.thawte.com. Эти сертификаты используются несколькими приложениями, поэтому не нужно приобретать отдельный сертификат для каждого подписываемого приложения.

Серверные расширения FrontPage

Серверные расширения Microsoft FrontPage (FPSE) представляют собой набор программ, которые устанавливаются на сервере IIS для разработки и администрирования расширенных с помощью FrontPage сайтов, позволяя удаленным пользователям выполнять определенные задачи непосредственно на сервере. Фраза "непосредственно на сервере" является причиной того, что в лекции 3 не рекомендовалось устанавливать FPSE на защищаемом сервере, и этот совет по-прежнему остается в силе, так как компонент FPSE уже был предметом атак хакеров. Тем не менее, вам потребуется администрирование и разработка, обеспечиваемая FPSE при предоставлении услуг по веб-хостингу. Информация по установке FPSE находится в следующих разделах, ознакомьтесь с ней, чтобы разобраться в аспектах безопасности этого компонента и повысить его уровень защищенности.

Управление FPSE

Всегда используйте последнюю версию FPSE (это версия 2002), показанную на рис. 11.14 в окне Properties (Свойства) сервера. Расширения можно загрузить из раздела FrontPage сайта MSDN по адресу http://msdn.microsoft.com/library/default.asp?url/library/en-us/dnservext/html/fpse02win.asp. Пакет FrontPage Server Extensions Resource Kit доступен по адресу http://office.microsoft.com/Assistance/2000/FPserk.aspx; в нем имеются полезные сведения по использованию FPSE.

После установки FPSE 2002 можно использовать страницы HTML Administration или командую строку для администрирования веб-сайтов и сервера. Администрирование расширений FrontPage 2000 Server Extensions раньше осуществлялось при помощи Microsoft Management Console (MMC), а теперь эта возможность недоступна. Так как формы HTML позволяют осуществлять удаленное администрирование, они должны быть удалены. По умолчанию эти формы устанавливаются в каталог C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\50\admisapi\1033 наряду с другими утилитами командной строки, используемыми для администрирования FPSE.

Для удаленного администрирования обеспечьте следующие меры предосторожности.

• Обязательное SSL-соединение.
• Предоставление доступа к библиотеке fpadmdll.dll и формам HTML только доверенным администраторам.
• Обязательное использование нестандартного HTTP-порта.
• Использование ограничений маски IP-адресов для предотвращения несанкционированного доступа к формам администрирования HTML.

С этим программным пакетом устанавливаются две утилиты командной строки – owsadm.exe и owsrmadm.exe. Утилита Owsrmadm.exe позволяет осуществлять администрирование с удаленного компьютера и должна быть удалена, если в этом нет необходимости. Утилиты командной строки обеспечивают больший набор возможностей, нежели страницы администрирования HTML. Утилиты командной строки применяются для выполнения следующих задач.

• Управление пользователями и ролями.
• Обнаружение потенциальных проблем с установленным компонентом серверных расширений и их устранение.
• Добавление, удаление или слияние вложенных веб-сайтов.
• Сканирование веб-сайта для генерирования свежих отчетов о веб-содержимом.
• Обновление до новой версии серверных расширений.
• Деинсталляция серверных расширений для определенного веб-сайта.
• Настройка параметров для веб-страницы, корневой веб-страницы или для всех веб-сайтов сервера.

Вам пригодятся также две полезные команды Disable и DatabaseConnection. Команда Disable предназначена для отключения разработки и администрирования из клиента FrontPage после внесения каких-либо изменений, а также для их повторного включения при внесении изменений в содержимое. Команда DatabaseConnection предназначена для проверки информации о подключении к базе данных, для шифрования имени и пароля учетной записи перед их сохранением. Более подробная информация об администрировании из командной строки доступна в руководстве администратора по адресу http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechno/sharepnt/proddocs/admindoc/ows000.asp.

Веб-сайты с установленными расширениями FrontPage

Расширенный при помощи FrontPage Extensions сайт содержит веб-страницы, рисунки и другие файлы и документы. Пользователям могут быть присвоены роли для управления или обновления расширенного веб-сайта. Ранее управление ролями пользователей для FPSE осуществлялось из клиента FrontPage с помощью команды Security (Безопасность) в меню Tools (Сервис). При помощи расширений 2002 Extensions осуществляется управление ролями с использованием средства администрирования командной строки или с помощью страниц администрирования HTML. По умолчанию устанавливаются следующие роли.

По умолчанию устанавливаются следующие роли.

• Веб-браузер. Права для просмотра страниц, просмотра обсуждений веб-документов и чтения списков.
• Автор. Права обозревателя, права редактирования страниц, папок и списков.
• Главный автор. Права автора, права для определения и применения тем и границ, таблиц стилей ссылок и права на повторную калькуляцию веб-сайта.
• Администратор. Все права остальных ролей, права на изменение ролей, создание локальных учетных записей пользователей, контроль за исходными файлами, создание веб-сайтов, обсуждение веб-документов и подписок, управление параметрами сервера и анализ использования.

Библиотеки DLL пакета FPSE

FrontPage использует все возможности FPSE. Когда автор или администратор выполняет операцию при помощи FrontPage, он подключается к серверным расширениям, используя протокол удаленного вызова процедур RPC, лежащего в основе HTTP и HTML. Запрос POST отправляется из клиента FrontPage одной из трех библиотек DLL FPSE.

• Запросы на действия по администрированию передаются библиотеке Admin.dll.
• Запросы на действия по авторству передаются библиотеке Author.dll.
• Запросы на действия по просмотру передаются библиотеке Shtml.dll.

Когда веб-браузер или FrontPage-расширенный веб-сайт запрашивает страницу, требующую FPSE, например, форму отправки данных поиска, он отправляет запрос POST программе просмотра Shtml.dll. После получения службой IIS запроса для FPSE она осуществляет вход в систему и имитирует пользователя, после чего запрос передается напрямую библиотеке Admin.dll, Author.dll или Shtml.dll. Далее библиотека DLL FPSE сверяет разрешения имитируемого администратора, автора или посетителя со списком ACL в корневой папке веб-сайта или страницы. При положительном результате проверки запрос обрабатывается; в противном случае клиенту FrontPage или браузеру передается сообщение "Доступ запрещен".

Разрешения

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

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

FrontPage обеспечивает полный доступ ко всем файлам для членов группы Administrators (Администраторы) и учетной записи SYSTEM. Разрешения на выполнение посетителями сайта, разработчиками и администраторами присваиваются всем папкам, помеченным исполняемым виртуальным корневым каталогом. Разрешение на выполнение устанавливается только в том случае, если в окне Properties (Свойства) расширенного с помощью FrontPage веб-сайта отмечена опция Allow Authors To Upload Executables (Разрешить авторам отгружать исполняемые файлы).

Списки ACL для FrontPage-расширенного веб-сайта приведены в таблице 11.1.

Совет. Если вы создаете базу данных (например, Microsoft Access) и связываете ее с FrontPage-расширенным веб-сайтом, сохраняйте ее в папке, созданной FrontPage, – _fpdb. FrontPage автоматически пометит эту папку как непросматриваемую, доступную для сценариев или исполняемую. Удостоверьтесь и в том, что применены механизмы безопасности, встроенные в базу данных или сервер базы данных, для ограничения пользователей, имеющих право обновлять содержимое базы данных. Как правило, учетные записи веб-авторов не требуют привилегий выше, чем запрос SELECT. Веб-авторам не следует разрешать обновление, вставку или удаление записей из базы данных. Эти задачи выполняются через внешний интерфейс базы данных.

Подсайты

FPSE позволяет создавать отдельные подсайты. Подсайт представляет собой законченный FrontPage-расширенный веб-сайт, который можно создать на любом уровне структуры содержимого, включая уровень, находящийся под другим подсайтом. Несмотря на то, что данные объекты при доступе через веб-веб-браузер выглядят как обычные подпапки, их можно полностью отделить от родительского веб-сайта. Если сайт содержит раздельные области содержимого, управление которыми осуществляется различными людьми, и нужно запретить авторам доступ ко всему содержимому сайта, используйте раздельные подсайты для сегрегации данных. Это позволит структуре содержимого веб-сайта соответствовать структуре предприятия; например, реализовывать для различных отделов управление только собственными областями данных на сайте. Так как каждый подсайт имеет свои настройки безопасности, безопасность может быть настроена на достаточно высоком уровне детализации параметров защиты. Например, автору FrontPage-расширенного веб-сайта не должно автоматически присваиваться разрешение на редактирование любых подсайтов.

Так как виртуальный сервер имеет свои собственные параметры безопасности и свой собственный список пользователей, создание виртуального сервера является способом ограничения доступа к веб-содержимому. Дополнительным преимуществом виртуальных серверов и подсайтов является потенциально более высокая производительность, так как время, необходимое для пересчета гиперссылок, прямо пропорционально числу и размеру документов, хранимых на одном веб-сервере.

Совет. Когда администратор устанавливает списки ACL для FrontPage-расширенного веб-сайта с помощью команды Permissions клиента, FrontPage выводит список учетных записей сервера по умолчанию. Можно создать ограниченный список пользователей и групп для каждого веб-сайта, расширенного при помощи FrontPage. Это предотвратит отображение полного списка учетных записей Windows. Обратитесь к документации FPSE и выясните, как это сделать.

Удаление FPSE

Можно временно или постоянно удалить FrontPage 2002 Server Extensions с сервера IIS. Для временного удаления расширения используйте команду uninstall. В этом случае данные о сайте будут сохранены, и можно будет заново расширить виртуальный сервер и вернуться к исходной конфигурации. Для постоянного удаления расширения выполните команду fulluninstall, которая удалит все файлы компонента, кроме непосредственного содержимого сайта. Ниже приведен пример такой команды:

Для временной деинсталляции FrontPage 2002 Server Extensions введите следующую команду в командной строке, заменив <port> номером порта указанного виртуального сервера:

Переменные конфигурации FPSE

Иногда информация, предоставляемая средствами командной строки, является очень скудной. Для проверки или настройки переменных конфигурации расширения сервера найдите их в реестре или в файле Service.cnf. Переменные устанавливаются на одном из следующих уровней.

• Глобальные переменные. Применяются ко всем виртуальным серверам и подсайтам на компьютере сервера и устанавливаются в реестре по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Shared Tools\Web server Extensions\All Ports.
• Переменные виртуального сервера. Применяются к одному виртуальному серверу и устанавливаются в реестре по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\ Web server Extensions\Ports\<Номер порта>.
• Переменные веб-сайтов и подсайтов. Устанавливаются посредством изменения текстового файла _vti_pvt/Service.cnf в корневом веб-сайте или подсайте.

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

При использовании FPSE не требуется доступ с открытием файлов для общего пользования на компьютере веб-сервера, а пользователям не нужен ни FTP, ни Telnet для управления своими веб-страницами, так как управление осуществляется через HTTP. Тем не менее, внимательно отслеживайте все уведомления безопасности Microsoft, чтобы быть в курсе появления новых уязвимых мест. Программа FrontPage 2002 Server Extensions улучшена по сравнению с предыдущими версиями, но вам следует ознакомиться с онлайновой справкой и разобраться в том, как управлять этими расширениями.

AccessControl

Установите значение AccessControl, равное 1; в противном случае каждый раз при создании подсайта любой пользователь получит права автора по отношению к этому подсайту, пока параметры доступа не будут настроены вручную.

AllowExecutableScripts

Установите значение AllowExecutableScripts на нуль, если не нужно помечать отдельные файлы как исполняемые.

NoExecutableCGIUpload

Если переменная NoExecutableCgiUpload установлена на ненулевое значение, FPSE не будет устанавливать бит исполняемого файла на сценарии CGI, отгружаемые автором на веб-сайт с помощью FrontPage. Это позволит веб-мастеру устанавливать разрешение Execute (Выполнение) вручную после проверки сценария. Если переменные NoExecutableCgiUpload и AllowExecutableScripts установлены на нуль, можно отгружать и выполнять файлы ASP и IDC, но не файлы CGI или ISAPI.

ClientVerCutoff

Устанавливает самую раннюю версию клиента FrontPage, подключаемую к серверу.

NoMarkScriptable

Если переменная NoMarkScriptable установлена на ненулевое значение, пользователи FrontPage не смогут изменять бит обработки сценариями на любых папках веб-сайта; это сможет делать только веб-мастер.

NoSaveResultsPipeTo

Ранние версии FrontPage позволяют обработчику форм по умолчанию (Save Results) передавать результаты формы по каналу любой случайно выбранной программе. Для обратной совместимости NoSaveResultsPipeTo отключает данную возможность при установке на ненулевое значение.

NoSaveResultsToAbsoluteFile

Если значение переменной NoSaveResultsToAbsoluteFile установлено на 1, обработчик форм по умолчанию (Save Results), обработчик Registration (Регистрация) и Discussion (Обсуждение) не cмогут осуществлять запись в файл с абсолютным путем, даже если текущая учетная запись имеет права NTFS на запись данных по этому пути; обработчики форм смогут записывать только в файл, находящийся внутри области веб-содержимого.

PrivateBrowsable

Чтобы запретить посетителям сайта просматривать каталог _private, установите переменную PrivateBrowsable на нуль. После установки этот параметр будет применяться ко всем создаваемым веб-страницам. Он не оказывает влияния на веб-страницы, созданные перед установкой данного параметра.

RequireSSL

Если значение параметра RequireSSL установлено на 1, серверные расширения потребуют соединение между клиентом FrontPage и сервером через протокол защищенных сокетов SSL.

RestrictIISUsersAndGroups

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

Роботы и "пауки"

Веб-роботы, также называемые "пауками" или веб-странниками, – это программы, автоматически исследующие всемирную сеть через рекурсивное получение страниц по гиперссылкам. Робот посещает сайты посредством запросов документов с этих сайтов и создает базу данных, которая используется поисковой машиной для нахождения документов, соответствующих строке поиска. Если сайт открыт для общего доступа, пользователи должны иметь возможность поиска сайта с помощью поисковой системы. Тем не менее, следует запретить роботам доступ к страницам сайта, особенно к тем, которые содержат важную информацию, так как это может привлечь внимание хакеров. Большая часть веб-роботов содержит два механизма ограничения областей сайтов, которые они будут посещать: протокол исключений роботов Robots Exclusion Protocol и META-теги роботов, хотя некоторые роботы игнорируют обе директивы.

Протокол исключений роботов

Для указания разделов сайта, которые не должны посещаться роботом, создайте специально отформатированный файл с именем robots.txt. Разместите этот файл на верхнем уровне веб-пространства, например, по адресу http://www.ваш_домен.com/robots. Когда робот найдет этот документ, он проанализирует содержимое данного файла, устанавливающее базовую политику доступа роботов. К сожалению, робот действует по принципу "разрешено все, что не запрещено". На сайте может существовать только один файл robots.txt, поэтому не размещайте файлы robots.txt в различных папках, так как роботы никогда не будут их считывать. Если веб-разработчики создают свои собственные файлы robots.txt, нужно осуществить их слияние в один файл. Можно также использовать META-теги роботов (о которых пойдет речь в следующем разделе).

Содержимое файла robots.txt может быть таким:

В этом примере роботы могут посещать все части сайта, кроме трех вложенных папок: scripts, includes и mike. Регулярные выражения не поддерживаются в строках User-agent или Disallow, однако звездочка ("*") в поле User-agent имеет специальное значение – "любой робот". Следовательно, нельзя вводить в файл такие строки: Disallow: /tmp/* или Disallow: *.gif. Укажите отдельную строку Disallow для каждой папки, которую нужно исключить из списка посещаемых роботом объектов. Нельзя включать в запись и пустые строки, так как они используются для разделения нескольких записей.

Ниже приведено несколько примеров того, как запретить роботам посещение всего сайта целиком или его отдельных частей.

Чтобы исключить всех роботов для всего сайта:

Чтобы исключить всех роботов для отдельных папок на сайте:

Чтобы исключить одного робота:

Чтобы разрешить определенного робота:

Так как в этом случае не может существовать поле "Allow" (Разрешить), то для исключения всех файлов, кроме одного, поместите эти файлы в отдельную подпапку (например, private), и перенесите один файл на уровень выше, чем данная папка, например:

В качестве альтернативы можно явным образом запретить доступ робота к каждой странице:

Файл robots.txt должен исключать все папки, кроме тех, которые действительно должны быть проиндексированы и доступны через поисковые машины интернета.

META-теги роботов

Если несколько веб-разработчиков или подразделений одновременно управляют различными разделами сайта, то обновление файла robots.txt может оказаться трудной задачей. Используйте специальные META-теги HTML роботов для обозначения того, что страница может индексироваться или анализироваться роботами, хотя не все роботы поддерживают META-теги. Microsoft Index Server поддерживает META-теги роботов и исключает содержащие их веб-страницы. Мета-теги роботов чувствительны к регистру букв и размещаются в разделе <HEAD> страница HTML, как и все остальные META-теги. Например:

В содержимом META-тега роботов присутствуют директивы, разделяемые запятыми. В настоящий момент определены директивы INDEX, NOINDEX, FOLLOW и NOFOLLOW. Директива INDEX указывает, должен ли робот индексировать страницу. Директива FOLLOW указывает, должен ли робот переходить по ссылкам на странице для поиска других страниц. Директивами по умолчанию являются INDEX и FOLLOW. Значения ALL и NONE включают и выключают директивы: ALL=INDEX,FOLLOW и NONE=NOINDEX,NOFOLLOW. Чтобы разрешить роботу индексирование и анализ страницы на предмет ссылок, добавьте следующий META-тег:

или

Остальные комбинации приведены ниже:

Очевидно, что не следует указывать конфликтующие или повторяющиеся директивы, например:

Совет. Для получения более подробной информации о роботах посетите сайт http://www.robotstxt.org/.

Сводный перечень действий по обеспечению безопасности активного содержимого

• Создайте четкую структуру каталогов, чтобы упростить управление разрешениями на выполнение активного содержимого.
• Убедитесь, что веб-папкам присвоены минимальные разрешения NTFS, позволяющие просматривать содержимое определенным учетным записям.
• Свяжите активное содержимое с программой, которая будет его обрабатывать, включая файлы вставок.
• Используйте программы контроля над исходными файлами для управления изменениями, вносимыми в активное содержимое, и удаления ненужных резервных файлов, сгенерированных редакторами.
• Добавляйте в создаваемый код примечания об авторских правах.
• Осуществляйте проверку вводимых пользователем данных перед их обработкой или отображением.
• Реализуйте кодировку всего содержимого, исходящего от сторонних источников, – от баз данных и вводящих информацию пользователей.
• Убедитесь в том, что весь код проходит процедуру проверки, состоящую из девяти пунктов.
• Настройте и используйте на сайте фильтры ISAPI для защиты собственного кода.
• Используйте кодировщик сценариев Script Encoder для скрытия сценариев на веб-страницах.
• Управляйте доступом к важной информации с использованием ASP, HTTP 401 и EFS.
• Проводите тщательную отладку всех сценариев и исполняемых файлов перед их установкой на защищаемом сервере.
• Реализуйте перехват ошибок для всех сценариев, чтобы предотвратить утечку информации о системе через веб-браузер, но фиксировать ее в файлах журналов.
• Подписывайте код апплетов и макросов, которые понадобятся посетителям при доступе к сайту.
• Не используйте без надобности серверные расширения FrontPage Server Extensions.
• Настройте переменные FPSE для повышения уровня безопасности по сравнению с конфигурацией по умолчанию.
• Используйте протокол исключения роботов Robot Exclusion Protocol или META-теги роботов для запрета индексирования роботами важного содержимого.