SameSite Cookie Bypass через iframes и редкие хаки, о которых молчат в руководствах

Настройка SameSite в cookie уже стала одним из главных инструментов защиты сайтов от атак, связанных с межсайтовыми запросами — например, CSRF . Но, как это часто бывает, правила браузеров можно обойти, особенно если подключить немного креатива, старые API и несколько неожиданных способов доставки запроса. Сегодня мы разберём, как злоумышленники используют iframes и неочевидные техники для обхода SameSite, и почему это всё ещё проблема даже в 2025 году.

Что такое SameSite и зачем он нужен

SameSite — это атрибут cookie, который определяет, можно ли отправлять cookie при кросс-доменных запросах. Идея проста: если ваш сайт ставит cookie с SameSite=Strict или SameSite=Lax, браузер не будет передавать их, если запрос приходит с другого домена. Это закрывает огромный пласт атак, особенно CSRF.

Возможные значения:

• Strict — cookie передаются только при навигации в пределах одного домена.
• Lax — cookie передаются при переходах по ссылкам или при загрузке страниц, но не при большинстве запросов с других сайтов.
• None (требует Secure) — cookie всегда передаются, включая кросс-доменные запросы.

На бумаге звучит надёжно. Но на практике, как показывает опыт, ограничения SameSite можно обойти, если знать, какие «дырки» оставляют старые механизмы веба.

Почему обход SameSite до сих пор возможен

Причин несколько:

1. Разные браузеры реализуют поддержку SameSite с нюансами — старые версии могут работать по старым правилам.
2. Некоторые API и элементы HTML работают «особым» образом, заставляя браузер отправлять cookie даже при междоменном запросе.
3. Разработчики часто полагаются только на SameSite, забывая про дополнительные меры защиты.

Классический пример: сайт защищён от CSRF с помощью SameSite=Lax, но злоумышленник находит способ встроить страницу жертвы в iframe с нужными параметрами и запускает запрос изнутри.

Как iframes помогают обойти SameSite

Iframe — это встроенное окно в браузере, которое загружает другой сайт. Оно создаёт полноценный контекст, где браузер часто ведёт себя так, будто пользователь работает с этим сайтом напрямую. И тут начинается магия.

Сценарий с GET-запросом

Если на защищённом сайте есть функциональность, которая что-то делает по GET-запросу (например, подтверждает действие или выполняет поиск), её можно открыть в iframe. В некоторых случаях браузер отправит cookie даже при SameSite=Lax, потому что это будет воспринято как «переход».

<iframe src="https://target-site.com/action?approve=true" style="display:none"></iframe>
 

Да, в новых версиях Chrome и Firefox это ограничили, но в реальных условиях обход всё ещё встречается, особенно в корпоративных сетях со старыми браузерами.

Взаимодействие через postMessage

Iframe можно использовать не только для загрузки страниц, но и для общения между окнами через postMessage . Злоумышленник может загрузить страницу жертвы в iframe, а потом через скрипт в родительском окне инициировать действия, которые обойдут ограничения SameSite.

Странные методы обхода, о которых редко говорят

Помимо iframe, есть и более экзотические техники:

• Протоколы вроде data: и blob: — можно обернуть вредоносный контент в нестандартный источник, чтобы браузер иначе трактовал происхождение.
• Встраивание через SVG — элемент <image> внутри SVG иногда передаёт cookie в обход ожиданий.
• Service Workers — позволяют перехватывать запросы и «подсовывать» их так, чтобы SameSite не сработал.
• Принудительная загрузка ресурсов (CSS, JS) с параметрами, на которые реагирует сервер.

Пример сложного обхода

Допустим, злоумышленник хочет обойти SameSite=Strict на сайте банка. У него есть:

• Домен, с которого можно встроить iframe.
• Известный URL на сайте банка, который по GET-запросу выполняет действие (например, подтверждает перевод).
• Уязвимость типа XSS на другом поддомене банка.

Как это может работать:

1. Iframe загружает поддомен с XSS.
2. XSS-скрипт в поддомене отправляет запрос на основной домен (банковский API).
3. Поскольку это «внутреннее» взаимодействие, браузер отправляет cookie, игнорируя SameSite для поддоменов.
4. Запрос выполняет действие от имени жертвы.

Как защититься

Если вы разработчик или администратор, полагаться только на SameSite — опасно. Вот несколько мер:

• Добавляйте CSRF-токены во все критичные запросы.
• Используйте Content Security Policy для ограничения источников, откуда можно грузить ресурсы и iframes.
• Проверяйте Origin и Referer на сервере.
• Отключайте возможность встраивания сайта через iframe с помощью заголовка X-Frame-Options: DENY или frame-ancestors 'none'.
• Обновляйте браузеры и тестируйте на старых версиях.

Вывод

SameSite — полезный инструмент, но не серебряная пуля. Iframes и редкие техники обхода показывают, что веб до сих пор хранит множество «исторических» особенностей, которые можно использовать в атаке. Без комплексной защиты (CSRF-токены, проверка заголовков, ограничения на встраивание) полагаться на одну настройку cookie — всё равно что ставить замок на дверь, но оставлять открытое окно.