Cross-Site Request Forgery (CSRF)
Что такое CSRF?
Cross-Site Request Forgery (CSRF) — это уязвимость веб-безопасности, позволяющая атакующему побудить пользователей выполнить действия, которые они не собирались выполнять. Она позволяет частично обойти политику единого источника (same origin policy), предназначенную для предотвращения вмешательства разных веб-сайтов друг в друга.
Лабораторные работы Если вы уже знакомы с базовыми концепциями уязвимостей CSRF и просто хотите попрактиковаться в их эксплуатации на реалистичных, преднамеренно уязвимых целях, вы можете получить доступ ко всем лабораториям по ссылке ниже.
Каковы последствия атаки CSRF?
В успешной атаке CSRF атакующий заставляет пользователя непреднамеренно выполнить действие. Например, это может быть изменение адреса электронной почты в аккаунте, смена пароля или перевод средств. В зависимости от характера действия атакующий может получить полный контроль над учётной записью пользователя. Если скомпрометированный пользователь имеет привилегированную роль в приложении, атакующий может получить полный контроль над всеми данными и функциональностью приложения.
Как работает CSRF?
Чтобы атака CSRF была возможна, должны выполняться три ключевых условия:
Значимое действие. В приложении есть действие, совершение которого выгодно инициировать атакующему. Это может быть привилегированное действие (например, изменение прав других пользователей) или любое действие с пользовательскими данными (например, изменение собственного пароля пользователя).
Обработка сессий на основе cookie. Выполнение действия включает отправку одного или нескольких HTTP‑запросов, и приложение полагается исключительно на сессионные cookie для идентификации пользователя, сделавшего запросы. Нет других механизмов отслеживания сессий или проверки пользовательских запросов.
Отсутствие непредсказуемых параметров запроса. Запросы, выполняющие действие, не содержат параметров со значениями, которые атакующий не может определить или угадать. Например, функция смены пароля не уязвима, если атакующему нужно знать значение текущего пароля.
Например, допустим, в приложении есть функция, позволяющая пользователю изменить адрес электронной почты в своём аккаунте. При выполнении этого действия пользователь отправляет запрос HTTP, подобный следующему:
Это соответствует условиям, необходимым для CSRF:
Действие смены адреса электронной почты в учётной записи пользователя представляет интерес для атакующего. После этого действия атакующий обычно может инициировать сброс пароля и получить полный контроль над учётной записью пользователя.
Приложение использует сессионный cookie для идентификации пользователя, отправившего запрос. Нет других токенов или механизмов отслеживания пользовательских сессий.
Атакующий может легко определить значения параметров запроса, необходимых для выполнения действия.
При выполнении этих условий атакующий может создать веб‑страницу, содержащую следующий HTML:
Если жертва посетит веб-страницу атакующий, произойдёт следующее:
Страница атакующий инициирует запрос HTTP к уязвимому сайту.
Если пользователь вошёл на уязвимый сайт, его браузер автоматически добавит в запрос его сессионный cookie (при условии, что не используются SameSite cookie)
Уязвимый сайт обработает запрос обычным образом, посчитает его сделанным жертвой и изменит её адрес электронной почты.
Как сконструировать атаку CSRF
Ручное создание HTML, необходимого для CSRF-эксплойта, может быть утомительным, особенно когда требуемый запрос содержит много параметров или в нём есть другие особенности. Самый простой способ сконструировать CSRF-эксплойт — использовать CSRF PoC generator, встроенный в Burp Suite Professional:
Выберите любой запрос в Burp Suite Professional, который вы хотите протестировать или проэксплуатировать.
В контекстном меню (правый клик) выберите Engagement tools / Generate CSRF PoC.
Burp Suite сгенерирует HTML, который спровоцирует выбранный запрос (без cookie, они будут добавлены автоматически браузером жертвы).
В генераторе CSRF PoC вы можете настроить различные параметры, чтобы точно подогнать атаку. В некоторых необычных ситуациях это может понадобиться для обработки специфичных особенностей запросов.
Скопируйте сгенерированный HTML в веб-страницу, откройте её в браузере, вошедшем на уязвимый сайт, и проверьте, что нужный запрос успешно отправляется и выполняется желаемое действие.
Как доставить CSRF-эксплойт
Механизмы доставки атак CSRF по сути такие же, как для Reflected XSS. Обычно атакующий размещает вредоносный HTML на контролируемом им сайте, а затем побуждает жертв посетить этот сайт. Это можно сделать, отправив пользователю ссылку на сайт по электронной почте или в сообщении в соцсетях. Или, если атака размещена на популярном сайте (например, в пользовательском комментарии), атакующий может просто ждать, пока пользователи посетят сайт.
Обратите внимание, что некоторые простые CSRF-эксплойты используют метод GET и могут быть полностью самодостаточными в виде одного URL (унифицированный указатель ресурса) на уязвимом сайте. В этой ситуации атакующему может не понадобиться внешний сайт, и он может напрямую отправить жертвам вредоносный URL на уязвимом домене. В приведённом выше примере, если запрос на смену адреса электронной почты можно выполнить методом GET, то самодостаточная атака будет выглядеть так:
Распространённые механизмы защиты от CSRF
В наши дни успешный поиск и эксплуатация уязвимостей CSRF часто связаны с обходом мер противодействия, внедрённых целевым сайтом, браузером жертвы или обоими. Наиболее распространённые защиты, с которыми вы столкнётесь:
CSRF-токены — CSRF-токен — это уникальное, секретное и непредсказуемое значение, которое генерируется серверным приложением и передаётся клиенту. При попытке выполнить чувствительное действие, например отправку формы, клиент должен включить корректный CSRF-токен в запрос. Это делает усложняет проведение эксплуатации для атакующего.
SameSite cookies — SameSite — это механизм безопасности браузера, который определяет, когда cookie сайта включаются в запросы, исходящие с других сайтов. Поскольку запросы на выполнение чувствительных действий обычно требуют аутентифицированного сессионного cookie, соответствующие ограничения SameSite могут помешать атакующему инициировать такие действия Cross-Site. С 2021 года Chrome по умолчанию применяет ограничения SameSite со значением
Lax. Поскольку это предлагаемый стандарт, мы ожидаем, что другие основные браузеры в будущем примут такое же поведение.Проверка на основе Referer — Некоторые приложения используют заголовок HTTP Referer, чтобы попытаться защититься от CSRF-атак, обычно проверяя, что запрос пришёл с домена самого приложения. В целом это менее эффективно, чем проверка CSRF-токена.
Более детальное описание каждой из этих защит, а также возможных способов их обхода, приведено в следующих материалах. Они включают интерактивные лабораторные работы, позволяющие отработать полученные знания на реалистичных, намеренно уязвимых целях.
Подробности о том, как правильно реализовать эти меры на ваших собственных сайтах, чтобы предотвратить некоторые из этих проблем, смотрите:
Last updated