Xpoint
   [напомнить пароль]

Улучшает ли безопасность отключение cookie?

Зачем нужны cookie?

Сайтам очень важно узнавать своих посетителей, отличать их друг от друга. "Узнавание" позволяет реализовать такие вещи, как запоминание покупок в корзине интернет-магазина, позволяет не запрашивать логин и пароль при каждом просмотре требующих авторизации страниц и пр. Этот механизм носит обозначение "сессия".

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

Как работают cookie?

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

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

Почему у cookie плохая репутация?

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

Тут есть одно "но". До недавнего времени в Microsoft Internet Explorer (до выхода Windows XP Service Pack 2) картинки-счетчики могли устанавливать cookie, а поскольку один и тот же счетчик стоит на множестве сайтов, была возможность отслеживать посетителей и между разными сайтами.

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

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

Какие есть альтернативы cookie?

Все еще встречаются системы, которые идентифицируют пользователя по IP-адресу. В этом случае IP-адрес выступает в качестве идентификатора сессии, браузеру ничего запоминать не нужно. Это очень ненадежно. К примеру, 2 пользователя, пользующихся одним proxy-сервером, будут иметь один и тот же IP-адрес.

Хранить и передавать идентификатор браузера можно не только в cookie, для этого может использоваться и адресная строка. Это и есть основная альтернатива. В этом случае адреса выглядят примерно так:
httр://example.com/?SID=0cc8e376cbaf46f65394f9277172703c. Сайт дописывает ко всем внутренним ссылкам на своих страницах этот идентификатор, так что на какую бы из ссылок ни кликнул пользователь, идентификатор будет передаваться на сервер с каждым запросом.

Что мы получаем в этом случае? Сервер по прежнему отслеживает посетителей. Мы "побороли" cookie, но не сессии. Правда, посетитель может стереть из адресной строки идентификатор сессии, после чего станет для сервера словно бы новым посетителем, то есть человеку легче заставить сервер "забыть" о нем.

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

Получается, что как раз отключение cookie вкупе с передачей referer'а представляет собой серьезную брешь в безопасности. Потом, пользователь ведь может отправить эту ссылку по электронной почте или иным способом другому человеку. И опять же идентификатор в URL (в отличие от такового в cookie) перешлется вместе со ссылкой.

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

При передаче идентификатора сессии в URL его можно потерять, перейдя по ссылке, не снабженной идентификатором (если таковая окажется на сайте), или попав на страницу, где идентификатор еще не был выдан, к примеру, нажав кнопку браузера "Назад".

Вывод

Основные проблемы с безопасностью вызывают именно хранимые cookie, как раз с их помощью можно отслеживать вкусы пользователя в течение периодов, достаточных для анализа (а это гораздо больше обычного времени жизни сеансовых cookie). И именно в них хранятся пароли при реализации механизма "запомнить пароль". То есть следует различать сеансовые и хранимые cookie и, если уж отключать, то только последние.

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

p.s. Личное мнение автора этого текста в том, что и хранимые cookie имеют право на жизнь и нет смысла их отключать, но тут уже у него нет железных аргументов.

Комментарии

2006-02-20 21:20:28 [обр] Алексей Серебряков[досье]

Как всегда, дело не в технологии, а в кривых руках и непонимании проблемы орущими журналистами.

При нормальном раскладе, украв чужой cookie, сделать ничего нельзя, потому что не должно быть(!!!) в cookie чувствительной информации. С тех идиотов, которые решили записывать в cookie пароль от сайта, и началась эта истерия.
 
А сессии хранить? Да пожалуйста. Привяжите сессию к IP, к браузеру — хоть к чему привяжите. Вероятность перехвата уменьшится катастрофически.

спустя 1 час 13 минут [обр] Сергей Круглов[досье]

К IP привязывать нельзя, насколько мне известно, клиенты некоторых провайдеров могут изменять свой IP во время одного соединения. Хотя тот же newmail.ru привязывается к IP.

Потом, статья написана не столько для сайтостроителей, в чьих силах привязывать сессию к ip, браузеру и пр., а для пользователей и администраторов. Чтобы они не "слышали звон", а были в курсе проблемы.

спустя 13 часов [обр] Даниил Иванов[досье]
Сергей Круглов[досье]
Мне кажется, в целях безопасности вполне можно привязать ID сессии к IP. Если клиент вдруг во время сеанса поменяет IP-адрес (случай всё-таки редкий), то просьба повторно ввести пароль - небольшая плата за резкое повышение безопасности.
спустя 5 часов [обр] Владимир Палант[досье]
Даниил Иванов[досье]
Мне так не кажется. Может в России это сейчас случай и редкий, но это временно. К примеру DSL в Германии с настройками по умолчанию рассоединяет соединение после минуты бездействия. Если после этого пользователь на что-нибудь щелкнет, то соединение опять установится, но уже с другим IP. А что касается "небольшой платы" — так говорит тот, кто сам никогда не сталкивался с этой проблемой. Поверьте мне, на сайте, который регулярно спрашивает мой пароль, я долго не задержусь. И большинству пользователей плевать, что это для их же безопасности — они просто не знают, что такое IP.
спустя 2 дня 18 часов [обр] Victor Gr.[досье]

Что сложного привязать к USER_AGENT?
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060111 Debian/1.5.dfsg-3bpo1 Firefox/1.5" - много у кого такая строка повторится?

А если скрипт закрыт, то довольно тяжело узнать логику его работы.

спустя 2 дня 2 часа [обр] Сергей Круглов[досье]
Такая - мало, а Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) у каждого третьего, я думаю.
спустя 2 часа 55 минут [обр] Даниэль Алиевский[досье]

Владимир Палант[досье] А почему не спасает способность броузера запоминать пароль в формах? Я вообще почти никогда не ввожу пароль и не очень ценю способность сайтов запоминать его в хранимых куках. Ведь FireFox умеет автоматически заполнять форму логином и паролем. Если сайт организован грамотно, то в FireFox достаточно будет после упомянуй вами смены IP нажать 1 лишнюю кнопку.

Также интересно - а в каких пределах эти провайдеры меняют IP? Если, допустим, в рамках подсети (256 адресов), то почти так же надежно привязаться к старшим 24 битам IP. Маловероятно, что вор окажется в той же подсетке. Или это никак не регламентировано?

Что до USER_AGENT, то туда можно добавить все прочие заголовки запроса и даже клиентскую информацию (вроде разрешения экрана или текущего языка).

спустя 15 часов [обр] Сергей Круглов[досье]

Victor Gr.[досье] Ой, подождите, дык браузер вместе с реферером и userAgent сообщит же... ;)

Защитникам привязки к IP: А если и жертва, и злоумышленник имеют 1 IP-адрес? Ну, они, например, работают в одной организации или сидят в одном интернет-кафе...
Я к тому, что идея о неиспользовании cookie для хранения SID порочна в принципе, а все призязки - только шаткие подпорки, не дающие 100% уверенности.

спустя 2 дня 13 часов [обр] Владимир Палант[досье]

Victor Gr.[досье]
Ага, ждите... Ну и что, что скрипт закрыт? Если видно, что авторизация зависит не только от кук, то лишь болван не подумает на USER_AGENT. Чтобы разобраться с механизмом авторизации в предыдущей реинкарнации Xpoint, мне понадобилось ровно две минуты (там как раз была зависимость от USER_AGENT). А если человек может украсть куки, то украсть USER_AGENT и подобную информацию тем же способом не представляет труда. Заметьте, что при этом вы опять же причиняете неудобства нормальным пользователям — раньше на Xpoint были проблемы с просмотром исходников страниц (Mozilla при скачивании исходников слегка менял USER_AGENT, аналогично поступает IE при скачивании для работы в offline-режиме).

Даниэль Алиевский[досье]
Не имею привычки пользоваться этой функцией — сижу как правило за рабочим компьютером.

Область IP-адресов DSL не смотрел, но довольно давно проверял это для обычных dial-up'ов. Тогда получалось, что в крупных городах нередко используются подсети с 1024 адресами, а то и вовсе две не связанные между собой подсети.

спустя 6 дней [обр] Александр Носов[досье]

Подолью и своего масла в огонь.
Про эту проблему я читал давно и именно на xpoint (как бы ни Вы, Владимир Палант[досье], ее и поднимали).
Так вот там она рассматривалась более остро.

Ждать пока кто-то кликнет на ссылку и перейдет на твой сайт - это можно очень долго. Гораздо "эффективней" вставлять на чужие сайты картинки, которые грузятся со своего собственного сервера (если конечно тот сайт позволяет это делать!). Дело в том, что для картинки загружаемой внутрь html-кода браузер тоже передает referer.
И не надо быть семи пядей во лбу, чтобы настроить свой сервер так, чтобы он даже "класические" запросы, типа: http://example.com/images/some-image.com, сначала обрабатывал каким-то скриптом, а уже потом отдавал ту картинку, которую надо отобразить.

А уже в самом серверном скрипте можно автоматом отсеивать урлы не содержащие SID, а те которые его содержат - посылать по мылу владельцу. Все будет "автоматизировано" до предела. И логи "руками" просматривать не придется, и SID-ы "горячие" будут попадаться, которые еще не успели умереть. Надеюсь, юные хакеры не примут этот абзац, как руководство к действию. ;)

Впрочем, аналогичный скрипт можно повесить и на ссылку про которую говорилось в статье. Но все-таки вероятность поймать такой урл через картинку почти 100%, если конечно у клиента не отключены картинки, а по ссылке еще не каждый кликнет.

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

P.S. По условиям того прошлого обсуждения, как раз главным условием и была необходимость дать возможность безопасно грузить картинки и пр. с других сайтов.

спустя 16 часов [обр] Владимир Палант[досье]

Да, я поднимал, довольно давно, и результаты обсуждения я помню. Но эта статья вообще упрощенная. Конечно, вручную ничего делать не обязательно, всё хорошо автоматизируется. И на самом деле, конечно, на ссылки есть управа — их меняют, чтобы пользователь сначала попадал на страницу без SID, а уже с нее на внешний сайт. А вот с картинками ничего не поделать. В той теме предлагалось какое-то жуткое извращение, но я им пользоваться не стал. Просто перенес идентификатор сессии в cookie для всех, у кого они включены. А кто ходит с отключенными cookie — тот рискует.

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

спустя 2 месяца 11 дней [обр] Arioch[досье]

Междоменные куки ы самом любимом браузере таки были дыркой в безопасности и не у всех стоят обновления.

Кроме того, куки в отличие от сессий - действуют не минуты а дни/месяцы
Ты можешь не знать пароля, но зайдя с этим куки будешь залогиненным юзером.

Передача Session ID в URL'е - еще хуже, но не даром же есть и GET и POST :)
В URLе передавать не обязательно.

спустя 11 дней [обр] Сергей Круглов[досье]
Arioch[досье]
> Кроме того, куки в отличие от сессий - действуют не минуты а дни/месяцы
Неправда. К тому же куки и сессии нельзя сравнивать, одно есть средство для реализации другого.
> но не даром же есть и GET и POST
Вы POSTом предлагаете между страницами ходить?
Вы не обижайтесь, но вы сначала опыта наберитесь, а потом дяденек критикуйте.
Powered by POEM™ Engine Copyright © 2002-2005