Опубликован: 16.10.2006 | Уровень: специалист | Доступ: платный
Лекция 11:

Безопасность активного содержимого

Кодировка HTML

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

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

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

<html>
<head>
<META http-equiv="Content-Type" content="text/html; CHARSET=ISO-8859-1">
<title>Safer HTML</title>
</head>

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

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

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

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

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

  1. Указывать кодировку в начале каждой страницы.
  2. Фильтровать и кодировать все данные формы. Разработчикам следует обратиться к материалу CERT за информацией о вредоносных тегах HTML по адресу http://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-выражений.
Araz Heyderov
Araz Heyderov
Россия
iketommoe ike
iketommoe ike
Тайвань (Китай)