Необычный случай произошел в Австрии. Адвокат из Зальцбурга потребовал взыскать с немецкой компании круглую сумму за нарушение правил использования cookies.

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

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

На самом деле, лишь малое число пользователей коснётся это изменение. То есть если вы решили с сегодняшнего дня прекратить пользоваться Google, то ваши данные исчезнут 17 июля 2009 года. Но если вы всё-таки до 17 июля 2009 года снова зашли на сайт Google, срок жизни ваших кукисов автоматически продлится на два года.

Практически на всех более менее крупных проектах имеется система авторизации пользователей по введенному логину и паролю. Человек вводит логин и пароль и если они соответствуют данным в базе, то человек считается авторизованным, для него генерируется сессия и записывается в кукис. Наверное все вы слышали про брутфорс. Многие помнят о нем и реализуют защиту в виде ограниченных попыток ввода логина/пароля с некоторым интервалом. Но практически все забывают о том, что сессию, запрятанную в кукисе можно также брутфорсить. Более того, при аутентификации вы должны знать логин и пароль, а тут только сессию. Да и шаблон сессии (количество символов, какие символы) злоумышленник может посмотреть, зарегистрировавшись на портале.

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

1) Поставьте обязательную привязку к IP.
Если значение сессии из кукиса равно значению сессии из базы, но IP пользователя отличается от IP пользователя записанного в базе (при удачной авторизации), то выводите авторизационную форму с запросом логина и пароля.
Разумеется нужно дать пользователям возможность эту опцию отключить, т.к. иногда провайдеры меняют внешние IP (при натинге) и за полчаса пользователя может несколько раз кикнуть по такому алгоритму. Но по умолчанию опция должна быть включена! Это сильно ограничит взломщика.

2) Сессия должна быть как можно больше, ее длина должна варьироваться и состоять она должна из всех возможных символов.
Чем короче сессия, тем меньше возможных ее вариаций и тем больше вероятность подбора существующей сессии.
При постоянной длине, взломщик, зарегистрировав себе аккаунт, легко определит под какую длину нужно настроить программу — брутфорс, что минимизирует его время.
Т.к. взломщик может зарегистрироваться на портале, он может и собрать статистику по сессиям, из каких символов она состоит. Если он видит, что сессия состоит только из строчной латиницы, то внеся эти правила в свою программу он существенно сэкономит время подбора. Добавив только один дополнительный символ вы существенно увеличиваете время взлома!

3) Подумайте об использовании переменной окружения HTTP_USER_AGENT.
Если вы запишите в базу информацию о браузере и системе авторизированного пользователя и будете делать проверку на это условие при принятии сессии, то как минимум увеличите время взлома в несколько раз.

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

Надеюсь, что эта информация будет полезна веб разработчикам.

Три дня назад (1 февраля) Roger Wang объявил о выходе новой версии движка node-webkit — созданного в недрах Intel Open Source Technology Center мощного сочетания WebKit и Node.js, позволяющего создавать кросс-платформенные графические приложения методом веборазработки на языках HTML, CSS и JavaScript.

Новая версия имеет номер 0.4.1; на её основе нетрудно составить и запустить, например, вот такое окно:



Почти семь недель прошло с того дня (18 декабря), когда я обозревал одну из предыдущих версий (0.3.6) этого движка. Вам нетрудно заметить, что за это время успела перемениться не только последняя, но и предпоследняя цифра версии. Сейчас я расскажу, какие изменения, в node-webkit произошедшие, отражает эта перемена.

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

Оказывается, есть способ отслеживать отдельных не вошедших в систему пользователей без использования файлов cookie. Я тоже реализовал это. Сейчас покажу как.

Для наглядности я создал демо-сайт. Вот он.

Нажмите на каждую из трёх кнопок Page → На всех трёх один и тот же идентификатор.
Закройте окно браузера и снова откройте сайт → Идентификатор не поменялся.
Выключите компьютер и зайдите на эту веб-страницу завтра → Идентификатор всё тот же.
Проверьте ваши куки → Демо-сайт не записывает куки и не считывает их.
Проверьте URL → Сомнительные строки запроса отсутствуют.

Итак, как именно я могу хранить идентификатор и узнавать, что вы с определённого устройства возвращаетесь на сайт, при этом без входа в систему и без использования куки?