Защита информации в компьютерных сетях. Web уязвимости

запросе, передаваемом на http://www.disasterrelief.org, будет содержать строку http://www.cnn.com:

GET /Disasters/worldglance.html HTTP/1.0 Referer: http://www.cnn.com

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

Есть и худшие ситуации. Предположим, что с помощью формы, использующей метод GET, передается номер кредитной карты пользователя. Допустим, что сама форма передается безопасным способом (скажем, с применением SSL), а полученная после выполнения запроса с формой страница содержит ссылку на другую страницу, возможно, находящуюся па сервере S. Теперь, если пользователь переходит к этой странице, журнал регистрации сервера S будет содержать запись с полем Referer, содержащим номер кредитной карты пользователя.

Кроме того, сервер может осуществлять проверку поля Referer с целью отклонения запросов на определенные ресурсы, если ссылки па ресурсы находились на страницах, не контролируемых сервером. Например, предположим, что ссылка на встроенное изображение onlymine.gif, изначально принадлежащее ресурсу А, была скопирована в другой документ, В. Теперь, если браузер попытается отобразить документ В, он должен сформировать запрос на ресурс onlymine.gif и включить в запрос заголовок Referer с полем значения, соответствующим ресурсу В. Сервер может отказать в обработке запроса, поскольку поле Referer не содержит А.

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

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

2.3.2 Заголовки HTTP ответа

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

ВНТТР/1.0 определены три заголовка ответа:

•Location. Заголовок Location используется для направления запроса в место расположения ресурса и полезен при переадресации ответов. Заголовок Location имеет следующий синтаксис:

Location: http://www.foo.com/level1/twosdown/Location.html

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

HTTP не сохраняет свое состояние, поэтому Web-серверу не нужно хранить какую-либо информацию о прошлых или будущих запросах. Однако на стороне сервера может иметься существенная причина для сохранения информации о состоянии между запросами в ходе сеанса или даже между сеансами. Например, может оказаться необходимым предоставлять доступ к ряду страниц на сервере только определенной группе пользователей. Если ввод идентификационной информации необходим при каждом обращении пользователя к любой из этих страниц, возникает дополнительная нагрузка как на пользователя (ему необходимо вводить эту информацию), так и на сервер (для обработки этой информации). Дополнительные транзакции также снижают пропускную способность сети. Сохранение определенной информации между запросами сокращает непроизводительные затраты для пользователя, сети и сервера. Браузер играет важную роль в предоставлении необходимой информации о состоянии вместе с пользовательским запросом.

Cookies являются одним из средств сохранения состояния HTTP. Cookie — это информация о состоянии, которая передается Web-сервером браузеру и хранится на компьютере пользователя в интересах сервера. Механизм работы с информацией о состоянии HTTP дает возможность клиентам и серверам сохранять информацию за пределами запроса и ответа па него. Cookies впервые были применены Netscape в 1994 г.. Затем организацией Internet Engineering Task Force (IETF) был начат процесс стандартизации. Механизм рабо-ты с состоянием HTTP, формализующий использование cookies, подробно описан в документе RFC 2965, выпущенном в октябре 2000 г. и представляющем собой предложение по стандарту (Proposed Standard) IETF. RFC 2965 отражает опыт различных реализаций.

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

2.4.1. Причины использования cookies

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

Многие Web-сайты (например, The New York Times, http://www.nytimes.com) требуют, чтобы cookies использовались браузером при загрузке страниц. Сайты могут требовать, чтобы пользователи идентифицировали себя именами и паролями. Если это необходимо делать при каждой загрузке страниц с этого сайта, пользователь вряд ли захочет работать с таким сайтом. Вместо этого необходимая идентификационная информация может передаваться автоматически через cookie.

Типичный пример использования cookie — «магазинная тележка», в которую пользователь помещает купленные им товары. Имеются Web-сайты, на которых пользователи могут выбирать товары, которые они планируют купить, например, книги или компакт-диски. По мере выбора пользователем товаров виртуальная магазинная тележка содержит множество выбранных на данный момент товаров.

Без cookies Web-серверу пришлось бы сохранять состояние всех своих пользователей (их может быть тысячи) на своем компьютере в течение длительного периода времени. Содержимое магазинной тележки или перечень приобретенных в последнее время товаров являются примерами информации о состоянии. В других случаях может сохраняться более подробная информация, например, все купленные пользователем товары или страницы, которые

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

2.4.2. Использование cookies в браузере

На рис. 2.4 представлен клиент, отправляющий запрос исходному серверу А (этап 1). Исходный сервер в ответ включает заголовок (Set-Cookie) со значением cookie (XYZ) (этап 2). Во все последующие запросы к исходному серверу А клиент включает cookie (этап 3, передача Cookie с запросом в заголовке).

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

Cookies первоначально хранятся в оперативной памяти компьютера пользователя и записываются на долговременное устройство хранения (файлы на диске) при выходе из браузера. В соответствии с указаниями по реализации агенты пользователя могут хранить часто используемые cookies столько, сколько нужно, однако существует ряд ограничений. Cookie может иметь размер до 4 Кбайтов. Браузеры дают возможность сохранять максимум 20 cookies на сервер (или домен) и не более 300 cookies, чтобы избежать перегрузки.

Рис. 2.2 – Обмен cookies между клиентом и сервером

2.4.3 Контроль пользователя над cookies

Как и другие семантические свойства, управление которыми может осуществляться в браузере (см. раздел 2.4.2), cookies допускают значительную степень контроля со стороны пользователя. Пользователи могут:

•Решать, принимать ли какие-либо cookies вообще. Подобное решение может сделать для пользователя невозможным загрузку страниц с некоторых сайтов

•Устанавливать ограничения на размер и количество принимаемых cookie? Тем самым пользователь управляет пространством, которое будет выделен для cookies на его компьютере, и уменьшает вероятность размещения произвольно больших cookies.

•Решать, принимать ли cookies от всех сайтов, или только от определенны сайтов/доменов: Это дает возможность пользователю принимать cookie с нужных сайтов и отклонять cookies с других сайтов.

•Ограничить время жизни cookies только данным сеансом. Более детально управление на уровне сеанса дает возможность пользователю разрешать прием cookies только для выполнения определенной задачи. В конце сеанса осуществляется возврат к режиму по умолчанию, в соответствии с которым, cookies для последующих сеансов не принимаются.

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

2.4.4 Проблемы нарушения конфиденциальности, связанные с cookies

Пожалуй, ни одна другая технология не вызывала столько разногласий, сколько cookies. Cookies широко используются, но в то же время считается, что они могу привести к нарушению конфиденциальности пользователя. Прежде всего, если применение cookies разрешено браузером по умолчанию, многие пользователи могут даже не подозревать, что они используют cookies. Cookies передаются открытым текстом — другими словами, в незашифрованном виде. «Подслушивающая программа, способная перехватывать сетевой трафик, может узнать содержим» cookies. Создается возможность модификации информации cookies по мере прохождения пакетов по сети. Таким образом, конфиденциальную информацию не следует передавать открытым текстом в составе cookies, если только между клиентом и сервером не установлено защищенное коммуникационное взаимодействие. Помимо раскрытия личной информации пользователя, модификация значений сооkies может также привести к изменениям на стороне сервера. Исходный сервер может использовать фрагменты cookies в качестве индексов для обращения к внутренней базе данных, и изменение cookies может привести к непредумышленной модификации базы данных без вмешательства со стороны пользователя. Многие пользователи не знают, кто имеет доступ к информации, извлеченной из cookies, и для чего используется эта информация. Например, информация из cookies может совместно использоваться компаниями, а относящиеся к пользователю данные (профили) могут быть незаконно использованы.

Проблема еще больше усугубляется, если информация из cookies передается серверу, отличному от исходного сервера, которому изначально был послан запрос. Сбор информации третьей стороной может привести к сложно обнаруживаемым и серьезным проблемам с пользовательской безопасностью. Например, агент пользователя U загружает страницу со встроенными изображениями с сервера S. Если встроенные изображения находятся на другом сервере, скажем Е, браузер посылает запросы па сервер Е, который может передать cookies. Теперь браузер будет иметь cookies и от S, и от Е, хотя пользователь явно не обращался к серверу Е. Механизм управления промежуточным состоянием HTTP требует, чтобы агент пользователя прекратил прием и отправку cookies в случае не поддающейся проверке транзакции, т.е. пользователю не предоставляется возможность просмотра URL, запрошенного от его имени. Другими словами, запрос к URL делается без ведома пользователя, и cookies принимаются с сайта, который напрямую пользователем не посещался.

Рассмотрим пример. Пусть компания Doubleclick занимается сбором информации. Предположим, пользователь отправляет запрос на поиск информации в популярную поисковую систему и получает десять гиперссылок на страницы с искомой информацией. URL на эти страницы будут не в виде http://www.foo1.com/foo.html, http://www.foo2.com/bar.html и т.д.

Вместо этого они могут иметь следующий вид:

http://ad.doubleclick.net/x26362d2/www.foo1.com/foo.html. Теперь, когда пользователь щелкает мышью па одной из гиперссылок, запрос посылается на сервер ad.doubleclick.net. Сервер ad.doubleclick.net записывает информацию из cookie пользователя. Информация из cookie связывает два компонента: пользователя, отправившего запрос, и посещенный им сайт www.fool.com. Далее запрос переадресовывается на сервер www.fool.com. Переадресация представляет собой вид HTTP-ответа, который инструктирует браузер отправить другой запрос с иным URL. Переадресация запросов осуществляется прозрачно для большинства пользователей. Если различные серверы, которые пользуются услугами Doubleclick, сотрудничают между собой и совместно используют информацию из cookies одного и того же пользователя, они могут составить себе более подробный «портрет» пользователя.

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

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

2.4.5 Создание и использование cookies

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

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

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

Вместо этого можно указать браузеру включать уникальный cookie в каждым HTTPзапрос. Вернувшись к нашему примеру, предположим, что Web-сервер получил HTTP-запрос па ресурс http://www.bar.com/book.cgi?name=Noam+Chomsky. Запрос содержит cookie. Сервер вызывает сценарий /www/book/cgi и передает сооkie через переменную окружения

НТТР_СООК1Е. Сценарий может использовать сооkie для определения, какие рекламные объявления и предложения следует поместить на Web-страницу. Например, предложения могут быть связаны с книгами по темам, со ответствующим предыдущим покупкам данного пользователя. С точки зрения браузера cookie представляет собой произвольную строку символов. Сценарий же, со своей стороны, связывает с этой строкой определенный смысл. В простейшем случае строя представляет собой просто уникальный идентификатор пользователя, такой как имя пользователя или числовой код. Если запрос не содержит cookie, сценарий может создать новый cookie и включить его в заголовок сообщения-ответа

Set-Cookie: Customer="user17"; Version="1"; Path="/book"

Последующие запросы от этого пользователя будут содержать cookie

Cookie: Customer="user17"; Version="1"; Path="/book"

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

В других ситуациях cookie может содержать дополнительную информации такую как имя пользователя и цвета, которым он отдает предпочтение. Это полезно для динамического создания Web-содержимого, настраиваемого на основе указанных атрибутов. Например, Webстраница может содержать персональное приветствие, включающее имя пользователя. Cookie может также содержать информацию о предыдущих действиях пользователя по просмотру Web-сайта. Хранение накопленной информации в cookie может избавить от необходимости сохранять информацию о пользователе во внутренней базе данных. Например, в cookie сайта электронной коммерции может храниться текущий список заказанных пользователем товаров. Допустим, на сайте электронной коммерции пользователь заполняет различные формы для заказа книг. Пользователь добавляет книгу в список заказываемых товаров, что заставляет браузер послать HTTP-запрос, содержащий cookie, ассоциированный с этим Web-сайтом. Сценарий создает сообщение-ответ, включающий в себя заголовок

Set-Cookie: Order="Chomsky_Bio"; Version="1"; Path="/book"

Затем пользователь добавляет в список еще одну книгу, что инициирует НТТР-запрос, включающий в себя

Cookie: Customer="user17"; Version="1"; Path="/book" Order="Chomsky_Bio"; Version="1"; Path="/book"

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

Браузер трактует cookie как строку, передаваемую от имени пользователя. Однако достаточно искушенные пользователи могут совместно использовать, создавать или модифицировать cookies. Предположим, что Web-сайт не позволяет пользователю загрузить определенный ресурс, если HTTP-запрос не содержит cookie. Пользователи могут сформировать свои собственные cookies, чтобы не допустить отслеживания сайтом их запросов. Кроме того, один пользователь может «позаимствовать» допустимый cookie у другого пользователя, модифицировав строку в серверном ответе Set-Cookie. Обратившись к предыдущему примеру, можно предположить, что искушенный пользователь отправит HTTPзапрос, содержащий cookie, заменив строку user17 на user8. Здесь user8 соответствует корректному пользователю. Чтобы устранить подобные проблемы, cookie может включать некоторую зашифрованную информацию, не дающую пользователям возможность создавать корректные cookie от своего имени. Как часть обработки запроса сценарий может осуществлять проверку cookie на корректность. Хотя это предотвращает использование фиктивных cookies,

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

3 Протокол TCP

Протокол TCP (Transmission Control Protocol, RFC-793, -1323) осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна и пакеты подтверждения доставки ACK. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и telnet. Кроме того, TCP используют системы SMTP, HTTP, X- windows, RCP (remote copy), а также "r"-команды. Прикладные процессы (программы) взаимодействуют с модулем TCP через порты.

Примером прикладного процесса, использующего ветвь TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCPили UDP-модуль согласно коду, записанному в поле «тип протокола» данного IP-пакета. Формат сегмента (пакета) TCP представлен ниже на рисунке 3.1.

Если IP-протокол работает с адресами, то TCP с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента. Поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя. При значении флага syn=1 в этом поле лежит код isn (см. раздел 3.1 – Установление TCP соединения). Поле HLEN – определяет длину заголовка сегмента, которая измеряется в 32-разрядных словах. Далее следует поле резерв, предназначенное для будущего использования, в настоящее время должно обнуляться. Поле размер окна сообщает, сколько октетов готов принять получатель (флаг ACK=1). Окно имеет принципиальное значение, оно определяет число сегментов, которые могут быть посланы без получения подтверждения. Значение ширины окна может варьироваться во время сессии. Значение этого поля равное нулю также допустимо и указывает, что байты вплоть до указанного в поле номер октета, который должен прийти следующим, получены, но адресат временно не может принимать данные. Разрешение на посылку новой информации может быть дано с помощью посылки сегмента с тем же значением поля номер октета, который должен прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная сумма предназначено для обеспечения целостности сообщения. Контрольное суммирование производится по модулю 1. Перед контрольным суммированием к TCP-сегменту добавляется псевдозаголовок, который включает в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая псевдозаголовок. Поле указатель важной информации представляет собой указатель последнего байта, содержащий информацию, которая требует немедленного реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым байтом "важной информации".Если флаг ACK=0, значение поля номер октета, который должен прийти следующим, игнорируется. Флаг urg=1 в случае нажатия пользователем клавиш

Del или Ctrl-c.

Рисунок 3.1 – Структура заголовка TCP-пакета

В таблице 3.1 приведены возможные значения поля “флаги” заголовка TCP.

Таблица 3.1 – Флаги TCP

3.1 Установление TCP соединения

Перед тем как TCP протокол будет готов для передачи данных, необходимо установить TCP соединение. Процедура установления TCP соединения (рисунок 3.1) состоит из трех этапов (в литературе часто встречается термин трехфазовое рукопожатие):

1.Запрашивающая сторона (которая, как правило, называется клиент) отправляет SYN сегмент, указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (в данном примере ISN, 1415531521). Это сегмент номер 1.

2.Сервер отвечает своим сегментом SYN, содержащим исходный номер последовательности сервера (сегмент 2). Сервер также подтверждает приход SYN клиента с использованием ACK (ISN клиента плюс один). На SYN используется один номер последовательности.

3.Клиент должен подтвердить приход SYN от сервера с использованием ACK (ISN сервера плюс один, сегмент 3).