Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Безопасная эксплуатация Apache, часть 6: атаки на механизм управления сессиями

Оригинал: Securing Apache, Part 6: Attacks on Session Management
Автор: Arpit Bajpai
Дата публикации: 1 Февраля 2011 г.
Перевод: А.Панин
Дата перевода: 22 Января 2013 г.

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

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

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

Хотя данная особенность протокола HTTP очень полезна в ряде случаев (например, при поиске информации в Интернет), она неприемлема для веб-приложений, в которых данные должны передаваться с одной страницы на другую. Например, на странице сайта покупок, где пользователи вводят номера кредитных карт для завершения перевода средств и оплаты покупок, код должен иметь доступ информации о том, какие товары пользователь выбрал на предыдущей странице для того, чтобы подсчитать итоговую сумму к оплате. Сайт покупок нуждается в механизме идентификации "сессии", виртуального "установленного соединения" между браузером и веб-сервером для передачи данных с одной страницы на другую.

Технически это реализуется так, как показано на Рисунке 1. Когда браузер соединяется с веб-сервером в первый раз, пользователь еще не аутентифицирован. Веб-сервер запрашивает аутентификационные данные и генерирует уникальный идентификатор сессии (session ID). Сервер может ассоциировать контекст с каждым идентификатором сессии, сохраняя любой тип данных в этом контексте. Генерируемый идентификатор сессии отправляется браузеру. При каждом последующем запросе к серверу, браузер также передает ему идентификатор сессии. После этого сервер может использовать контекст, связанный с переданным идентификатором сессии и "сохранять" данные при переходе от страницы к странице.

Обычное взаимодействие клиента и сервера с использованием идентификатора сессии
Рисунок 1: Обычное взаимодействие клиента и сервера с использованием идентификатора сессии

В данном случае важно понимать, что для установления принадлежности клиента сессии, каждой сессии ставится в соответствие идентификатор. Этот идентификатор передается между клиентом и сервером для HTTP-запросов, осуществляющихся в рамках данной сессии. Сессии в веб-приложениях обычно реализуются двумя способами:
  1. Сессии на строне клиента: При реализации сессий на стороне клиента, информация для авторизации и идентификации пользователя хранится на стороне клиента в куках. Клиент оправляет информацию из кук (включая идентификатор сессии) для информирования сервера о том, кто отправляет данные запросы.
  2. Сессии на стороне сервера: В отличие от предыдущего способа, реализация сессий на стороне сервера хранит информацию для авторизации и идентификации пользователя на сервере базы данных. Идентификатор сессии используется для извлечения пользовательской информации из базы этой данных, поэтому сервер имеет доступ к соответствующей информации при приеме запросов от клиента.

Механизмы хранения идентификаторов сессий

Для идентификации и поддержки действительных сессий используются три следующих механизма:
  1. Уникальный идентификатор добавляется в строку URL.
  2. Уникальный идентификатор хранится в скрытом поле формы.
  3. Уникальный идентификатор хранится в куках.

Теперь обсудим каждый из этих механизмов вместе с их достоинствами и недостатками.

Уникальный идентификатор, добавленный в строку URL

Такие идентификаторы принимаются веб-приложением с использованием HTTP GET-запросов со стороны клиента при переходе по ссылке на странице. Например, ссылка может быть такой: http://www.bank.com/account.php?sessionid=IE60012219. Стоит отметить, что веб-сервисы приглашений обычно используют уникальные идентификаторы сессий, добавленные в строки URL.

Преимущества

  • Этот метод защищает от CSRF-атак, проводимых через сторонние сайты.
  • Этот метод также не зависит от настроек браузера. Передача параметров в строке URL является функцией, которая всегда поддерживается любыми браузерами. Это обстоятельство является одной из причин, по которой передача идентификаторов в составе URL является страховочным вариантом при использовании кук для их хранения.

Недостатки

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

Уникальный идентификатор, хранящийся в скрытых полях форм

Обычно идентификатор сессии, хранящийся в скрытом поле формы, передается с помощью запроса HTTP POST. Например: 
<FORM METHOD=POST ACTION="/account.php">
<INPUT TYPE="hidden" NAME="sessionid" VALUE="IE60012219">
<INPUT TYPE="hidden" NAME="allowed" VALUE="true">
<INPUT TYPE="submit" NAME="Read News Article">

Преимущества

  • В отличие от передачи идентификатора в составе параметров запроса GET, значения скрытых полей форм передаются в теле запроса и не появляются в журналах событий прокси-серверов и в параметрах "Referrer" заголовков. Более того, пользователи не могут случайно скопировать их для вставки в сообщение электронной почты.
  • Данный метод также защищает приложение от CSRF-атак с использованием сторонних сайтов и также не зависти от настроек браузера.

Недостатки

  • Так как идентификатор сессии находится в составе HTML-страницы, данный механизм уязвим к XSS-атакам, проводимым с целью похищения идентификатора сессии.
  • Наиболее серьезным функциональным недостатком является то, что встроенные объекты, такие, как изображения, объекты FRAME и объекты IFRAME не могут быть использованы совместно с POST-запросами. Ресурсы, описанные в HTML-документах с использованием тэгов (например) IMG, IFRAME, и.т.д., всегда принимаются браузером с помощью запросов HTTP GET. Единственной альтернативой является использование этих объектов без обработки информации о сессиях, что открывает доступ к ним без аутентификации, или же переход к использованию совместно с этими объектами других механизмов, таких, как включение идентификатора сессии в строку URL.
  • Таким образом, использование скрытых полей форм для передачи идентификатора сессии ограничивается теми областями приложения, где информация о состоянии сессии не требуется для получения дополнительных объектов страницы. В большинстве случаев это означает, что для данных ресурсов проверка состояния аутентификации невозможна.

Уникальный идентификатор, хранящийся в куках

В большинстве ситуаций лучшим способом отправки идентификаторов сессии вместе с каждым запросом страницы является использование кук. Содержимое кук при хранении в них идентификатора сессии выглядит аналогично следующему: 
www.bank.com FALSE / FALSE 1293840000 sessionID IE60012219
Поля в строке выше иллюстрируют семь параметров, хранящихся в куках. Предназначение данных полей:
  • domain: Домен веб-сайта, добавившего данные в куки, которому также позволено считывать данные из них (в нашем случае www.bank.com).
  • flag: логическое значение (TRUE/FALSE), указывающее на то, могут ли все узлы, использующие данный домен, получить доступ к данным (в нашем случае не могут, так как значение FALSE).
  • path: строка URL, при использовании которой возможен доступ к данным с указанного выше домена.
  • secure: логическое значение, указывающее на то, необходимо ли использование технологии SSL при соединении с доменом для доступа к данным.
  • expiration: время истечения срока хранения данных в формате UNIX.
  • name: имя переменной (в нашем случае sessionID).
  • value: значение переменной (в нашем случае IE0012219).
Веб-приложение записывает данные в куки, отправляя специальный заголовок HTTP, аналогичный приведенному ниже:

Достоинства

Браузер автоматически отправляет значения из кук веб-приложению при каждом запросе. Приложению не требуется включать идентификатор сессии в состав ссылок или форм, как в случае использования механизмов с идентификатором в составе URL или в скрытом поле формы.

Недостатки

  • Тот факт, что куки с идентификатором сессии автоматически отправляются вместе с каждым запросом приложению, делает данный механизм уязвимым к CSRF-атакам с использованием сторонних сайтов.
  • Данные из кук могут быть похищены в ходе XSS-атаки, так как они доступны для сценариев JavaScript.
  • Другим важным недостатком механизма хранения идентификатора сессии в куках является возможность отключения использования кук пользователями в их браузерах. Это может быть препятствием при аутентификации.

Существуют два метода атак на механизмы сессий: похищение сессий (session hijacing) и фиксация сессий (session fixation). Рассмотрим их по очереди.

Похищение сессий (session hijacking, sidejacking)

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

Похищение сессий может происходить на двух уровнях: уровне сети и уровне приложения. Похищение сессий на уровне сети осуществляется путем перехвата или вмешательства в поток пакетов, передаваемых между клиентом и сервером в рамках TCP- или UDP-сессий. Похищение сессий на уровне приложений осуществляется путем установления идентификаторов сессий для получения контроля над HTTP-сессией используемой веб-приложением.

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

Из прошлых статей мы узнали, что идентификаторы сессий могут быть похищены с использованием XSS-атак (часть 2), CSRF-атак (часть 3), XST- и XSHM-атак (часть 4), а также атак уровня запросов HTTP (часть 5). Мы рассмотрели множество сценариев атак, нацеленных на похищение пользовательских данных сессии и вход в систему под идентификатором пользователя. Однако, существует ряд других и более эффективных способов похищения клиентских сессий. Это следующие способы:

Предсказание аутентификационных данных и идентификаторов сессий

Это эффективный и простой способ угадать чей-либо идентификатор сессии. В зависимости от случайности и длины идентификатора сессии, этот процесс может занять такой короткий промежуток, как несколько секунд. Давайте рассмотрим сценарий атаки для лучшего понимания...

Предположим, что веб-приложение использует идентификаторы сессии с постоянно повышающимся значением или использует пропиетарные алгоритмы, имеющие нулевую энтропию - таким образом, значения идентификаторов полностью предсказуемы. Приложение выдает идентификатор сессии с каким-либо числом и просто прибавляет единицу к данному числу для каждой новой сессии. Однако взломщики пока не знакомы с принципом работы приложения, но они могут исследовать приложение и использовать в своих целях этот принцип. Для завершения исследования им необходимо пройти следующие шаги:
  1. Взломщик регистрирует учетную запись с использованием исследуемого веб-приложения и осуществляет вход с использованием своих идентификационных данных.
  2. Он или она сразу же после этого фиксирует свой идентификатор сессии, хранящийся одним из трех способов, описанных выше. Предположим, что значение этого идентификатора оказалось IE60012219.
  3. После этого взломщик завершает сессию и снова осуществляет вход с помощью идентификационных данных, проверяя новое значение идентификатора сессии: скажем, оно стало IE60012350.
  4. На основе этих данных взломщик может предугадать следующий идентификатор, который будет использован, скажем, IE60012329. Он или она может после этого сменить свой идентификатор сессии на IE60012329 в куках, после чего с большой вероятностью будет аутентифицирован как какой-либо другой клиент.

Подбор идентификаторов, генерируемых Apache

Некоторые веб-приложения используют встроенные в веб-сервер Apache алгоритмы для генерации идентификаторов сессий, добавляемых в куки. Хотя данные куки предназначены только для записи событий в журнал обращений к веб-серверу, веб-приложения также используют их для аутентификации. Было обнаружено, что идентификаторы сессий, сгенерированные при помощи алгоритма из модуля mod_usertrack.c, могут быть подобраны с использованием сценариев для автоматизации.

продолжение статьи