Существует ли способ предотвратить кражу файлов cookie?

Question

в приложениях Web 2.0 многие пользователи обычно хотят оставаться в системе (флаг «помни меня»), а с другой стороны, их куки могут предоставить доступ к очень приватным данным. Есть ли способ предотвратить то, что кто-то, кто украл cookie-файл - непосредственно с компьютера или с помощью сниффинга, может использовать cookie-файл для получения доступа к данным пользователя? Всегда HTTPS не вариант.

Спасибо, Бернд

[Изменить] Подключить IP-адрес к cookie-файлу тоже не вариант.

Answer 1

KISS - просто используйте сеансы, чтобы использовать идентификатор, который уже автоматически создается на языке сценариев на вашем сервере. Это достаточно сложно угадать. Затем, если он украден, сохраните IP-адрес и пользовательский агент посетителя в сеансе (следя за тем, чтобы его никогда не выводили) и считайте сеанс действительным только в том случае, если уже сохранено IP-адрес и пользовательский агент совпадают с тем, который найден для удаленного клиента.

В этом сценарии злоумышленник должен сделать следующие три вещи:

1. Украсть печенье жертвы
2. Подмена правильного IP-адреса
3. Поддать правильный агент пользователя

Это также помогает убедиться, что злоумышленник еще не знает всех вещей, которые он / она должен будет сделать, чтобы правильно перенести сеанс жертвы. IE: Они могут предположить, что нужен только файл cookie, а затем потерпеть неудачу ... и должны выяснить все остальное с помощью очень долгих проб и ошибок. Таким образом, вы получаете безопасность через мрак и трудности, в зависимости от навыка атакующего и его / ее существующих знаний о системе.

Answer 2

Бернд - проблема со всем, что делается по стандартному HTTP, заключается в том, что он является открытым текстом; любой может подделать что угодно. IP-спуфинг - это более сложная задача, чем простая кража файлов cookie, поэтому привязка к IP-адресу обычно является тем, что делают люди. Как вы сказали, это не очень хорошо работает в высокодинамичных средах.

Единственный наиболее безопасный способ, который я могу придумать, - это использовать HTTPS для размещения и проверки «постоянного» cookie, а затем поместить (в том же сеансе HTTPS) краткосрочный cookie сеанса. Остальное общение может быть выполнено по обычному HTTP с использованием куки-файла сессии для аутентификации.

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

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

Надеюсь, это поможет.

Answer 3

О хранении сложных файлов cookie и связанных с ними IP-адресов в базе данных - вам действительно не нужно этого делать. Если у вас есть секретный ключ K, достаточно зашифровать ip пользователя с помощью вашего K и поместить результат {IP} K в файл cookie. Пока ваш ключ защищен (а криптография не взломана - но если это произойдет, у нас будут большие проблемы), это безопасно.

Answer 4

Возможно, было бы хорошим подходом использовать идентификатор сеанса и токен (хэш, основанный на IP, соли и идентификаторе сеанса), который восстанавливается при каждом запросе (используется алгоритм быстрого хеширования)? Я храню данные сеанса в базе данных (в настоящее время), и это означает, что у меня есть два запроса на каждый запрос. Это работает так:

1. Выберите, где совпадают SID и TOK.
2. Убедитесь, что токен, сгенерированный на основе текущего клиента, совпадает с данным в базе данных.
3. десериализация данных в свойство.
4. Сценарии и т. Д.
5. Сериализация обновленных данных, восстановление SID / TOK и обновление базы данных, где SID / TOK = старые sid и ток, обновленные данные и новые sid и ток. Установите для cookie новый SID и TOK.

Таким образом, во-первых, cookie-файлы привязываются к тому, на чем я основываю токен (в данном случае к удаленному адресу), и, если он украден и данные клиента подделаны, cookie в любом случае будет полезен только для одного запроса - к тому времени. cookie перехвачен, он бесполезен.

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

Answer 5

Поставьте крышку на банку с печеньем.

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

Answer 6

Сохраните cookie, который является неясным идентификатором, в вашей локальной базе данных сервера. Выполните поиск БД на стороне сервера на основе идентификатора, указанного в файле cookie. Обязательно сделайте ID достаточно сложным, чтобы его было трудно угадать. Сопоставьте идентификатор с IP-адресом пользователя. Если их IP-адрес изменится, заставьте их снова войти в систему и создать новый идентификатор.

При втором чтении звучит так, будто вы хотите высокий уровень безопасности со связанными руками. Пользователь должен иметь возможность оставаться в системе и таким образом увеличивать свой риск. Вы можете реализовать всю безопасность в мире с точки зрения приложения и сервера, но если пользователь забудет свой ноутбук на столе в Tim Horton's (Canadian Starbucks), то ни один из них не принесет вам пользы.

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

Answer 7

Бернд - вы говорите, что подключение IP-адреса к cookie-файлу не вариант, я предполагаю, что это может быть связано с тем, что пользователь мог подключиться через DHCP и, таким образом, каждый раз мог входить под другим IP-адресом. Рассматривали ли вы возможность связать куки с именем хоста DNS? Вы можете зашифровать куки-файл с помощью закрытого ключа и сохранить его в ящике пользователя. Затем всякий раз, когда они приходят, проверьте cookie, отмените шифрование, а затем проверьте текущее имя DNS-узла пользователя по отношению к имени в cookie. Если он совпадает, вы разрешаете им вход. Если нет, вы не разрешаете автоматический вход.

FYI - в ASP.Net, чтобы получить имя хоста DNS для ящика пользователя, просто посмотрите на

Page.Request.UserHostName