¦ подключиться к серверу, используя текущий идентификатор сессии;

¦ вычислить или подобрать следующий идентификатор сессии;

¦ присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.

Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. Успешное прохождение аутентификации пользователем вовсе не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Грамотно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам.

В прошлом многие веб-серверы сохраняли важные ресурсы в скрытых директориях – таких как /admin или /Log. Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор «роли» пользователя в рамках веб-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie. К примеру, значение cookie: Session Id = 12345678; Role = User заменяется на SessionId = 12345678; Role = Admin.

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

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

Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа «межсайтовое выполнение сценариев» или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя.

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

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

Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию- заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе, собственно, и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS.

Следующим шагом атакующего является собственно подключение к сессии. Атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, 'гвоздем программы' является фиксация ID, которая реализуется посредством следующих действий.

¦ При наличии уязвимости типа 'межсайтовое выполнение сценариев' злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода: httр://example/<script> document.cookie='sessionid=12 34;%2 0domain=.example.dom'; </ script>.idc.

¦ Второй вариант предусматривает установку нужного значения cookie с помощью тега META. Кроме того, возможна установка cookie с использованием заголовка HTTP-ответа.

Атаки на клиентов

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

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

Некоторые веб-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма <frame src='http://foo. example/file.html'> может передаваться в следующем параметре URL:

httр://foo.example/page?frame_src=http://foo.example/file.html