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

Этот текст впоследствии выдается в виде содержания клиентам, просматривающим объявления. Если программа, генерирующая контент, не проверяет текст объявлений на наличие тэгов »>Click here При этом код отсылается как часть текста объявления на 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 предоставляет злоумышленникам широкое поле для деятельности, и этот факт нельзя не учитывать при формировании политики безопасности. Использов

скачать работу


Погода в Алматы	на 10 дней	другой город

Отправка СМС бесплатно

На правах рекламы

Модератор сайта RESURS.KZ