🔒SOP, CORS, CSP — Политики на защите вашего браузера

В современном мире информационной безопасности браузерная защита базируется на трёх ключевых политиках: SOP, CORS и CSP. Они не взаимозаменяемы, у каждой своя роль, и вместе они закрывают разные векторы атак. Часто уязвимости возникают из-за неправильной настройки этих политик.

1. SOP — Same-Origin Policy. По умолчанию браузер запрещает одному сайту читать данные с другого, но не блокирует отправку запросов.
👉 Пример: скрипт с evil.com не может прочитать вашу почту на mail.ru.

Но если сайт ослабляет SOP через document.domain или загружает сторонние скрипты без проверки, это становится уязвимостью.

То есть, даже если страница с https://app.example не может прочитать https://api.example/data, она всё ещё может отправлять формы или fetch-запросы на этот эндпоинт.
Это может позволить злоумышленнику:

– Проводить CSRF-атаки: <form action="https://api.example/transfer" method="POST">;
– Эксплуатировать Blind SSRF через анализ времени отклика;
– Вызывать API с целевого ресурса через iframe или fetch-запрос без чтения ответа.

2. CORS — управляемое ослабление SOP через заголовки Access-Control-Allow-*, в которым один сайт разрешает другому читать свои данные.
👉 Пример: api.site.com добавляет заголовок Access-Control-Allow-Origin: https://myapp.com — и теперь только myapp.com может получать данные.

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

Пример опасной конфигурации:

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

Таким образом браузер начинает отдавать данные сторонним скриптам. Если эндпоинт использует cookie-based аутентификацию, злоумышленник с другого сайта может читать ответы через fetch-запросы и получить чувствительные данные.


3. CSP — Content-Security-Policy ограничивает источники контента и выполнения скриптов, запрещая браузеру выполнять посторонний код (например, при XSS-атаке).
👉 Пример: даже если злоумышленник вставит <script src="evil.com/hack.js">, браузер откажется его загружать. если домен не в white list.

Политика CSP не блокирует доступ к данным, но уменьшает риск эксплуатации клиентских уязвимостей и эксфильтрации данных через fetch-запросы или веб-сокеты.
Однако, если в CSP прописано unsafe-inline или * (всё разрешено) — защита становится бесполезной.

Пример слабой политики:

Content-Security-Policy: default-src *; script-src 'unsafe-inline' https://cdn.example.com

Скрипты с внешних доменов могут выполняться, inline-скрипты остаются уязвимыми, а данные могут уходить на произвольные эндпоинты.

Metascan умеет выявлять мисконфигурации в политиках, а наши инженеры Red Team регулярно демонстрируют клиентам, почему reflected origin в конфигурации CORS — это действительно риск для безопасности.

#Metascan #pentest #redteam #Metascan_news