Сессии
PHP Manual

Безопасность сессий

Внешние ссылки: » Атака "Фиксация сессии"

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

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

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

Существует несколько способов утечки существующего идентификатора сессии третьим лицам. Такая утечка позволяет злоумышленнику получить доступ ко всем данным, ассоциированным с конкретным идентификатором сессии. Во-первых, передача идентификатора сессии в URL. При переходе на внешний сайт идентификатор сессии пользователя и адрес ресурса могут попасть в статистику переходов данного сайта. Во-вторых, при более активной атаке возможно прослушивание сетевого трафика злоумышленником. Если канал передачи данных не зашифрован, идентификаторы сессии будут переданы в виде простого текста. В таком случае решением является обязательное использование SSL пользователями при доступе к сайту. Для этих целей следует применять HSTS.

С версии PHP 5.5.2 доступна опция session.use_strict_mode. При ее включении и при условии, что модуль сохранения сессий ее поддерживает, неинициализированный сессионный ID отвергается и создается новый. Это защищает от атак, которые принуждают пользователя использовать заранее извесный ID. Ататкующий может размещать ссылки или отправлять письма, которые содержат сессионный ID. Например http://example.com/page.php?PHPSESSID=123456789 . Если опция session.use_trans_sid включена, то жертва откроет сессию с этим идентификатором. Опция session.use_strict_mode уменьшает этот риск.

Даже при уменьшении риска с помощью session.use_strict_mode атакующий все еще может заставить пользователя использовать уже инициализированную сессию, созданную атакующим. Атакующий создает ее до атаки и поддерживает ее существование.

Cookie с сессионным ID должна устанавливаться с указанием domain, path, httponly и secure. Их приоритетность определяется браузерами. Опираясь на эту приоритетность, атакующий может может установить сессионный ID, который будет использоваться бесконечно. Применение session.use_only_cookies не решает эту проблему. session.use_strict_mode уменьшает риск. session.use_strict_mode=On, не допускает использование неинициализированных сессионных ID. Сессионный модуль создает новый ID каждый раз, как получает неизвестный ID. Это может привести к DoS атаке на жертву, но это лучше, чем компрометация аккаунта.

Использование session.use_strict_mode полезно, но не достаточно для аутентификационной сессии. Разработчик должен использовать также функцию session_regenerate_id() для аутентификации. Функцию session_regenerate_id() нужно вызывать до записи информации об аутетификации в $_SESSION. Только в этом случае функция session_regenerate_id() гарантирует, что только новая сессия содержит данные аутетификации, так как во время процесса аутотентификации могут возникнуть ошибки и данные могли бы остаться в старой сессии.

Вызов функции session_regenerate_id() может привести к персональной DoS атаке как и при use_strict_mode=On. Однако, DoS лучше, чем компрометация аккаунта. Пересоздание сессионного ID должно происходить хотя бы при аутентификации пользователя. Пересоздание ID уменьшает риск кражи сессии, поэтому рекомендуется периодически выполнять его. Разработчик не должен пологаться на устаревание сессионного ID. Атакующий может обращаться с сессионным ID жертвы периодически для предотвращения его истекания. Разработчик должен самостоятельно реализовать функционал для истекания старых сессий.

Обратите внимание, что session_regenerate_id() по умолчанию не удаляет старые сесии. Старая аутетифицированная сессия может оставаться доступной. Если разработчик хочет предотвратить дальнейшее использование старой сессии, то он должен уничтожать сессию, установив delete_old_session в TRUE. Однако, незамедлительное удаление старых сессий может привести к неожиданным побочным эффектам. Сессия может быть утеряна в случае нескольких конкурентных соединений к web-приложению и/или если сетевое соединение нестабильно. Вместо незамедлительного удаления вы можете установить маленькое значение времени истекания для $_SESSION. Если пользователь обращется с устаревшей сессией, отклоните его запрос.

session.use_only_cookies и правильное использование session_regenerate_id() могут привести к персональной DoS. Если такое происходит, то вы можете попросить пользователя удалить cookie и предупредить его о возможных проблемах с безопасностью. Атакующий может устанавливать вредные cookie через уязвимость в web-приложении (т.е. JavaScript инъекция), уязвимость в браузерном плагине и т.д.

Разработчикам не рекомендуется использовать долгоживущие сессионные ID для автоматического входа пользователей из-за повышения риска кражи сессий. Автоматический вход должен реализовываться самим разработчиком. Используйте одноразовые хэш ключи безопасности как ключи для автоматического входа через cookie. Используте хэши сложнее чем SHA-2, т.е. SHA-256 и сложнее с использованием случайных данных из /dev/urandom и т.д. Если пользователь не аутентифицирован, проверьте верный или нет у него одноразовый хэш. Если ключ верен, аутентифицируйте пользователя и задайте новый одноразовый хэш. Ключ для автоматического входа является долгоживущим ключем, этот ключ должен быть максимально защищенным. Используйте аттрибуты path/httponly/secure для защиты cookie. Разработчик должен реализовать функционал, который может выключать автоматический вход и удалять ненужные ключи из cookie.


Сессии
PHP Manual