Политика одинакового происхождения - Same-origin policy

В вычислениях политика одного и того же происхождения (иногда сокращенно SOP ) является важной концепцией в модели безопасности веб-приложений . В соответствии с политикой веб-браузер разрешает сценариям, содержащимся на первой веб-странице, получать доступ к данным на второй веб-странице, но только в том случае, если обе веб-страницы имеют одно и то же происхождение . Источник определяется как комбинация схемы URI , имени хоста и номера порта . Эта политика предотвращает получение вредоносным сценарием на одной странице доступа к конфиденциальным данным на другой веб-странице через объектную модель документа этой страницы .

Этот механизм имеет особое значение для современных веб-приложений, которые во многом зависят от файлов cookie HTTP для поддержания аутентифицированных пользовательских сеансов, поскольку серверы действуют на основе информации cookie HTTP, чтобы раскрыть конфиденциальную информацию или предпринять действия, изменяющие состояние. На стороне клиента должно поддерживаться строгое разделение контента, предоставляемого несвязанными сайтами, чтобы предотвратить потерю конфиденциальности или целостности данных.

Очень важно помнить, что политика одного и того же происхождения применяется только к скриптам. Это означает, что к таким ресурсам, как изображения, CSS и динамически загружаемые скрипты, можно получить доступ из разных источников через соответствующие теги HTML (заметным исключением являются шрифты). Атаки используют тот факт, что одна и та же политика происхождения не применяется к тегам HTML.

История

Концепция политики одинакового происхождения была введена Netscape Navigator 2.02 в 1995 году, вскоре после появления JavaScript в Netscape 2.0. JavaScript позволяет создавать сценарии на веб-страницах и, в частности, программный доступ к объектной модели документа (DOM).

Изначально политика была разработана для защиты доступа к модели DOM, но с тех пор была расширена для защиты конфиденциальных частей глобального объекта JavaScript.

Реализация

Все современные браузеры реализуют ту или иную форму политики одного и того же происхождения, поскольку это важный краеугольный камень безопасности. Политики не обязательно должны соответствовать точной спецификации, но часто расширяются для определения примерно совместимых границ безопасности для других веб-технологий, таких как Microsoft Silverlight , Adobe Flash или Adobe Acrobat , или для механизмов, отличных от прямого управления DOM, таких как XMLHttpRequest .

Правила определения происхождения

Алгоритм, используемый для вычисления «происхождения» URI, указан в RFC 6454, раздел 4. Для абсолютных URI источником является тройка {схема, хост, порт}. Если URI не использует иерархический элемент в качестве центра именования (см. RFC 3986 , раздел 3.2) или если URI не является абсолютным URI, то используется глобальный уникальный идентификатор. Два ресурса считаются имеющими одно и то же происхождение тогда и только тогда, когда все эти значения абсолютно одинаковы.

Для иллюстрации в следующей таблице представлен обзор типичных результатов проверок по URL-адресу « http://www.example.com/dir/page.html ».


Сравните URL	Исход	Причина
http://www.example.com /dir/page2.html	Успех	Та же схема, хост и порт
http://www.example.com /dir2/other.html	Успех	Та же схема, хост и порт
http: // имя пользователя: пароль @ www.example.com /dir2/other.html	Успех	Та же схема, хост и порт
http://www.example.com: 81 /dir/other.html	Отказ	Та же схема и хост, но другой порт
https : //www.example.com/dir/other.html	Отказ	Другая схема
http: // en.example.com /dir/other.html	Отказ	Другой хост
http: // example.com /dir/other.html	Отказ	Другой хост (требуется точное соответствие)
http: // v2.www.example.com /dir/other.html	Отказ	Другой хост (требуется точное соответствие)
http://www.example.com: 80 /dir/other.html	Зависит от	Порт явный. Зависит от реализации в браузере.

В отличие от других браузеров, Internet Explorer не включает порт в вычисление источника, используя вместо него Зону безопасности.

Доступ для чтения к конфиденциальным ответам из разных источников с помощью многоразовой аутентификации

Политика одного и того же происхождения защищает от повторного использования аутентифицированных сеансов в разных источниках. В следующем примере показана потенциальная угроза безопасности, которая может возникнуть без политики одного и того же происхождения. Предположим, что пользователь посещает веб-сайт банка и не выходит из системы. Затем пользователь переходит на другой сайт с вредоносным кодом JavaScript, который запрашивает данные с сайта банка. Поскольку пользователь по-прежнему авторизован на сайте банка, вредоносный код может делать все, что пользователь может сделать на сайте банка. Например, он может получить список последних транзакций пользователя, создать новую транзакцию и т. Д. Это связано с тем, что в исходном духе всемирной паутины браузеры должны помечать детали аутентификации, такие как файлы cookie сеанса и платформенные. виды уровня заголовка запроса авторизации к сайту банка в зависимости от домена сайта банка.

Владельцы сайтов банка ожидают, что обычные браузеры пользователей, посещающих вредоносный сайт, не позволят коду, загруженному с вредоносного сайта, получить доступ к cookie банковского сеанса или авторизации на уровне платформы. Хотя это правда, что JavaScript не имеет прямого доступа к куки-файлу банковской сессии, он все же может отправлять и получать запросы на банковский сайт с помощью куки-файла сеанса банковского сайта. Политика одинакового происхождения была введена как требование для браузеров, ориентированных на безопасность, чтобы запретить доступ для чтения к ответам из разных источников, с предположением, что большинство пользователей предпочитают использовать совместимые браузеры. Политика не запрещает пишет. Противодействие злоупотреблению разрешением на запись требует дополнительной защиты CSRF со стороны целевых сайтов.

Ослабление политики одинакового происхождения

В некоторых случаях политика одного и того же происхождения является слишком строгой, что создает проблемы для крупных веб-сайтов, использующих несколько поддоменов . Сначала для передачи данных между документами, находящимися в разных доменах , использовался ряд обходных приемов, таких как использование идентификатора фрагмента или window.nameсвойства. Современные браузеры поддерживают несколько методов контролируемого ослабления политики одного и того же происхождения:

Заражение данных

Netscape Navigator кратко содержал функцию проверки на наличие заражения . Эта функция была экспериментально представлена в 1997 году как часть Netscape 3. По умолчанию эта функция была отключена, но, если она была включена пользователем, она позволяла веб-сайтам пытаться читать свойства JavaScript окон и фреймов, принадлежащих другому домену. Затем браузер спросит пользователя, разрешить ли рассматриваемый доступ.

document.domain свойство

Если два окна (или фрейма) содержат сценарии, устанавливающие для домена одно и то же значение, политика одного и того же происхождения ослабляется для этих двух окон, и каждое окно может взаимодействовать с другим. Например, совместные скрипты в документах, загруженных с orders.example.com и catalog.example.com, могут установить свои document.domainсвойства на «example.com», тем самым создавая впечатление, что документы имеют одно и то же происхождение, и позволяя каждому документу читать свойства Другие. Установка этого свойства неявно устанавливает для порта значение null, которое большинство браузеров будет интерпретировать иначе, чем порт 80 или даже неуказанный порт. Чтобы гарантировать, что доступ будет разрешен браузером, установите свойство document.domain на обеих страницах.

Эта document.domainконцепция была представлена как часть Netscape Navigator 3, выпущенного в 1996 году.

Совместное использование ресурсов между источниками

Другой метод ослабления политики одинакового происхождения стандартизирован под названием Cross-Origin Resource Sharing (CORS). Этот стандарт расширяет HTTP с новым заголовком запроса Origin и новым заголовком ответа Access-Control-Allow-Origin. Это позволяет серверам использовать заголовок для явного перечисления источников, которые могут запрашивать файл, или использовать подстановочный знак и разрешать запрос файла любым сайтом. Браузеры, такие как Firefox 3.5, Safari 4 и Internet Explorer 10, используют этот заголовок, чтобы разрешить HTTP-запросы с разными источниками с XMLHttpRequest, которые в противном случае были бы запрещены политикой того же происхождения.

Обмен сообщениями между документами

Другой метод, обмен сообщениями между документами, позволяет сценарию с одной страницы передавать текстовые сообщения сценарию на другой странице независимо от происхождения сценария. Вызов метода postMessage () для объекта Window асинхронно запускает событие «onmessage» в этом окне, вызывая любые определенные пользователем обработчики событий. Сценарий на одной странице по-прежнему не может напрямую обращаться к методам или переменным на другой странице, но они могут безопасно взаимодействовать с помощью этой техники передачи сообщений.

JSONP

Поскольку HTML- <script>элементам разрешено извлекать и выполнять контент из других доменов, страница может обходить политику того же происхождения и получать данные JSON из другого домена, загружая ресурс, который возвращает полезную нагрузку JSONP. Полезные данные JSONP состоят из внутренних полезных данных JSON, обернутых предварительно определенным вызовом функции. Когда ресурс сценария загружается браузером, будет вызвана назначенная функция обратного вызова для обработки обернутой полезной нагрузки JSON.

WebSockets

Современные браузеры разрешают сценарию подключаться к адресу WebSocket без применения политики того же происхождения. Однако они распознают использование URI WebSocket и вставляют заголовок Origin: в запрос, который указывает источник сценария, запрашивающего соединение. Для обеспечения межсайтовой безопасности сервер WebSocket должен сравнить данные заголовка с белым списком источников, которым разрешено получать ответ.

Угловые шкафы

Поведение проверок одного и того же происхождения и связанных механизмов недостаточно четко определено в ряде крайних случаев, например, для псевдопротоколов, у которых нет четко определенного имени хоста или порта, связанного с их URL-адресами ( file:, data: и т. Д. .). Исторически это вызывало изрядное количество проблем с безопасностью, таких как обычно нежелательная способность любого локально хранимого файла HTML получать доступ ко всем другим файлам на диске или связываться с любым сайтом в Интернете.

Наконец, определенные типы атак, такие как повторное связывание DNS или прокси на стороне сервера, позволяют частично нарушить проверку имени хоста и позволяют мошенническим веб-страницам напрямую взаимодействовать с сайтами через адреса, отличные от их «истинных», канонических источник. Воздействие таких атак ограничено очень конкретными сценариями, поскольку браузер по-прежнему считает, что он взаимодействует с сайтом злоумышленника, и поэтому не раскрывает сторонние файлы cookie или другую конфиденциальную информацию злоумышленнику.

Атаки на основании политики одного происхождения

Даже когда действует политика одного и того же происхождения (без ослабления совместного использования ресурсов между источниками), могут выполняться определенные компьютерные атаки с перекрестным происхождением. WebRTC можно использовать для определения внутреннего IP-адреса жертвы. При попытке подключиться к порту с перекрестным происхождением ответы не могут быть прочитаны с учетом политики одного и того же происхождения, но JavaScript все равно может делать выводы о том, открыт ли порт или закрыт, проверяя, срабатывает ли событие onload / onerror, или если получаем таймаут. Это дает возможности для сканирования портов между разными источниками. Кроме того, JavaScript может даже использовать сервисы отпечатков пальцев из разных источников, используя файлы по умолчанию. Например, если JavaScript, загруженный с сайта evil.com, пытается открыть файл http://127.0.0.1/images/jenkins.png , и возникает событие onload, то можно сделать вывод, что жертва запускает Jenkins на своем собственный компьютер. Таким образом, злоумышленник может найти потенциально уязвимые службы, например, во внутренней сети, даже при наличии политики одного происхождения. Если какая-либо служба будет уязвима для подделки межсайтовых запросов, она может быть даже взломана.

Смотрите также

дальнейшее чтение

Политика одинакового происхождения в 500 строках или меньше .

Languages

In other projects