Same-Origin Policy

Same-Origin Policy (политика одинакового источника, SOP) — это фундаментальный механизм безопасности веб-браузеров, ограничивающий возможность взаимодействия веб-страницы с ресурсами из другого источника (origin). Политика предотвращает чтение или изменение данных, полученных с другого домена, протокола или порта, без явного согласия сервера-источника. SOP является одним из ключевых элементов модели безопасности веб-приложений, защищающим пользователей от кражи конфиденциальной информации и атак типа межсайтового скриптинга (XSS) и межсайтовой подделки запросов (CSRF).

История

Концепция Same-Origin Policy была впервые реализована в браузере Netscape Navigator 2.0 в 1995 году. Разработчики компании Netscape Communications Corporation (основана Марком Андриссеном и Джимом Кларком) столкнулись с необходимостью ограничить возможность скриптов на одной странице получать доступ к данным другой страницы, открытой в том же браузере. До внедрения SOP любая веб-страница могла читать содержимое других вкладок или окон, что создавало серьёзные уязвимости.

В 1996 году спецификация SOP была включена в черновик стандарта Document Object Model (DOM) Level 0, разрабатываемого консорциумом World Wide Web Consortium (W3C). Впоследствии механизм был интегрирован в стандарты HTML5 и ECMAScript (JavaScript). Современные браузеры — Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge — поддерживают SOP в соответствии со спецификациями W3C и WHATWG (Web Hypertext Application Technology Working Group).

Определение источника

Источник (origin) в контексте SOP определяется тремя компонентами URL:

• Протокол (схема): например, http, https, ftp, file.
• Домен (хост): например, example.com, sub.example.com, localhost.
• Порт: например, :80, :443, :8080.

Два ресурса считаются имеющими одинаковый источник только в том случае, если все три компонента совпадают. Например:

• http://example.com/page1.html и http://example.com/page2.html — одинаковый источник (протокол http, домен example.com, порт 80 по умолчанию).
• http://example.com и https://example.com — разные источники (разные протоколы).
• http://example.com и http://sub.example.com — разные источники (разные домены).
• http://example.com:80 и http://example.com:8080 — разные источники (разные порты).

Принцип работы

При загрузке веб-страницы браузер создаёт для неё контекст выполнения, привязанный к определённому источнику. Любые скрипты, выполняемые в этом контексте, могут обращаться к ресурсам (данным, куки, localStorage, DOM) только в пределах своего источника. Попытка доступа к ресурсам другого источника блокируется браузером, если сервер-источник явно не разрешил такое взаимодействие через механизмы вроде CORS (Cross-Origin Resource Sharing).

Типы блокируемых операций

SOP ограничивает следующие виды межсайтового взаимодействия:

• Чтение содержимого DOM: скрипт на странице http://example.com не может прочитать содержимое элемента <iframe> с http://other.com.
• Доступ к куки и localStorage: куки, установленные для http://example.com, недоступны для страниц с http://other.com.
• Отправка запросов с чтением ответа: XMLHttpRequest или Fetch API, отправленные на другой источник, блокируются, если сервер не разрешил CORS.
• Манипуляции с окнами: скрипт не может изменить свойство location окна другого источника или прочитать его document.

Исключения и разрешённые операции

Некоторые виды межсайтового взаимодействия разрешены по умолчанию:

• Ссылки и перенаправления: пользователь может перейти по ссылке на другой источник.
• Загрузка ресурсов: <img>, <script>, <link>, <video>, <audio> могут загружать ресурсы с других источников, но браузер не позволяет скриптам читать их содержимое.
• Отправка форм: данные формы могут быть отправлены на другой источник, но ответ не может быть прочитан скриптами.
• Встраивание через <iframe>: страница может быть встроена в <iframe> другого источника, но скрипты родительской страницы не могут получить доступ к содержимому <iframe>.

Классификация и варианты

SOP для разных типов ресурсов

• DOM-доступ: наиболее строгая часть SOP, ограничивающая чтение и изменение DOM между разными источниками.
• Сетевые запросы: регулируется SOP в сочетании с CORS. Браузер блокирует запросы на чтение с другого источника, если сервер не возвращает соответствующие заголовки.
• Куки и хранилища: куки, localStorage и sessionStorage привязаны к источнику. SOP не позволяет страницам одного источника читать куки другого.

SOP для разных протоколов

• HTTP/HTTPS: SOP применяется одинаково, но браузеры могут иметь дополнительные ограничения для смешанного контента (mixed content), когда HTTPS-страница загружает HTTP-ресурсы.
• file://: для файлового протокола SOP реализована по-разному в разных браузерах. В некоторых браузерах (например, Firefox) файлы из разных каталогов считаются разными источниками.
• data: и blob: URL-адреса с этими протоколами обычно считаются уникальными источниками, не имеющими доступа к другим ресурсам.

Применение и значение

Защита от атак

SOP является первой линией обороны против многих веб-атак:

• Межсайтовый скриптинг (XSS): если злоумышленник внедряет скрипт на страницу, SOP не позволяет этому скрипту получить доступ к данным другого источника (например, к куки банка пользователя).
• Межсайтовая подделка запросов (CSRF): SOP блокирует чтение ответа от сервера-жертвы, что затрудняет кражу данных.
• Кража сессионных данных: SOP предотвращает чтение куки аутентификации с другого сайта.

Ограничения и необходимость CORS

SOP создаёт проблемы для разработчиков, которым необходимо легитимно взаимодействовать с разными источниками (например, API на другом домене). Для этого был разработан механизм CORS (Cross-Origin Resource Sharing), который позволяет серверу явно разрешить межсайтовые запросы через HTTP-заголовки:

• Access-Control-Allow-Origin: указывает, какие источники могут обращаться к ресурсу.
• Access-Control-Allow-Methods: разрешённые HTTP-методы.
• Access-Control-Allow-Headers: разрешённые заголовки.

CORS не отменяет SOP, а дополняет её, предоставляя контролируемый способ обхода ограничений.

Критика

Недостатки SOP

• Сложность для разработчиков: SOP требует от разработчиков понимания механизмов безопасности и настройки CORS, что увеличивает время разработки и вероятность ошибок.
• Неполная защита: SOP не защищает от всех типов атак. Например, CSRF-атаки могут быть выполнены без чтения ответа (например, через отправку формы), а XSS-атаки могут быть проведены в пределах одного источника.
• Проблемы с встраиванием: SOP ограничивает встраивание контента с других источников, что может мешать работе легитимных сервисов (например, виджетов социальных сетей).
• Различия в реализации: разные браузеры могут по-разному интерпретировать SOP, особенно для нестандартных протоколов (например, file:// или data:).

Альтернативы и улучшения

• CORS: основной механизм для контролируемого обхода SOP.
• PostMessage API: позволяет безопасно обмениваться сообщениями между окнами разных источников.
• Content Security Policy (CSP): дополнительный уровень защиты, ограничивающий источники, с которых можно загружать ресурсы.
• Subresource Integrity (SRI): проверка целостности загружаемых скриптов и стилей.

Интересные факты

• В 2010 году исследователь безопасности Джоэл Вайнбергер (Joel Weinberger) продемонстрировал атаку «Same-Origin Policy bypass» через использование уязвимости в обработке URL-адресов браузером Internet Explorer 6.
• В 2015 году в браузере Google Chrome была обнаружена уязвимость CVE-2015-1234, позволявшая обходить SOP через манипуляции с протоколом data:.
• Некоторые старые версии браузера Safari (до версии 7) имели неполную реализацию SOP для протокола file://, что позволяло локальным файлам читать данные из других каталогов.
• В 2020 году исследователи из Университета Калифорнии в Беркли предложили расширение SOP под названием «Same-Origin Policy 2.0», которое добавляет проверку на основе контекста выполнения, а не только источника.

Источники

• World Wide Web Consortium (W3C). «Same-Origin Policy». W3C Working Draft, 2010.
• Mozilla Developer Network (MDN). «Same-origin policy». MDN Web Docs, 2023.
• WHATWG. «HTML Living Standard: Origin». WHATWG, 2024.
• Adam Barth, Collin Jackson, John C. Mitchell. «Robust Defenses for Cross-Site Request Forgery». Proceedings of the 15th ACM Conference on Computer and Communications Security, 2008.
• Michal Zalewski. «The Tangled Web: A Guide to Securing Modern Web Applications». No Starch Press, 2011.