Дело в том, что HTTP-протокол - одноразовый, если так можно выразиться. Т.е. каждый раз заходя на страничку, пользователь начинает сначала, что бы он не вводил, и какие изменения бы не делал. Cookie помогает создать иллюзию, что пользователя помнят на сайте. Пользователю не нужно вводить сотню раз одну и ту же информацию от странички к страничке, и даже от сессии к сессии, она хранится у него на диске. К удобству можно отнести еще и то, что эту информацию пользователь всегда сможет сменить у себя на диске "на лету". В Cookie также могут храниться другие разнообразные данные. Например, количество посещений какой-то страницы, время посещений. С помощью cookie не составляет труда сделать маленький органайзер или корзину в виртуальном магазине.
Cookie многие не любят из-за ее небезопасности. Многие аналитики говорят, что это не проблема, и ничего плохого с помощью данной технологии сделать нельзя. Я с этим глубоко не согласен, если кто-то может читать информацию из файла(ов) cookie, то это уже небезопасно. Приведу чисто теоретические примеры, которые, при желании, не трудно воплотить в реальность. 1. Допустим, пользователь зашел на почтовый сайт, заполнил форму с login'ом и паролем, которые записались в cookie, пускай даже через Secure Socket Level. Взломщик написал письмо пользователю в формате HTML с параметрами чтения cookie с паролями. Прочитав cookie, HTML-файл или запрашивает у пользователя разрешение отослать информацию взломщику, где пользователя можно обмануть ложной надписью а ля "Ошибки в сценариях Javascript!". Даже довольно опытный пользователь не задумываясь нажмет OK, после чего login и пароль отошлется взломщику. Или взломщик может добавить 0-ой фрейм, где будет временно содержаться информация из cookie, которая при ответе на письмо, будет вставляться в конец письма. Все это нетрудно сделать с помощью FORM и Javascript. 2. Пример с виртуальным магазином. Допустим, мы имеем гипотетический магазин shop.provider.com. Совершая покупки в данном магазине, пользователь хранит информацию в cookie. Параллельно или до захода в магазин, пользователь зашел на гипотетическую страницу взломщика hacker.provider.com, где изменялись настройки cookie виртуального магазина. Взломщик может изменить количество покупок, имя, адрес, и все то, что хранится в данном cookie. Я думаю, вам бы не понравилось, если к вашим покупкам прибавили пару мониторов или отвезли ваши покупки не тому пользователю. Сделать это довольно просто, если иметь страничку в домене магазина второго или третьего уровня. Несколько других, уже ПРАКТИЧЕСКИХ примеров, я описывал в статье "Взлом через Cookie" (http://www.nvkz.kuzbass.net/gazzzeta/htm/136.htm).
Итак, для пользователя технология cookie представляет собой несколько файлов в папке %WINDOWS%Cookies (по умолчанию в Internet Explorer), либо всего один файл cookie.txt (если это Netscape Navigator и другие броузеры). Сайты периодически добавляют информацию в cookie и ее же забирают. Естественно, в спецификациях Cookie предусмотрены некоторые элементы защиты.
Всего Cookies может быть не больше 300.
Каждый Cookie не может быть больше 4kb.
С одного домена второго уровня (плюс подуровни) не может быть получено больше 20 Cookies.
Информация из Cookie одного домена второго уровня (плюс подуровни) не может быть прочитана другими доменами.
Если документ кэшируется, то информация о cookie не кэшируется.
Информация виз Cookie может передавать с помощью протокола SSL.
Если лимит исчерпывается, первые записи удаляются. Если Cookie становится больше 4kb, первые байты вырезаются. Формат Cookie.
Полную спецификацию на английском можно найти на http://www.netscape.com/newsref/std/cookie_spec.html. В моей статье только сокращенное описание. Информация в Cookie задается принципом ИМЯ=ЗНАЧЕНИЕ. В одном документе может содержаться несколько Cookies (не больше 20). Минимальное описание поля Cookie выглядит так: Set-Cookie: NAME=VALUE; Максимальное выглядит так: Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
NAME=VALUE - NAME - Имя Cookie, VALUE - Значение. Можно менять как NAME, так и VALUE. Используются любые символы, кроме символа переноса строки, двоеточия, запятой и пробела. Пример: Имя=Вася
expires=DATE - Дата окончания действия Cookie. Менять только DATE. Вид такой: "expires=День, Число-Ден-ГГГГ ЧЧ:ММ:СС GMT". Если expires не обозначен, Cookie хранится до закрытия окна броузера. Пример: expires=Fri, 14-Sep-2005 13:13:13 GMT
domain=DOMAIN_NAME - домен на котором действителен Cookie. Вид такой: "domain=domain.com". Cookie будет действителен как для www.domain.com, так и для myname.domain.com. В зоне RU и других локальных зонах не работает. Используется только для COM, EDU, NET, ORG, GOV, MIL и INT. Если domain не обозначен, используется доменное имя сервера с Cookie. Пример1: domain=mamapapa.com Пример2: domain=gazzzeta.da.ru
path=PATH - Указывает имена докментов, для которых действительно значение Cookie. Вид такой: "path=/word". Cookie будет отсылаться в директориях /word, /word2000 и файлов в текущей директории с именами word.htm, wordchampion.html. Для применения Cookie ко всему серверу указывается корневой каталог сервера /. Если path не указан, Cookie распространяется только на текущую директорию. Пример1: path=/gazzzeta Пример2: path=/
secure - Если указан, при передаче Cookie используется HTTPS (HTTP с SSL - Secure Socket Level). Если secure не указан, Cookie передается HTTP.
Если Cookie использует одинаковое значение NAME, domain и path - старое значение заменяется новым. Вставка Cookie в HTML
Вставить Cookie можно несколькими способами. Самые простой - это через META-тег. Альтернативным способом является Javascript и всевозможные другие технологии (CGI, PHP, SSI и т.д.). Рассматривать CGI, PHP, SSI и прочие мы не будем, т.к. это требует от вашего домена, где располагается страница, возможности использования этих технологий, что бывает не всегда.
Использование Cookie через META-тег. Между тегов и Cookie вписывается так:
Можно использовать несколь META-тегов с Cookie в одном документе. Пример: Использование Cookie через Javascript
Использование Cookie с помощью Javascript является самым популярным способом, т.к. это довольно просто для разработчика, не требует от сервера определенного программного обеспечения и может использовать динамичные данные, генерируемые внутренним Javasript-скриптом, либо вводимые пользователем. Вот примера скрипта Javascript, используещего Cookie. Скрипт не мой, но он точно описывает те возможности, о которых мы говорим. К сожалению, автора скрипта я не знаю поэтому указать не могу. Останавливаться на данном скрипте смысла нет, статья о Cookie, а не о Javascript. Как видите, технология Cookie предоставляет огромные возможности для разработчиков сайтов. Cookie поддерживается всеми более или менее известными броузерами, такими как Netscape Navigator, Microsoft Internet Explorer, Mosaic, Opera и другими, начиная с самых первых версий.
Взлом через Cookie
А зачем мне все это надо? Технология cookie используется при заполнении полей, хранения информации, для виртуальных корзин в Интернет-магазинах, в баннерных сетях и много чего еще. Но также эта технология используется взломщиками для достижения своих целей.
1. Радость от гадости. Первый пример основан на том, что по спецификациям, броузер может хранить не больше 20 записей от одного домена. При переполнении данного лимита, старые записи затираются новыми. Использование: Закачать HTML-файл на тот сервер, откуда пришли cookie. Можно послать по E-mail, если жертва читает почту через Web, все cookie от его почтового сервера сотрутся. Если нужно удалить все cookies с *.домен.com, заменять строчки примера на
Работает только с доменами COM, EDU, NET, ORG, GOV, MIL, INT. Сам пример файла:
...
Сохраняй этот файл как cook.htm, он нам еще пригодится.
2. Полная гадость. Вторая гадость основана на том, что общее количество cookies может быть не больше 300. При переполнении лимита, старые записи также затираются новыми. Уловил мысль? Затираем все cookies жертвы. Сначала тебе придется завести 15 аккаунтов для страничек на разных серверах. Заходим на всякие narod.ru, заводим аккаунты cook.site1.ru, cook.site2.ru и т.д. до cook.site15.ru. Затем заливаем на каждую страничку файл cook.htm, который мы использовали в прошлой гадости. На все это у тебя должно уйти не больше часа при нормальной раскладке пальцев m/. Создаем файлик index.html и вписываем туда следующее:
...
Заливаем созданный файл в любое место, например на cook.narod.ru. Зайдя на этот сайт, у пользователя будет вычищаться весь cookies, накопленный годами, за пару секунд.
3. Почему нельзя забить дисковое пространство или сделать buffer overflow? Дело в том, что каждый cookie не может быть больше 4kb. Если лимит превышен, начало cookie удаляется. Максимум, что можно сделать - забить жертве 1,2mb дискового пространства при хорошем качестве связи у жертвы, либо disconnect'ить жертву при плохой связи. Для этого меняй строчки в cook.htm на следующее:
Защита
Способов защиты несколько и каждый способ довольно неудобен.
1. Отменить использование cookie в броузере. Недостаток в том, что пользователь фактически отказывается ходить на огромное количество сайтов.
2. Завести программу из класса Cookie Manager. Недостаток в том, что надо постоянно держать лишнюю программу. А это для интернетчика с включенным Firewall'ом, антивирусным монитором, ICQ, Dialer'ом и т.д. довольно большое неудобство.
3. Не вступать в случайные связи. Недостаток в том, что твои "проверенные" друзья тоже могут над тобой подшутить, да и не вступать в случайные связи - значит сидеть дома и наслаждаться сайтами по адресу 127.0.0.1.
