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

В области безопасности компьютерных сетей атаки с фиксацией сеанса пытаются использовать уязвимость системы, которая позволяет одному человеку фиксировать (находить или устанавливать) идентификатор сеанса другого человека . Большинство атак с фиксацией сеанса осуществляются через Интернет и большинство из них полагаются на идентификаторы сеанса, принимаемые из URL-адресов ( строка запроса ) или данных POST.

Сценарии атак

У Алисы есть счет в банке http://unsafe.example.com/

Мэллори намеревается украсть деньги Алисы из ее банка.

Алиса имеет разумный уровень доверия к Мэллори и будет посещать ссылки, которые Мэллори ей отправляет.

Простой сценарий атаки

Прямой сценарий:

Мэллори определил, что http://unsafe.example.com/ принимает любой идентификатор сеанса, принимает идентификаторы сеанса из строк запроса и не имеет проверки безопасности. http://unsafe.example.com/ таким образом, не является безопасным.
Мэллори отправляет Алисе электронное письмо: «Эй, посмотри, в нашем банке есть классная новая функция сводки счетов. http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID". Мэллори пытается привязать SID к I_WILL_KNOW_THE_SID.
Алиса интересуется и посещает http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. Появляется обычный экран входа в систему, и Алиса входит в систему.
Мэллори посещает http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID и теперь имеет неограниченный доступ к учетной записи Алисы.

Атака с использованием SID, сгенерированного сервером

Заблуждение состоит в том, что если сервер принимает только идентификаторы сеансов, сгенерированные сервером, он застрахован от фиксации. Это неверно .

Сценарий:

Мэллори посещает http://vulnerable.example.com/ и проверяет, какой SID возвращается. Например, сервер может ответить: Set-Cookie: SID=0D6441FEA4496C2.
Теперь Мэллори может отправить Алисе электронное письмо: «Познакомьтесь с этой новой интересной функцией в нашем банке. http://vulnerable.example.com/?SID=0D6441FEA4496C2."
Алиса входит в систему с фиксированным идентификатором сеанса. SID=0D6441FEA4496C2.
Мэллори посещает http://vulnerable.example.com/?SID=0D6441FEA4496C2 и теперь имеет неограниченный доступ к учетной записи Алисы.

Атаки с использованием межподдоменных файлов cookie

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

Сценарий:

Веб-сайт www.example.com передает поддомены ненадежным третьим лицам
Одна из таких партий, Мэллори, которая сейчас контролирует evil.example.com, заманивает Алису на свой сайт
Посещение evil.example.com устанавливает сеансовый файл cookie с доменом .example.com в браузере Алисы
Когда Алиса приходит в гости www.example.com этот файл cookie будет отправлен вместе с запросом, и у Алисы будет сеанс, указанный в файле cookie Мэллори.
Если Алиса теперь войдет в систему, Мэллори сможет использовать ее учетную запись.

Когда атака будет завершена, Мэллори сможет получить доступ к www.example.com Алисы.

Не обязательно, чтобы пользователь входил в систему для использования атак с фиксацией сеанса. ^[1] и, хотя эти атаки без аутентификации не ограничиваются атаками с использованием файлов cookie между субдоменами, последствия атак на субдомены актуальны для этих сценариев без аутентификации. Например, Мэллори может предоставить URL-адрес своего вредоносного сайта, фиксируя сеанс в сценарии без аутентификации, и использовать эти методы для эксплуатации своей цели. Сюда входят сценарии, использующие как сценарии без аутентификации (например, формы или регистрация), так и возможность передать пользователю установленный сеанс для полного обхода входа в систему.

Предположим, например, что Мэллори может создать пользователя A1ice на сайте www.example.com и войти в систему под этим пользователем, чтобы получить текущий действительный идентификатор сеанса. Затем Мэллори ловит Алису URL-адресом от evil.example.com , который фиксирует этот сеансовый файл cookie в браузере Алисы (как описано выше) и перенаправляет на www.example.com для завершения конкретной транзакции (или, по сути, для более широкого использования). Таким образом, Мэллори может скрыть сеанс от своего первоначального входа в систему, очищая данные и выполняя операции как «A1ice» на «www.example.com». Если Алису удалось обмануть и она сохранила свою кредитную карту в учетной записи, Мэллори могла бы совершать покупки с использованием этой карты.

Контрмеры

Не принимать идентификаторы сеансов из переменных GET/POST.

Идентификаторы сеанса в URL (строка запроса, переменные GET) или переменные POST не рекомендуются, поскольку они упрощают эту атаку — легко создавать ссылки или формы, которые устанавливают переменные GET/POST.

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

Примечание. Файлы cookie распределяются между вкладками и всплывающими окнами браузера. Если ваша система требует использования одного и того же домена (www.example.com/?code=site1 и www.example.com/?code=site2 ), файлы cookie могут конфликтовать друг с другом между вкладками.

Чтобы преодолеть это ограничение, может потребоваться отправить идентификатор сеанса по URL-адресу. Если возможно, используйте site1.example.com или site2.example.com, чтобы в файлах cookie не было конфликтов доменов. Это может повлечь за собой расходы на дополнительные сертификаты SSL.

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

Лучшее решение: подтверждение личности

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

Подобный метод можно использовать и для решения проблемы фишинга . Если пользователь защищает свою учетную запись двумя паролями, то эту проблему можно во многом решить.

Этот метод также полезен против атак с подделкой межсайтовых запросов .

Решение. Сохраняйте идентификаторы сеансов в файлах cookie HTTP.

Идентификатор сеанса в большинстве современных систем по умолчанию хранится в файле cookie HTTP , который имеет умеренный уровень безопасности, пока система сеанса игнорирует значения GET/POST. ^{[ нужна ссылка ]} Однако это решение уязвимо для подделки межсайтовых запросов и не соответствует требованию REST о безгражданстве .

Решение: используйте идентификатор сеанса SSL/TLS.

При включении безопасности HTTPS некоторые системы позволяют приложениям получать идентификатор сеанса SSL/TLS . Использование идентификатора сеанса SSL/TLS очень безопасно, но многие языки веб-разработки не предоставляют для этого надежных встроенных функций.

Регенерировать SID при каждом запросе

Противодействием фиксации сеанса является создание нового идентификатора сеанса (SID) при каждом запросе. Если это будет сделано, то даже несмотря на то, что злоумышленник может обманом заставить пользователя принять известный SID, SID будет недействительным, когда злоумышленник попытается повторно использовать SID. Реализация такой системы проста, о чем свидетельствует следующее:

Получить идентификатор предыдущего сеанса OLD_SID из HTTP-запроса.
Если OLD_SID имеет значение NULL, пусто или отсутствует сеанс с SID= OLD_SID существует, создайте новый сеанс.
Создать новый идентификатор сеанса NEW_SID с безопасным генератором случайных чисел.
Пусть сессия идентифицируется SID= NEW_SID (и уже не по SID= OLD_SID)
Передать новый SID клиенту.

Пример:

Если Мэллори успешно обманом заставит Алису посетить http://victim.example.com/?SID=I_KNOW_THE_SID, этот HTTP-запрос отправляется на victim.example.com:

GET /?SID=I_KNOW_THE_SID HTTP/1.1
Host: victim.example.com

victim.example.com принимает SID=I_KNOW_THE_SID, что обычно было бы плохо. Однако, victim.example.com является безопасным, поскольку выполняет регенерацию сеанса. victim.example.com получает следующий ответ:

HTTP/1.1 200 OK
Set-Cookie: SID=3134998145AB331F

Алиса теперь будет использовать SID=3134998145AB331F это неизвестно Мэллори, и SID=I_KNOW_THE_SID является недействительным. Таким образом, Мэллори безуспешно пытается зафиксировать сеанс.

К сожалению, регенерация сеанса не всегда возможна. Известно, что проблемы возникают при использовании стороннего программного обеспечения, такого как ActiveX или Java-апплеты, а также при взаимодействии плагинов браузера с сервером. Стороннее программное обеспечение может привести к выходу из системы, или сеанс может быть разделен на два отдельных сеанса.

Если реализация сеансов включает передачу SID через переменные GET или POST, это также может сделать кнопку «назад» в большинстве браузеров непригодной для использования, поскольку тогда пользователь будет использовать более старый, недействительный идентификатор сеанса из предыдущего запроса.

Принимать только SID, сгенерированные сервером

Один из способов повышения безопасности — не принимать идентификаторы сеансов, которые не были сгенерированы сервером. Однако, как отмечалось выше, это не предотвращает все атаки фиксации сеанса.

if (!isset($_SESSION['SERVER_GENERATED_SID'])) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['SERVER_GENERATED_SID'] = true;

Функция выхода из системы

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

if (logout) {
    session_destroy(); // Destroy all data in session
}

Тайм-аут старых SID

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

Сохраните переменную сеанса, содержащую отметку времени последнего доступа, совершенного с этим SID. Когда этот SID будет использоваться снова, сравните текущую временную метку с той, которая хранится в сеансе. Если разница превышает заранее определенное число, скажем, 5 минут, сессию следует уничтожить. В противном случае обновите переменную сеанса, указав текущую временную метку.

Уничтожить сеанс, если реферер вызывает подозрения

При посещении страницы большинство веб-браузеров устанавливают заголовок Referrer — страницу, содержащую ссылку, по которой вы перешли, чтобы попасть на эту страницу.

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

Например, http://vulnerable.example.com/ можно использовать следующую проверку безопасности:

if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable.example.com/') !== 0) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier

Убедитесь, что дополнительная информация единообразна на протяжении всего сеанса.

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

Поскольку все больше и больше сетей начинают соответствовать RFC 3704 и другим методам защиты от спуфинга , IP-адрес становится более надежным идентификатором «того же источника». Таким образом, безопасность веб-сайта можно повысить, проверив, что исходный IP-адрес единообразен на протяжении всего сеанса.

Это можно сделать следующим образом:

if ($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

Однако есть некоторые моменты, которые следует учитывать, прежде чем использовать этот подход.

Несколько пользователей могут использовать один IP-адрес. Нередко все здание использует один IP-адрес с использованием NAT .
Один пользователь может иметь противоречивый IP-адрес. Это справедливо для пользователей, использующих прокси (например, клиентов AOL ). Это также справедливо для некоторых пользователей мобильной связи/роуминга, а также пользователей, использующих Интернет-соединения с балансировкой нагрузки. Пользователи с включенными расширениями конфиденциальности IPv6 также могут в любое время изменить свои адреса конфиденциальности IPv6.
Он не будет надежно работать с клиентами с двойным стеком, поскольку запросы будут перемещаться между IPv4 и IPv6.
Он не будет надежно работать с мобильными пользователями, поскольку мобильные пользователи также перемещаются между адресами.

Для некоторых сайтов дополнительная безопасность перевешивает отсутствие удобства, а для других – нет.

Пользовательский агент

Браузеры идентифицируют себя по HTTP-заголовкам «User-Agent». Этот заголовок обычно не меняется во время использования; было бы крайне подозрительно, если бы это произошло. Веб-приложение может использовать обнаружение User-Agent, пытаясь предотвратить кражу сеансов злонамеренными пользователями. Однако обойти это тривиально, поскольку злоумышленник может легко перехватить пользовательский агент жертвы на своем собственном сайте, а затем подделать его во время атаки. Предлагаемая система безопасности опирается на безопасность через неизвестность .

if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];

Однако есть некоторые моменты, которые следует учитывать, прежде чем использовать этот подход.

Несколько пользователей могут иметь один и тот же User Agent браузера в Интернет-кафе .
У нескольких пользователей может быть один и тот же браузер по умолчанию (например: Internet Explorer 6 в Windows XP SP3 или мини-браузер в мобильном телефоне).

Но в некоторых случаях пользовательский агент может измениться юридически. Следующие примеры относятся к тем же пользователям.

Смартфон, экран которого поменялся с момента последнего запроса
- Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
- Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2
Режим совместимости с Internet Explorer:
- Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
- Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Пользователь получает доступ к веб-сайту через прокси-сервер, распределенный по нескольким серверам, не все из которых обновлены до последней версии программного обеспечения прокси.
- Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
- Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

Глубокоэшелонированная защита

Глубокоэшелонированная защита предполагает сочетание нескольких контрмер. Идея проста: если одно препятствие преодолеть тривиально, то несколько препятствий преодолеть будет очень сложно.

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

Включите HTTPS (для защиты от других проблем)
Правильная конфигурация (не принимать внешние SID, устанавливать тайм-аут и т. д.)
Выполнение сеансовой регенерации, поддержка выхода из системы и т. д.

HTTP-рефереры не передаются с помощью SSL/TLS (HTTPS).

Следующий PHP-скрипт демонстрирует несколько таких контрмер, объединенных в принцип глубокоэшелонированной защиты:

if (isset($_GET['LOGOUT']) ||
    $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] ||
    $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) {
    session_destroy();
}

session_regenerate_id(); // Generate a new session identifier

$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

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

См. также

Ссылки

^ Статья о неаутентифицированных атаках фиксации сеанса.

Внешние ссылки

Уголок безопасности: фиксация сеанса
Уязвимость фиксации сеанса в веб-приложениях (PDF)
Пример видео фиксации сеанса
Классификация угроз Консорциума по безопасности веб-приложений

[1] Статья о неаутентифицированных атаках фиксации сеанса.

[1]