Перейти к содержимому

Поиск по платформе

CSRF: Обход проверки Referer-заголовка

Приложение использует проверку заголовка Referer вместо CSRF-токена. Обойди проверку и смени email администратора.

Автор: Hack & Fix
Освоишь: double-submit tokenSameSite=StrictOrigin/Referer check
Средне+60 XP ~30 мин golang
CWE-352 · A01:2021 Pro
Обложка: CSRF: Обход проверки Referer-заголовка Обложка: CSRF: Обход проверки Referer-заголовка
Задача
# CSRF: обход защиты через заголовок Referer ## Сценарий Онлайн-магазин **PineMarket** вырос из семейного проекта и живёт на самописном коде. Разработчик Денис, экономя время, «защитил» смену email от CSRF без токенов: обработчик ищет имя домена приложения в заголовке `Referer` и доверяет запросу, если подстрока найдена. Владелица магазина Мария после недавней истории у конкурентов заказала пентест. Администратор магазина по-прежнему открывает все ссылки, присланные через форму жалоб, оставаясь залогиненным в системе. ## Цель 1. Найдите эндпоинт смены email и разберите его проверку источника: где именно в `Referer` сервер ищет имя домена приложения. 2. Подготовьте HTML-страницу с формой, которая отправляется при открытии и подменяет email жертвы на адрес, доступный вам. 3. Разместите страницу так, чтобы её URL удовлетворял проверке, и доставьте ссылку боту-администратору через форму жалоб. 4. Дождитесь смены email администратора: уведомление придёт на новый адрес — в вашем почтовом клиенте приложения появится письмо с флагом. ## Теория Проверка `Referer` — исторически первая попытка защиты от CSRF: браузер прикрепляет этот заголовок к запросам, инициированным с другой страницы, поэтому логика «Referer без нашего домена — чужой запрос» выглядит правдоподобно. Подход рушится, когда проверка сводится к поиску подстроки: имя домена ищется **в любом месте** заголовка — в имени хоста, в пути, в параметрах URL. Атакующий размещает страницу по адресу, в путь которого встроено имя домена жертвы, и проверка пропускает запрос. Дополнительные слабости: часть браузеров и политик конфиденциальности вообще не отправляет `Referer`, а строгое сравнение хоста легко написать с ошибкой. Корректная защита не строится на заголовках, которые контролирует или может вычистить браузер: синхронизированный CSRF-токен или Double-Submit Cookie остаются стандартом. **Уязвимый паттерн:** ```go // Защита «по Referer»: подстрока ищется где угодно в заголовке referer := r.Header.Get("Referer") if !strings.Contains(referer, "secureshop.local") { http.Error(w, "Invalid request origin", 403) return } ``` Механика атаки — обычная CSRF: страница атакующего с авто-отправляемой формой и залогиненная жертва. Отличие одно: URL страницы подбирается так, чтобы поиск подстроки её пропустил. ## Точка входа атаки | Параметр | Значение | |----------|----------| | Ваш аккаунт | `demo` / `demo` | | Уязвимый эндпоинт | `POST /profile/change-email`, поле `email` | | Доставка боту | `POST /report`, поле `url` | | Хостинг payload | Exploit Server (панель лабы; адрес дополняется путём) | | Где появится флаг | `GET /email` — письмо о смене email администратора |

Похожие лабораторные (4)

другие лабы по этой уязвимости
Обложка лабы: CSRF: Атака через JSON API без кастомных заголовков Обложка лабы: CSRF: Атака через JSON API без кастомных заголовков
CSRF

CSRF: Атака через JSON API без кастомных заголовков

JSON API эндпоинт не требует кастомных заголовков. Используй CSRF для смены пароля admin через API.

+60 XP
Go Pro
Exploit Fix
Обложка лабы: CSRF: SameSite=Lax Bypass через GET-запрос Обложка лабы: CSRF: SameSite=Lax Bypass через GET-запрос
CSRF

CSRF: SameSite=Lax Bypass через GET-запрос

Мутирующий эндпоинт смены email реализован через GET. SameSite=Lax не защищает от top-level навигации. Измени email администратора через CSRF.

+60 XP
Go Pro
Exploit Fix