Очевидное решение для злоумышленника, оккупировавшего какой-либо WWW-сервер, состоит в непосредственном помещении кода Javascript в HTML-документы сервера. Другой способ называется cross-site scripting и состоит том, что злоумышленник использует сервер с динамической генерацией содержания в качестве посредника. Например, WWW-сервер имеет доску объявлений, куда любой желающий может поместить текст. Этот текст впоследствии выдается в виде содержания клиентам, просматривающим объявления. Если программа, генерирующая контент, не проверяет текст объявлений на наличие тэгов <script> и других специальных слов и символов, то злоумышленник может поместить программный код в текст объявления, и этот код будет доставлен пользователю.
Разновидностью cross-site scripting является отправка пользователем потенциально вредоносного кода самому себе. Это происходит, когда пользователь следует по ссылке вида:
<A HREF=«http:/example.com/comment.cgi?mycomment=
«<SCRIPT> вредоносный код</SCRIPT>»>Click here</A>
При этом код отсылается как часть текста объявления на WWW-сервер example.com, который тут же возвращает этот текст пользователю для просмотра, доставляя таким образом вредоносный код браузеру.
Cross-site scripting и SSL
Интересным эффектом cross-site scripting является возможность доставки злоумышленником кода через соединения, защищенные с помощью SSL. Это возможно, если WWW-сервер, с одной стороны, позволяет злоумышленнику поместить непроверяемый текст через незащищенное соединение, а с другой стороны, демонстрирует помещенный текст пользователю через защищенное соединение.
Для защиты от cross-site scripting разработчики программ динамической генерации содержания должны проверять вывод программы на наличие специальных тэгов и символов.
Цифровая подпись
Несколько слов о цифровой подписи. Ее наличие говорит только о том, что программа (управляющий элемент ActiveX, апплет Java или код Javascript) написана определенным автором и не была изменена. Подпись не гарантирует того, что после запуска программа не начнет стирать файлы с жесткого диска. Конечно, программа, подписанная широко известной компанией, вряд ли содержит умышленно введенный вредоносный код, но может содержать ошибки, которые потом могут быть использованы злоумышленником. Также отметим, что если браузер доверяет одной подписанной программе, то он автоматически доверяет всем программам, подписанным тем же автором.
Настройки современных браузеров позволяют отключать выполнение приложений Java, ActiveX и скриптов Javascript, или требовать обязательного наличия подписи в этих программах.
ШПИОН НА ПРОВОДЕ
Если не предпринять специальных мер, то все данные между браузером и HTTP-сервером передаются в открытом виде. Таким образом, можно смело предположить, что прослушивание WWW-трафика не требует значительных усилий. Применение Digest-аутентификации (с некоторыми оговорками) снимает проблему перехвата пароля и при полной реализации даже защищает от несанкционированной модификации передаваемых данных каким-либо промежуточным узлом. Однако сами данные при этом остаются беззащитными.
Кроме того, вам следует знать, что все запросы вашего браузера регистрируются www-сервером, который записывает в специальный файл время запроса, IP-адрес клиента, URL запрошенного документа, имя пользователя (если применялась аутентификация), тип браузера и URL документа, который пользователь просматривал до этого. Если пользователь работает через прокси-сервер, то такая информация сохраняется на нем же и может быть использована администрацией для контроля и учета использования WWW своими сотрудниками.
Более того, если браузер передает данные заполненной формы методом GET, то они сохраняются в LOG-файлах, поскольку являются частью URL-адресов. Метод POST свободен от этого недостатка, так как передает данные в зашифрованном виде.
Также браузер ведет кэширование недавно запрошенных документов на локальном диске и запись всех сайтов, которые посещал пользователь (эта запись называется журналом, в оригинале - history). Настройки браузера позволяют очистить журнал и кэш (или вовсе отключить кэширование).
Многие интерактивные www-серверы (например, интернет-магазины) используют механизм cookies для сохранения информации о сеансе работы пользователя (например, о том, какой товар пользователь отобрал для покупки). Эту информацию сервер передает на сохранение браузеру пользователя, который записывает ее на локальный диск (куда именно - зависит от используемого браузера, следует найти файл или каталог под именем cookies). Просмотр файла с cookies может выявить достаточно интересные детали об активности пользователя в WWW. Пользователь может запретить браузеру принимать cookies, но в этом случае он не сможет пользоваться некоторыми сайтами.
ВОЗМОЖНОЕ РЕШЕНИЕ - SSL
Проблема подлога и перехвата данных злоумышленником, прослушивающим сеть или оккупировавшим прокси-сервер, решается с помощью протокола SSL (новое название - TLS).
Протокол SSL в стеке TCP/IP расположен между транспортным (TCP) и прикладным уровнями. SSL обеспечивает шифрование (и, соответственно, дешифрацию) всех данных прикладного уровня. В контексте HTTP это означает, что все данные, а также заголовки HTTP-запросов и ответов передаются через сеть в зашифрованном виде.
Для того чтобы воспользоваться SSL, HTTP-сервер должен быть сконфигурирован соответствующим образом, а браузер должен поддерживать протокол SSL (все распространенные браузеры его поддерживают). URL ресурсов, защищенных с помощью SSL, начинаются с "https://". Перед собственно обменом HTTP-запросами и ответами клиент (браузер) и сервер устанавливают SSL-соединение. При этом сервер предъявляет клиенту сертификат, подтверждающий "личность" сервера. Следовательно, злоумышленник не может выдать себя за искомый сервер. Подлинность сертификата автоматически проверяется браузером в общеизвестной базе данных сертификатов, например базе компании VeriSign. Если же сертификат не найден ни в одной общеизвестной регистратуре, то пользователю предстоит самому решить, доверять этому сертификату или нет.
В любом случае нужно понимать, что секретность при передаче данных и наличие сертификата не гарантируют защиты этих данных при хранении на сервере (слабо защищенная система сервера, недобросовестный администратор и т. п.).
SSL и прокси-серверы
Отметим особенность работы SSL через прокси-серверы. Так как весь трафик между браузером и HTTP-сервером зашифрован, то его интерпретация и кэширование не имеют смысла. Поэтому функции прокси-сервера сводятся к простой ретрансляции октетов между браузером и HTTP-сервером. Для перевода проксисервера в такой режим браузер посылает запрос методом CONNECT с указанием адреса и номера порта HTTP-сервера.
Поскольку метод CONNECT фактически создает туннель сквозь прокси-сервер, он может использоваться для обхода правил фильтрации TCP-соединений на брандмауэре, так как в общем случае туннель может быть установлен с любым портом внешнего сервера. Так пользователь может получить доступ к неразрешенным сервисам, поэтому администратор прокси-сервера должен тщательно сконфигурировать разрешения на использование метода CONNECT, в частности, разрешить соединения только с портом 443, который используется для работы HTTP через SSL.
Прокси-сервер - контроллер и защитник
Возможность использования прокси-серверов как посредников между клиентом и HTTP-сервером является весьма полезной не только с точки зрения уменьшения трафика путем кэширования, но и с точки зрения обеспечения безопасности.
Разумная политика состоит в том, что все хосты внутренней сети должны пользоваться WWW через прокси-сервер предприятия. Правила фильтрации брандмауэра строятся таким образом, что разрешен только HTTP-трафик, следующий к прокси-серверу или от него. Особенность HTTP-трафика состоит в том, что он далеко не всегда привязан к порту 80, поэтому в общем случае для прокси-сервера должны быть открыты все порты или хотя бы наиболее популярные из них (80-86, 8000-8006, 8080-8086, 8888).
Решаемые задачи
Следующие административные задачи могут быть решены на прокси-сервере при обслуживании пользователя (группы пользователей):
Идентификация пользователя
Для дифференцированного обслуживания пользователей прокси-сервером необходим механизм идентификации пользователя, который является автором данного запроса. Пользователь идентифицируется прокси-сервером либо по IP-адресу, либо с помощью прокси-аутентификации.
Прокси-аутентификация выполняется аналогично аутентификации на конечном WWW-сервере, но с помощью заголовка Proxy-Authorization. Если требуется прокси-аутентификация, но требуемые данные клиентом не предоставлены, то возвращается отклик с кодом 407 Proxy Authentication Required и заголовком Proxy-Authenticate, аналогичным по смыслу заголовку WWW-Authenticate. При использовании схемы Digest применяется также заголовок Proxy-Authentication-Info.