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

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

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

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

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

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

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

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

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

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

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

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

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

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

Page.Request.UserHostName

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

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

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

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

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

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

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

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