Мне не хочется забивать вам голову техническими подробностями, поэтому я кратко скажу, что такое Cookies и, нет, не с чем их едят, а как с ними нужно работать.
Представим, что перед нами поставлена такая задача: нужно написать индивидуальный счетчик посещения для каждого клиента сайта нашей компании. То есть, чтобы пользователь знал, сколько раз именно он был на нашем сайте, а не видел общее количество посещений.
Можно решить данную задачу двумя способами. Первый способ заключается в том, чтобы вести учет по IP -адресу. Для этого нужна база данных, состоящая всего из одной таблицы, структура которой примерно такова:
Посещения |
|
111. 111.111.111 |
|
Когда пользователь заходит на наш сайт, нам нужно определить его IP , найти в базе данных информацию о его посещениях, увеличить счетчик на единицу и вывести его в браузер. Определять IP-адрес клиента мы уже сумеем (переменная $REMOTE_ADDR), поэтому нам несложно написать такую программу. Однако при использовании данного способа рано или поздно «всплывут» две проблемы:
Для каждого IP -адреса нужно будет вести учет в одной таблице, которая, скорее всего, будет большой, а из этого следует, что мы нерационально используем процессорное время и дисковое пространство. Гораздо правильнее с нашей стороны будет использовать это пространство с большей пользой.
У большинства домашних пользователей IP -адреса динамические. То есть, сегодня у него адрес 111. 111.111.111, завтра -- 111.111.111.118. И попробуй потом определить, кто есть кто. Можно ввести регистрацию с использованием
имени пользователя и пароля, но это еще больше увеличит нашу базу данных и создаст неудобства для клиентов.
Ясное дело, что данный способ нам не поможет. Остается использовать второй способ, который намного легче в реализации. Мы устанавливаем Cookie - переменную, которая будет храниться на диске у пользователя. Эта переменная и будет хранить информацию о посещениях. Она будет считываться сценарием при обращении пользователя к серверу. Выгода очевидна. Во-первых, нам не нужно хранить ненужную информацию о IP -адресах, во-вторых, нам не страшны динамические IP -адреса, поскольку данные о своих посещениях хранятся у клиента.
Теперь нам ясно, для чего используются Cookies - для хранения небольшой по объему информации у клиента, например, его логина (но ни в коем случае не пароля!), настроек сайта (цветовая гамма, язык, и т.д.) и другой информации.
Почему небезопасно хранить пароль в Cookies ? Получив от сервера Cookie - переменную, браузер сохраняет ее на диске в открытом виде, то есть, не кодируя ее. Любой, кому не лень, может просмотреть значения этой переменной. Кроме того в некоторых браузерах Cookies вообще сохраняются в обыкновенном тектовом файле, а некоторые - даже позволяют просмотреть их. Например, в браузере Mozila для просмотра
Сооkies выполните команду меню Edit-Preference-Security-Cookes
В этом разделе ны можете включить (Enable) или отключить (Disable ) прием Cookies, установить максимальный срок хранения Cookie (Limit maximum lifetime) :
Current session (Текущая сессия) - переменная будет удалена по окончании сессии работы с сайтом (например, когда пользователь закроет окно сайта).
Установить определенное количество дней, по истечении которых все принятые Cookies будут удалены.
Нажмите кнопку Manage Stored Cookies . Появится окно с информацией обо всех установленных Cookies
Щелкните на имени установленной Cookie -переменной, чтобы получить информацию о ней:
Name - имя переменной;
Information - информация, которую содержит Cookie;
Host - узел, установивший переменную;
Secure Server - признак того, что Cookie должна передаваться через защищенное (HTTPS ) соединение:
Expires - время жизни Cookie . Значение at end of session означает, что Cookie будет «жить» до конца сессии.
Кнопка Remove Cookie удаляеттекущую переменную, а кнопка Remove All Cookies удаляет iscc Cookie -переменные.
Вы часто покупаете товары в Интернет-магазинах? Тогда рекомендую время от времени (скажем, раз в месяц) удалять все Cookies . Зачем? Вы увидите, что цены станут ниже. Дело в том, что некоторые Интернет-магазины (особенно, «буржуйские») грешат на доверии клиентов. Пару раз они могут продать вам товар по заниженным пенам, затем вы, зная, что это самый дешевый в Интернете магазин, будете покупать товары только у них. А они как раз и воспользуются Cookies - будут сознательно завышать цены на все товары, когда вы в очередной раз будете делать покупку, уверяя себя, что экономите деньги. При этом с помощью Cookies Интернет-магазины будут определять, кто вы такой и что вы раньше покупали.
Однако не нужно совсем отключать Cookies . Некоторые сайты станут загружаться некорректно. Если вы боитесь, что через Cookies можно получить вирус, то не беспокойтесь: даже если кто-то передаст вам с помощью Cookies «вредный код», то система не сможет его запустить, так как Cookies хранятся в текстовом виде (а в Linux для Cookies не устанавливается право за запуск файла).
Перед тем, как начать работу с Cookies , позволю себе пару замечаний относительно выбора браузера. Для отладки ваших сценариев, если они используют Cookies , я рекомендую использовать браузер Mozilla , поскольку он позволяет эффективно управлять Cookies . Если этот браузер вас почему-то не устраивает, используйте Konqueror , который также позволяет просмотреть подробную информацию о полученных Cookies . Браузеры Internet Explorer версий 4 и 5 не позволяют этого сделать.
2 . Программирование Cookies
Установка Cookies
Вот теперь можно приступить к программированию Cookies . Для установки Cookies используется функция SetCookie . В общем случае для этой функции можно указать целых шесть параметров, но обязательный из них является только один - пате:
namе - задает имя (строка), закрепленное за Cookie .
value - определяет значение переменной (строка).
expire - время жизни переменной (целое число). Если этот параметр не указан, Cookie будет «жить» до конца сессии, то есть до закрытия браузера. Если время указано, то, когда оно наступит, Cookie самоуничтожится.
path - путь к Cookie (строка).
domain - домен (строка). В качестве значения устанавливается имя хоста с которого установили.
secure - передача через HTTPS -соединение.
Обычно используются только три первые параметра. В листинге 4 приведены несколько примеров установки Cookies .
Листинг 4. Примеры установки Cookies
/./ До конца сессии
SetCookie("Test","Value");
.// Время жизни - один час после установки
SetCookie("My_cookie", "One hour",time()+3600); ?>
При использовании Cookies нужно иметь в виду, что Cookies должны быть установленными до первого вывода сценария (будь то оператор echo или вывод какойнибудь функции). Поэтому желательно устанавливать Cookies в самом начале сценария. Дело в том, что Cookies устанавливаются с помощью определенного заголовка сервера, а если вы выводите что-нибудь, то это означает, что начинается тело документа. В результате Cookies не будут установлены. Вот что вы получите, если установка Cookies
невозможна: Warning: Cannot add header information - headers already sent by (output started at /var/www/html/cookie.php: 2) in /var/www/ html/cookie.php on line 4
Чтение значений Cookies
Получить доступ к Cookies достаточно просто. Все они хранятся к переменной окружения НТТР_СООК1Е . Если мы установили несколько Cookies , то в переменной НТТР_СООК1Е они будут перечислены через «;» (через точку с запятой). Например: mycookiel=valuel;mycookie2=value2.
Для чтения значения Cookies можно обращаться к ним, как к обыкновенным переменным. Например: echo $Test ; Только не забудьте проверить существование переменной. В заключение приведу пример «индивидуального счетчика» посещений. Код сценария приведен в листинге 5.
Листинг 5. Индивидуальный счетчик с помощью Cookies
// Если переменная не существует, объзляем ее if (! isset(51na Counter); $lnd Counter = 0;
// Увеличиваем счетчик
/* Устанавливаем Cookie которая будет жить до переустановки пользователем Windows, то есть очень долго. Если вам интересно, то браузер удалит ее 18/07 ,-"2 9 08:49 */
SetCookie ("Jnd_ Counter", $ I na_ Counter, Ox6FFFFFFF) ; echo "Вы посетили этот сайт $Ind_Counter раз"
Выше я говорил, что перед установкой Cookies нельзя использовать оператор echo . Только что я сам допустил подобную ошибку. Если оператора echo и вашей программе нет (по крайней мере до вызова SetCookie() ), a Cookies невозможно установить, убедитесь в том, что символы маркера начала программы -
Начало сайта
Естественно, что символ \n я не увидел, а PHP «подумал», что это фрагмент HTML -документа. В результате Cookies не были установлены, так как Cookies устанавливаются при формировании заголовка документа, а после первого вывода сценария формирование заголовка прекращается.
Cookies - верная технология, позволяющая веб-сайту "запомнить" пользователя,
сохранить его настройки и не спрашивать каждый раз его логин и пароль. Можно
подумать, что если удалить кукисы в браузере, то сайт тебя не узнает. Но эта
уверенность обманчива.
Можно сколько угодно заморачиваться о своей анонимности, использовать прокси
и VPN, подделывать заголовки HTTP-запросов, выдающие используемую систему,
версию браузера, часовой пояс и море другой инфы, но у веб-сайта все равно
останутся способы распознать факт того, что ты на нем уже бывал. Во многих
случаях это не особо критично, но только не в ситуации, когда на каком-то
сервисе необходимо представиться другим пользователем или банально сохранить
анонимность. Легко представить, как среагирует антифрод-система некой условной
финансовой организации, если определит, что с одного компьютера были выполнены
авторизации под аккаунтами совершенно разных людей. Да и разве приятно
осознавать, что кто-то в Сети может отслеживать твои перемещения? Едва ли. Но
обо всем по порядку.
Как работают куки?
Чтобы идентифицировать пользователя, испокон веков использовались кукисы.
Cookies (от англ. "печенье") - это небольшая порция текстовой информации,
которую сервер передает браузеру. Когда пользователь обращается к серверу
(набирает его адрес в строке браузера), сервер может считывать информацию,
содержащуюся в cookies, и на основании ее анализа совершать какие-либо действия.
Например, в случае авторизованного доступа к чему-либо через веб в cookies
сохраняются логин и пароль в течение сессии, что позволяет пользователю не
вводить их снова при запросах каждого документа, защищенного паролем. Таким
образом, веб-сайт может "запомнить" пользователя. Технически это выглядит
следующим образом. Запрашивая страницу, браузер отправляет веб-серверу короткий
текст с HTTP-запросом.
Например, для доступа к странице www.example.org/index.html браузер
отправляет на сервер www.example.org следующий запрос:
GET /index.html HTTP/1.1
Host: www.example.org
Сервер отвечает, отправляя запрашиваемую страницу вместе с текстом,
содержащим HTTP-ответ. Там может содержаться указание браузеру сохранить куки:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Если есть строка Set-cookie, браузер запоминает строку name=value (имя =
значение) и отправляет ее обратно серверу с каждым последующим запросом:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value
Accept: */*
Все очень просто. Если сервер получил от клиента куки и они есть у него в
базе, он однозначно может их обработать. Таким образом, если это были кукисы с
некоторой информацией об авторизации, у пользователя в момент посещения не будет
спрашиваться логин и пароль. По стандарту куки имеют определенный срок жизни
(хоть он и может быть очень большим), после которого умирают. А любые
сохраненные кукисы пользователь без труда может удалить, воспользовавшись
соответствующей опцией, которая есть в любом браузере. Этот факт сильно
расстраивает владельцев многих ресурсов, которые не желают терять связь с
посетителем. Им важно отслеживать его, понимать, что "вот этот человек был у нас
вчера, а еще позавчера и т.д.". Особенно это касается различных анализаторов
трафика, систем для ведения статистики, баннерных сетей и т.п. Вот тут-то и
начинается самое интересное, потому что разработчики используют всякие
ухищрения, о которых многие пользователи даже не подозревают. В ход идут
различные уловки.
Flash-куки
Все дело в том, что помимо обычных HTTP "плюшек", к которым все давно
привыкли, сейчас активно используются альтернативные хранилища, где браузер
может записать данные на стороне клиента. Первое, что нужно упомянуть - это
хранилище любимого и ненавистного одновременно Flash (для тех пользователей, у
которых он установлен). Данные хранятся в так называемых LSO (Local Shared
Objects) - схожих с cookies по формату файлах, которые сохраняются локально на
компьютере пользователя. Подход во многом аналогичен обычным "плюшкам" (в этом
случае на компьютере пользователя точно так же сохраняется небольшое количество
текстовых данных), но имеет некоторые преимущества:
- Flash-кукисы являются общими для всех браузеров на компьютере (в отличие
от классической cookie, которая привязана к браузеру). Настройки, информация
о сессии, как и, скажем, некий идентификатор для отслеживания пользователя,
не привязываются к какому-то конкретному браузеру, а становятся общими для
всех. - Flash cookie позволяет сохранять намного больший объем данных (как
правило, 100 Кб), что увеличивает количество настроек пользователя,
доступных для сохранения.
На практике LSO становится очень простой и доступной технологией для трекинга
пользователя. Задумайся: если бы я предлагал тебе удалить все "плюшки" в
системе, ты бы вспомнил о Flash-кукисах? Вероятно, нет. А теперь попробуй взять
любой просмотрщик, например, бесплатный
FlashCookiesView и посмотреть, сколько всего интересного записано в
хранилищах Flash. Тут же вырисовывается и список сайтов, которые очень не хотят
потерять твой след, даже если ты подчистишь кэш браузера (вместе с "плюшками").
Кукисы везде с evercookie
Но если об LSO слышали продвинутые пользователи и мало-мальски хорошие
разработчики, то о существовании других техник хранения данных, подчас очень
изощренных (но действенных), многие даже не подозревают. Взять хотя бы новые
хранилища, которые появлялись в
(Session Storage,
Local Storage, Global Storage, Database Storage via SQLite), о которых ты можешь
прочитать в статье " ". Этой проблемой всерьез заморочился польский специалист
по безопасности Samy Kamkar. В результате на свет появилась специальная
JavaScript-библиотека evercookie, которая специально создана для того, чтобы
создавать максимально живучие кукисы в браузере. Кто-то может спросить: "Зачем
это нужно?". Очень просто: для того, чтобы однозначно идентифицировать
посетителя страницы, если он придет вновь. Такие сложно убиваемые кукисы часто
называются Tracking cookies и даже определяются некоторыми антивирусами как
угроза приватности. Evercookie может свести все попытки остаться анонимным к
нулю.
Секрет в том, что evercookie использует сразу все доступные для браузера
хранилища: обычные HTTP-кукисы, LSO, контейнеры HTML5. Кроме того, в ход идет
несколько хитрых приемов, которые с не меньшим успехом позволяют оставить на
компьютере желанную метку. Среди них: генерация особых PNG-изображений,
использование history браузера, хранение данных с помощью тега ETag, контейнер
userData в Internet Explorer - оказывается, что вариантов-то очень много.
В том, насколько это эффективно работает, можно убедиться на сайте
разработчика -
http://samy.pl/evercookie . Если нажать на кнопку "Click to create an
evercookie", в браузере будут созданы кукисы со случайным числом. Попробуй
удалить кукисы везде, где это только возможно. Бьюсь об заклад, сейчас ты
задумался: "Где еще можно удалить кукисы, кроме как в настройках браузера?".
Уверен, что все удалил? Перезагрузи страницу для верности, можешь даже заново
открыть браузер. Вот теперь смело нажимай на кнопку "Click to rediscover cookies".
WTF? Сайту это не помешало откуда-то взять данные - в полях страницы
отобразилось число, которые было сохранено в кукисах. Но мы же их потерли? Как
это получилось? Попробуем разобраться с некоторыми техниками.
Кукисы в PNG
Крайне интересным приемом, используемым в Evercookie, является подход
хранения данных в кэшированных PNG-изображениях. Когда evercookie устанавливает
куки, он обращается к скрипту evercookie_png.php со специальной HTTP "плюшкой",
отличной от той, которая используется для хранения стандартной информации о
сессии. Эти специальные кукисы считываются PHP-сценарием, создающим
PNG-изображение, в котором все значения RGB (цветов) выставляются в соответствии
с информацией о сессии. В конечном итоге PNG-файл отправляется браузеру клиента
с пометкой: "файл необходимо кэшировать 20 лет".
Получив эти данные, evercookie удаляет созданные ранее специальные
HTTP-кукисы, затем выполняет тот же самый запрос к тому же PHP-сценарию, но не
предоставляя информации о пользователе. Тот видит, что интересующих его данных
нет, и сгенерировать PNG он не может. Вместо этого браузеру возвращается
поддельный HTTP-ответ "304 Not Modified", что заставляет его вытащить файл из
локального кэша. Изображение из кэша вставляется на страницу с помощью тега
HTML5 Canvas. Как только это происходит, evercookie считывает каждый пиксель
содержимого Canvas, извлекая RGB-значения и, таким образом, восстанавливая
данные изначальных кукисов, которые были сохранены в изображении. Вуаля, все
работает.
Хинт с Web History
Другой прием напрямую использует историю браузера. Как только браузер
устанавливает плюшку, evercookie с помощью алгоритма Base64 кодирует данные,
которые необходимо сохранить. Предположим, что этими данными является строка,
полученная "bcde" после преобразований в Base64. Библиотека последовательно
обращается в фоновом режиме к следующим URL:
google.com/evercookie/cache/b
google.com/evercookie/cache/bc
google.com/evercookie/cache/bcd
google.com/evercookie/cache/bcde
google.com/evercookie/cache/bcde-
Таким образом, эти URL сохраняются в history. Далее в ход идет специальный
прием - CSS History Knocker, который с помощью JS-скрипта и CSS позволяет
проверить, посещал ли пользователь указанный ресурс или нет (подробнее тут -
samy.pl/csshack). Для
проверки плюшек evercookie пробегается по всем возможным символам Base64 на
google.com/evercookie/cache, начиная с символа "a" и двигаясь далее, но только
на один символ. Как только скрипт видит URL-адрес, к которому было обращение, он
начинает перебор следующего символа. Получается своеобразный брутфорс. На деле
этот подбор осуществляется чрезвычайно быстро, потому что никакие запросы к
серверу не выполняются. Поиск в history осуществляется локально в максимально
короткий срок. Библиотека знает, что достигла конца строки, когда URL будет
заканчиваться символом "-". Декодируем Base64 и получаем наши данные. Как
назвать разработчиков браузеров, которые это позволяют?
Попробуй удали
А что будет, если юзер потрет свои кукисы? Важная фишка самой библиотеки
evercookie в том, что пользователю придется основательно постараться, чтобы
удалить кукисы, оставленные в разных местах - сейчас их 10. Если хотя бы в одном
месте останутся данные куки, то они автоматически восстановятся и во всех других
местах. Например, если пользователь не только удалит свои стандартные кукисы, но
и очистит данные LSO, подчистит HTML5-хранилища, что уже маловероятно, все равно
останутся куки, созданные с помощью кэшированного PNG и web history. При
следующем же посещении сайта с evercookie библиотека не только сможет найти
запрятанную плюшку, но и восстановит их во всех остальных местах, которые
поддерживает браузер клиента. Интересный момент связан с передачей
"плюшек" между браузерами. Если пользователь получает кукисы в одном браузере,
то есть большая вероятность, что они воспроизведутся и в других. Единственное
необходимое для этого условие - сохранение данных в Local Shared Object куке.
Как использовать?
Библиотека Evercookie полностью открытая, поэтому ты можешь свободно
пользоваться ей, подгонять под свои нужды. К серверу не предъявляется никаких
серьезных требований. Все что нужно - это доступ к JS-сценарию, в котором
содержится код evercookie. Чтобы использовать Flash-кукисы (Local Shared Object),
в папке со скриптом должен быть файл evercookie.swf, а для работы техник,
основанных на PNG-кэшировании и использовании хранилища ETag, необходим доступ к
PHP-сценариям evercookie_png.php и evercookie_etag.php. Использовать evercookie
можно на любой страничке сайта, подключив следующий скрипт: