Я искал способы защиты от перехвата сеанса, когда кто-то крадет файл cookie сеанса и использует его для получения доступа к системе.
Такие программы, как http://codebutler.com/firesheep, позволяют легко прослушивать сеансы в открытых беспроводных сетях, а другие способы получения сеансов включают атаки с использованием межсайтовых сценариев или просто физическое снятие их с компьютера жертвы.
Использование SSL для защиты всех сеансовых cookie-файлов / серверов имеет решающее значение для предотвращения перехвата Firesheep, а установка HTTPOnly для cookie-файлов помогает предотвратить возможность чтения сценариев cookie-файлами при XSS-атаках, но все же уязвима для AJAX- атаки на основе.
Другим уровнем является включение токена безопасности или одноразового номера в файл cookie сеанса, который обновляется при каждом запросе. Вы сохраняете токен в хранилище данных на стороне сервера и в файле cookie, и при каждом запросе вы сравниваете, что токен в файле cookie совпадает с маркером в хранилище данных.
Если токены не совпадают, это может указывать на то, что кто-то украл сеанс и пытается его использовать, чтобы вы могли либо проигнорировать запрос, либо аннулировать сеанс и потребовать от пользователя повторной аутентификации. Однако несоответствующие токены также могут быть результатом медленного / нестабильного соединения.
Например, может иметь место случай, когда сервер получает запрос от реального пользователя, обновляет токен сеанса в хранилище данных сервера и отвечает пользователю сессионным cookie, который содержит обновленный токен. Но пользователь не получает ответ из-за медленного / нестабильного соединения, поэтому у пользователя все еще есть старый токен сеанса, в то время как новый хранится на сервере. Когда пользователь повторяет запрос, токены не совпадают.
Один из способов смягчения этой проблемы состоит в том, чтобы сервер сохранил историю последних нескольких токенов и проверил ее, чтобы увидеть, совпадают ли они, но тогда возникает ситуация, сколько токенов нужно сохранить, и в зависимости от того, насколько ненадежным является Соединение или насколько пользователь доволен щелчком, сервер может циклически просматривать историю до того, как соединение восстановится, а сеанс пользователя будет обновлен браузером.
Альтернативой хранению истории токенов является отметка времени каждого сеанса и проверка, находятся ли отметки времени в некотором коротком заданном диапазоне, например, 30 секунд. Если временная метка cookie сеанса пользователя находится в пределах 30 секунд от сохраненной временной метки сеанса сервера, то сеанс считается подлинным.
Пример псевдокода
def authenticate_request():
if (stored_session.timestamp - session.timestamp > 30 seconds):
return False
return True
Это избавляет от необходимости хранить историю токена - метка времени становится токеном - но у злоумышленников есть 30-секундное окно возможности перехватить сеанс после его кражи. Хотя это и правда, альтернатива истории токенов не лучше, потому что она дает злоумышленникам потенциально более длительное окно возможностей.
Есть и другие подходы к проверке IP-адресов и изменений User-Agent. Агенты пользователей легко подделываются, и если злоумышленник может получить сеанс пользователя, он может легко определить агента пользователя с помощью того же кода XSS или с помощью других средств.
Если пользователь подключен к мобильному устройству, его IP-адрес может часто меняться, что приведет к множеству ложных срабатываний. Кроме того, злоумышленник может находиться за брандмауэром одной и той же компании, поэтому IP-адрес пользователя и злоумышленника совпадают с внешним веб-сервером.
Является ли использование метки времени правильным подходом или есть лучший способ? Правильный ли 30-секундный буфер? Какие крайние случаи я пропускаю?