Отравление сеанса - Session poisoning

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

Основная уязвимость - это проблема управления состоянием: общее состояние, состояние гонки, неоднозначность использования или явные незащищенные изменения значений состояния.

Отравление сеанса было продемонстрировано в серверных средах, где разные, не вредоносные приложения (сценарии) используют одни и те же состояния сеанса, но где использование отличается, что вызывает неоднозначность и состояния гонки.

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

Происхождение

Отравление сеанса впервые обсуждалось как (потенциально новый) класс уязвимости в Полное раскрытие список рассылки.^[1] Алла Безрутчко поинтересовалась, была ли новая проблема в январе 2006 г. «Уязвимость к загрязнению данных сеанса в веб-приложениях». Однако это была старая уязвимость, ранее отмеченная другими: «это классическая проблема управления состоянием» - Иван Бойли;^[2] «Это не ново» - / кто-то.^[3]

Более ранние примеры этих уязвимостей можно найти в основных ресурсах / архивах безопасности, таких как Bugtraq, например

Июль 2001, Серьезная дыра в безопасности в Mambo Site Server версии 3.0.X, Исмаэль Пейнадо Паломо из reverseonline.com.^[4]
Сентябрь 2005 г., модификация PHP Session от unknown (от uw-team) и adam_i^[5]

Загрязнение сеанса также освещалось в некоторых статьях, таких как Безопасность сеансов PHP, Przemek Sobstel, 2007.^[6]

Примеры атак

Тривиальный сценарий атаки

Пример кода, уязвимого к этой проблеме:

Сессия ("Логин") = Запрос ("Логин") Сессия ("Имя пользователя") = Запрос ("имя пользователя")

Который подвержен тривиальным атакам, таким как

уязвимый.asp? login = YES & username = Mary

Эта проблема может существовать в программном обеспечении, где

Пользователь отправляет имя пользователя / пароль на logon.asp
Если пароль для Мэри проверяет, logon.asp пересылает в уязвимый.asp? login = YES & username = Mary

Проблема в том, что уязвимый.asp спроектирован исходя из предположения, что доступ к странице осуществляется только безопасным способом. Любой, кто понимает, как устроен сценарий, может создать HTTP-запрос, который произвольно устанавливает пользователя для входа.

Использование неоднозначного или двойного использования одной и той же переменной сеанса

Алла Безрутчко обсуждает сценарий, в котором $ _SESSION ['логин'] используется для двух разных целей.^[7]

В сценариях входа в систему переменная сеанса хранит «Этот пользователь вошел в систему».
В сценариях сброса пароля переменная сеанса хранит «этот пользователь хочет сбросить свой пароль».

Было продемонстрировано состояние гонки, в котором сценарии сброса могут использоваться для произвольного изменения вошедшего в систему пользователя.

Использование сценариев, разрешающих запись в произвольные переменные сеанса

Алла Безрутчко обсуждает наблюдаемые на форумах разработчиков примеры, которые позволяют записывать в произвольные переменные сеанса.^[8]

Первый пример

$ var = $ _GET["что нибудь"]; $ _SESSION["$ var"] = $ var2;

(где $ _GET ["что-то"], вероятно, находится из поля выбора или аналогичного).

Атака становится

уязвимый.php? something = SESSION_VAR_TO_POISON

Атаки отравления сеанса, включенные php.ini: register_globals = on

php.ini: register_globals = on известно, что в некоторых приложениях есть уязвимости в системе безопасности. PHP администраторам сервера рекомендуется отключить эту функцию.

Примечание. Реальные примеры заражения сеансов при включении register_globals = on были публично продемонстрированы еще в июльской статье 2001 г. Серьезная дыра в безопасности в Mambo Site Server версии 3.0.X.^[9]

Второй пример кем-то^[10]

если ($ condition1) {     $ var = 'ЧТО НИБУДЬ'; }; если ($ condition2) {     $ var = 'ДРУГОЙ'; }; $ _SESSION["$ var"] = $ var2;

который уязвим, если:

Злоумышленник может заставить оба условия быть ложными.
php.ini настроен неправильно (register_globals = on), что позволяет управлять значением по умолчанию $ var с помощью ввода GPC (GET, POST или COOKIE).

Атака становится

уязвимый.php? var = SESSION_VAR_TO_POISON

Использовать общий сервер PHP (например, общий веб-хостинг)

«unknown» на uw-team.org обсуждает сценарий, в котором злоумышленник и жертва используют один и тот же сервер PHP.^[11]

Атака довольно проста:

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

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

Смотрите также

Фиксация сеанса