Реферат: Информация и личная безопасность

Пользователь, наведя указатель на ссылку, увидит в статусной строке браузера, что ссылка указывает на www.goodbank.com, и, активизировав ссылку, попадет на www.cracker.com. Дальнейшее зависит только от фантазии владельца сайта www.cracker.com.

Пути распространения

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

Очевидное решение для злоумышленника, оккупировавшего какой-либо 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).

Решаемые задачи
Следующие административные задачи могут быть решены на прокси-сервере при обслуживании пользователя (группы пользователей):

• разрешение доступа к тому или иному сайту;
• разрешение использовать те или иные методы запроса (особенно CONNECT, позволяющего туннелировать сквозь прокси-сервер);
• качество обслуживания запроса: например, выделение определенной полосы пропускания;
• учет объема полученного за определенный период трафика и отказ в обслуживании пользователя при превышении определенного лимита;
• направление запроса через того или иного провайдера, если организация подключена к нескольким провайдерам (например, запросы низкоприоритетных пользователей направляются по медленному, но дешевому каналу, а высокоприоритетные - по скоростной, но дорогой линии);
• инспекция данных, передаваемых в запросе или ответе, например, для предотвращения несанкционированной передачи секретных данных или для автоматического удаления рекламных баннеров (выполнимо, если данные передаются в открытом виде).
• HTTP прокси-серверы также могут предоставлять прокси-сервис и для протокола FTP, что поддерживается всеми браузерами и большинством специализированных FTP-клиентов.

Идентификация пользователя

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

Прокси-аутентификация выполняется аналогично аутентификации на конечном WWW-сервере, но с помощью заголовка Proxy-Authorization. Если требуется прокси-аутентификация, но требуемые данные клиентом не предоставлены, то возвращается отклик с кодом 407 Proxy Authentication Required и заголовком Proxy-Authenticate, аналогичным по смыслу заголовку WWW-Authenticate. При использовании схемы Digest применяется также заголовок Proxy-Authentication-Info.

Подчеркнем, что аутентификация на www-сервере и прокси-аутентификация HTTP-запроса - это две не связанные между собой процедуры, выполняемые различными серверами. Оба заголовка (Authorization и Proxy-Authorization) могут присутствовать в одном запросе, если это необходимо.

Аутентификация является более предпочтительным способом идентификации пользователя, особенно, если один и тот же компьютер может эксплуатироваться разными людьми (персональный компьютер общего пользования или многопользовательская система). Однако очевидно, что аутентификация по схеме Basic в сети Ethernet с разделяемыми сегментами практически лишена смысла из-за широкой доступности программ прослушивания, поэтому необходимо применять схему Digest.

Заключение

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

ЭКСКУРС В ТЕХНОЛОГИЮ

WWW представляет собой клиент-серверную технологию, основанную на прикладном протоколе HTTP.

В HTTP имеются два типа сообщений: запросы от клиента (браузера) к серверу и ответы сервера клиенту. Для передачи сообщений используется протокол TCP и стандартный порт HTTP-сервера - 80. Запрос содержит URL - идентификатор ресурса (документа), который хотел бы получить клиент, и несколько вспомогательных заголовков.

Предполагается, что в ответ на запрос, проанализировав требуемый URL, сервер предоставит клиенту искомую информацию. Эта информация называется контентом. В простейшем случае это HTML-документ или файл в другом формате, однако контент может генерироваться сервером "на лету", например может быть вызвана сторонняя программа и ее вывод принят в качестве контента. Чтобы браузер правильно определил тип информации, содержащейся в контенте, и, соответственно, применил адекватный способ представления этой информации пользователю, контент сопровождается заголовком Content-Type, в котором указывается МIМЕ-тип данных.

Взаимодействие с клиентом

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

Пользователь задает параметры запроса путем заполнения и отправки HTML-форм. Формы содержат поля ввода текстовой информации, радиокнопки, выпадающие списки и т. п. Интерес представляет то, как именно браузер присоединяет введенные данные к запросу. В тэге <form> содержатся два параметра: action и method. Первый указывает URL, к которому будет отправлен запрос по заполнению формы, а второй - метод этого запроса.

Существуют два метода: GET и POST. При отправке запроса методом GET данные, введенные в форму, присоединяются к URL после вопросительного знака. В этом случае URL может выглядеть, например, так: "/cgi-bin/dir/script.pl?name=John&age=25 &hobby=reading&hobby=football". Нетрудно заметить, что данные состоят из пар "имя=значение", разделенных амперсандами. При отправке данных методом POST та же самая строка: "па-me=John&age=25&hobby=reading&hob-by=football" помещается после заголовке запроса, отделяясь от них пустой строкой В этом случае к URL ничего не добавляется.

Очевидно, что никакой HTTP-сервер не может предусмотреть всего разнообразия интерактивных www-приложений. Вместо этого HTTP-сервер предлагает разработчику интерфейс, используя который, сторонняя программа может получить от HTTP-сервера все необходимые для обработки запроса данные, а в ответ сгенерировать контент, который будет возвращен сервером браузеру. Таким образом, задача генерации контента возлагается на приложения, разрабатываемые под нужды конкретной задачи. В комплексных информационных системах на базе WWW говорят, что HTTP-сервер - это front end www-сайта, а приложения, генерирующие контент, - back end. Часто приложения работают в связке с базой данных: таким образом, имеет место трехуровневая схема: HTTP-сервер - приложение - база данных.

Интерфейс CGI

Наиболее общим и распространенным интерфейсом подобного типа является CGI. При его использовании HTTP-сервер запекает приложение, которое должно обработать запрос, и передает ему на стандартный ввод все, что поступило в запросе после заголовков. Также HTTP-сервер устанавливает несколько переменных окружения, в том числе переменную QUERY_STRING, которая содержит часть URL, расположенную после вопросительного знака (а это, как мы знаем, данные, переданные методом GET). Таким образом, CGI-приложение получает доступ к данным, введенным пользователем в форму. Отметим, что сами данные, их наличие или отсутствие, размещение в теле запроса или в URL или сразу в обоих местах HTTP-сервером никак не интерпретируются и не декодируются, а передаются приложению как есть. Все задачи по интерпретации и преобразованию данных возложены на CGI-приложение. Обработав запрос, приложение передает сгенерированный контент на свой стандартный вывод, где он перехватывается HTTP-сервером и пересылается клиенту. Единственный заголовок, который обязано выставить само CGI-приложение, - Content-Type.

Выполняемые составляющие

Другой способ динамической генерации контента - внесение программного кода непосредственно в текст HTML-файла. Код размещается внутри специальных тэгов (например, ). Приняв запрос такого файла, HTTP-сервер производит разбор его содержимого, обнаруживает программный код и исполняет его. В текст исходного файла вставляется результат выполнения кода и итоговый контент отправляется клиенту. Популярными технологиями, использующими встроенный код на стороне сервера, являются PHR ASP (Active Server Pages), JSP (Java Server Pages). В отличие от CGI, где от сервера, в общем случае, не требуется никаких знаний о том, как работает запускаемая им CGI-программа, при использовании встроенного кода требуется поддержка соответствующей технологии сервером, так как выполнение кода производится внутри процесса сервера.

Особый случай встроенного кода - язык Javascript. Код, написанный на Javascript, помещается внутри пары тэгов <script> и </script>, передается на сторону клиента и выполняется браузером. На стороне клиента выполняются также программы, написанные на языке Java. Встретив в HTML-документе тэг <applet>, браузер загружает с сервера файл, содержащий байт-код программы, и передает его на выполнение Java-машине. Последнюю можно бесплатно загрузить из Интернета с сайта http://java.sun.com.

Кэширование данных

Часто между браузером и HTTP-сервером располагается промежуточное звено - HTTP-кэш, или прокси-сервер. Не всякий контент будет помещен в кэш. Администратор прокси-сервера формулирует политику кэширования: например, не кэшировать контенты больше определенного размера, контенты, в URL которых имеется каталог cgi или cgi-bin, или контенты, полученные с серверов локальной сети. Кроме того, используя заголовок Cache-Control, сервер может явно запретить кэширование выдаваемого им контента. Помещенный в кэш контент не хранится там вечно: на основании значения заголовков Last-Modified и Expires прокси-сервер определяет его "срок годности".

Очевидно, что не все информационные ресурсы WWW могут быть открыты для всеобщего просмотра. Для того чтобы ограничить доступ к какому-либо ресурсу, используется аутентификация клиента, прежде чем запрос обслуживается HTTP-сервером. Аутентификация выполняется с помощью заголовков WWW-Authenticate и Authorization. Сегодня определены две схемы аутентификации: Basic и Digest, фундаментально отличающиеся друг от друга с точки зрения безопасности. Первая представляет собой обычную процедуру пересылки имени и пароля пользователя в открытом виде; вторая использует алгоритм MD5.

Пользователь вновь под ударом

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

В ЛАБИРИНТЕ ОТРАЖЕНИЙ

Страницы: 1, 2, 3