Каков наилучший способ предотвратить угон сеанса?
Вы можете играть с любым из них: Угловой, Ember, Knockout, React, Node JS. То же самое, что вы, PHP-код, вы можете совершить с практически любыми технологиями Javascript - просто нет динамического языка. Другой способ сделать это - использовать онлайн-провайдеры, такие как Jot Forms или другие. Вы можете создать и стилизовать форму с помощью онлайн-формы, а затем просто добавить ее на свой сайт. Затем, когда пользователь отправит сообщение, он отправит его в форму. В результате у вас есть централизованная среда не только для вашего текущего сайта, но и для любых других людей в будущем. Вы можете создать веб-сервис и опубликовать значения там - тогда сделайте все, что вы хотите с ними: сохраните их в базе данных ... В других словах есть еще один сервер, который обрабатывает все эти вещи, поэтому вы можете просто вызвать его с размещенных сайтов Firebase. Надеюсь, что это поможет
PS: В настоящее время я создаю продукт, который является упрощенной версией онлайн-форм, которые будут использоваться на сайтах Firebase. На данный момент я планирую использовать несколько человек, поэтому, если вы хотите, чтобы вы могли написать мне по электронной почте, и я создам учетную запись, чтобы вы ее использовали. До тех пор, пока не будет никакого злоупотребления, такого как отправка кучу писем - все будет хорошо!
5 ответов
Шифрование значения сессии будет иметь нулевой эффект. Сеансовые куки уже являются произвольным значением, шифрование их просто сгенерирует другое произвольное значение, которое может быть сниффинговым.
Единственным действительным решением является HTTPS. Если Вы не хотите делать SSL на своем целом сайте (возможно, у Вас есть проблемы производительности), Вы смогли сходить с рук только SSL, защищающий чувствительные области. Чтобы сделать это, сначала удостоверьтесь, что Вашей страницей входа в систему является HTTPS. Когда пользователь входит в систему, установите защищенный cookie (значение, что браузер только передаст его по ссылке SSL) в дополнение к cookie очередной сессии. Затем когда пользователь посетит одну из Ваших "чувствительных" областей, перенаправьте их к HTTPS и проверьте на присутствие того защищенного cookie. У реального пользователя будет он, угонщик сессии не будет.
Править: Этот ответ был первоначально записан в 2008. Это - 2016 теперь, и нет никакой причины не иметь SSL через Ваш весь сайт. Больше никакого простого текста HTTP!
Попробуйте протокол Защищенного cookie, описанный в данной статье Liu, Kovacs, Huang и Gouda:
Как указано в документе:
Протокол защищенного cookie, который работает между клиентом и сервером, должен предоставить следующие четыре услуги: аутентификация, конфиденциальность, целостность и антивоспроизведение.
Что касается простоты развертывания:
С точки зрения эффективности наш протокол не включает поиска базы данных или шифрования с открытым ключом. С точки зрения deployability наш протокол может быть легко развернут на существующем веб-сервере, и он не требует никакого изменения в интернет-cookie specication.
Короче говоря: это безопасно, легко, работы для меня просто большой.
SSL только помогает со сниффингом нападений. Если у взломщика будет доступ к Вашей машине, то я предположу, что они могут скопировать Ваш защищенный cookie также.
По крайней мере удостоверьтесь, что старые cookie теряют свое значение через некоторое время. Даже успешному нападению угона будут мешать, когда cookie прекратит работать. Если у пользователя есть cookie от сессии, которая зарегистрировалась в больше чем месяц назад, заставьте их повторно войти в свой пароль. Удостоверьтесь, что каждый раз, когда пользователь нажимает на Ваш сайт, "выходят из системы" ссылка, что старая сессия UUID никогда не может использоваться снова.
Я не уверен, будет ли эта идея работать, но здесь идет: Добавьте порядковый номер в свои сеансовые куки, возможно, строка как это:
SessionUUID, последовательная цифра, текущая дата / время
Зашифруйте эту строку и используйте ее в качестве своих сеансовых куки. Регулярно изменяйте последовательную цифру - возможно, когда cookie составляет 5 старых минут, и затем переиздайте cookie. Вы могли даже переиздать его на каждом просмотре страницы, если бы Вы хотели. На стороне сервера ведите учет последней последовательной цифры, которую Вы выпустили для той сессии. Если кто-то когда-нибудь отправляет cookie с неправильным порядковым номером, это означает, что взломщик может использовать cookie, который они прервали ранее, так делайте недействительным сессию UUID и попросите, чтобы пользователь повторно вошел в их пароль и затем переиздал новый cookie.
Помните, что у Вашего пользователя может быть больше чем один компьютер, таким образом, у них может быть больше чем одна активная сессия. Не делайте чего-то, что вынуждает их войти в систему снова каждый раз, когда они переключаются между компьютерами.
Удостоверьтесь, чтобы Вы не использовали incremting целые числа для идентификаторов сессии. Намного лучше использовать GUID или некоторую другую длинную случайным образом сгенерированную символьную строку.
Для снижения риска, можно также связать инициирующий IP с сессией. Тем путем взломщик должен быть в той же частной сети, чтобы смочь использовать сессию.
Проверка заголовков ссылающегося домена может также быть опцией, но они более легко имитируются.