Основные методы имитации web сеансов

Рохыт Белани, Перевод Алексей Антипов

Понимание угрозы

В 1960-ых требовалось все великолепие Франка Абагнала младшего (фильм "Поймай меня, если сможешь"), для того чтобы обманным путем создать огромный счет в банке. Все что необходимо сегодня - это прыщавый тинэйджер, имеющий доступ в Интернет!

Давайте рассмотрим следующую аналогию:

Первый сценарий:

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

Второй сценарий:

Злой Федя (злонамеренный пользователь) идет в тот же самый банк и входит в него через главный вход (80 порт), также как любой другой клиент. Даже притом, что его намерения мерзкие, он не врывается через другие входы (другие порты). Таким образом, охранникам (межсетевая защита) он кажется безвредным. Он точно также обслуживается банковским служащим (web приложением). Однако он обманывает служащего, заставив поверить (управление сеансом), что на самом деле он не плохой Федя, а хороший Вася и получает после этого доступ к Васиному вкладу.

Во втором сценарии описывается успешная имитационная атака, которая не обнаруживается охранниками (межсетевой защитой).

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

Управление сеансом

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

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

Клиентское управление сеансом

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

Пользователь (Доверчивый Вася) после успешной аутентификации на xyzbank.com получает следующий набор Cookie (показаны только названия и значения Cookie):

Admin=false; account=101

Пользователь (Злой Федя) после успешной аутентификации на xyzbank.com получает следующий набор Cookie (показаны только названия и значения Cookie):

Admin=false; account=120

Роль каждого Cookie вполне очевидна. Admin указывает приложению, нужно ли пользователю предоставить права администратора. Account определят разрешенную для доступа учетную запись пользователя.

Если бы Федор захотел сымитировать Васю, то он, скорее всего, выполнил бы перебор его значения account "в лоб". Для этого ему необходимо было бы перебрать все возможные значения Cookie (в данном случае 1000 вероятных значений от 000 до 999). Федя получил бы успех на 102-й попытке, когда Cookie, которое он представил приложению, имело следующий вид:

Admin=false; account=101

Все сказанное выше это пример атаки с горизонтальным повышением привилегий (т.е злоумышленник имитирует пользователя на том же уровне привилегий).

Федор мог также выполнить попытку атаки с вертикальным повышением привилегий, изменив Cookie значение admin на true". С помощью этого можно "обмануть" приложение, заставив его поверить, что Федя является администратором и предоставить ему права администратора к банковскому приложению. В таком случае возможности злоумышленника были бы безграничны!

Серверное управление сеансом

Главное отличие такой формы управления сеансом является то, что большая часть информации сохраняется в серверной базе данных, а маркер сеанса, проходимый между клиентом и приложением как индекс в этой базе данных. Данный тип маркера сеанса часто называют идентификатором сеанса. Рассмотрим следующий пример:

Пользователь (Доверчивый Вася) после успешной аутентификации на xyzbank.com получает следующий идентификатор сеанса:

Sessionid=1234

Пользователь (Злой Федя) после успешной аутентификации на xyzbank.com получает следующий идентификатор сеанса:

Sessionid=1235

Такие идентификаторы можно считать номерами записей в серверной базе данных имеющей следующую структуру:

Если намерение Федора состоит в имитации Василия, то он должен изменить свой идентификатор сеанса с 1235 на 1234. Также он может сымитировать пользователя с правами администратора (в данном случае Иван), т.е. определив его идентификатор сеанса (1232).

Таким образом, простое сохранение данных на серверной базе данных не предохраняет приложение от атак киберимитации.

Меры противодействия

Какие действия могут успешно противостоять эти атакам?

Основные правила защиты приложений от имитационных атак одинаковы для клиентского и серверного управления сеансом.

Увеличение длины значения Cookie или идентификатора сеанса.

Например, если бы значение account состояло не из 3, а из 32 символов, то для правильного определения значения, Федор потратил бы гораздо больше времени (10^32-1 значений против 10^3-1). Тоже применимо и к идентификатору сеанса.

Повышение случайности выбора значения маркера сеанса

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

Защита целостности маркеров сеанса

Добавление кода подлинности сообщения (типа MD5 контрольной суммы первоначального значения, выпущенного сервером) и проверке этого кода при каждом запросе, обеспечит проверку того, что данное значение не изменялось. Таким образом, даже если злоумышленник попытается изменить значение Cookie или идентификатора сеанса, то эти значения не пройдут проверку подлинности данных на сервере и будут отклонены.

"Запутывание" cookies

"Запутывание" полного набора Cookie помогает скрыть состав cookie пользователя, что затрудняет манипулирование злоумышленником значениями его cookie. Такая методика "запутывания" значений больше подходит для cookie, поскольку они содержат идентификационные данные в отличие от идентификаторов сеанса.

Защита конфиденциальности маркеров сеанса

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

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

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

Заключение

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

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