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

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

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

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

История

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

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

Выполнение

Все современные браузеры реализуют ту или иную форму политики одного и того же происхождения, поскольку это важный краеугольный камень безопасности. ^[4] Политики не обязаны соответствовать точной спецификации. ^[5] но часто расширяются для определения примерно совместимых границ безопасности для других веб-технологий, таких как 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	Успех	Та же схема, хост и порт
:// имя пользователя:пароль@ www.example.com/dir2/other.html http	Успех	Та же схема, хост и порт
http://www.example.com: 80 /dir/other.html	Успех	Большинство современных браузеров неявно назначают порт протокола по умолчанию, если он опущен. ^[6]^[7]
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	Отказ	Другой хост (требуется точное совпадение)
данные :image/gif;base64,R0lGODlhHATAAAAAACwAAAAAAHAT=	Отказ	Другая схема

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

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

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

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

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

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

Испорченность данных

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

Свойство document.domain

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

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

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

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

Междокументный обмен сообщениями

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

JSONP

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

Вебсокеты

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

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

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

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

Атаки

Даже если действует политика одного и того же источника (без ослабления из-за совместного использования ресурсов между источниками), могут быть выполнены определенные атаки из разных источников. WebRTC можно использовать для определения внутреннего IP-адреса жертвы. При попытке подключения к порту с несколькими источниками ответы не могут быть прочитаны в соответствии с политикой одного и того же источника, но JavaScript все равно может делать выводы о том, открыт ли порт или закрыт, проверяя, срабатывает ли событие onload/onerror или мы получаем тайм-аут. между источниками Это дает возможности для сканирования портов . Кроме того, фрагменты JavaScript могут использовать такие методы, как межсайтовые утечки, чтобы использовать давние утечки информации в браузере и получать информацию о перекрестном происхождении.

См. также

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

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

Ссылки

^ «Руководство по Netscape 3.0 — дополнительные темы» . netscape.com . Архивировано из оригинала 8 августа 2002 г. Проверено 16 февраля 2020 г. Навигатор версии 2.02 и более поздних автоматически запрещает сценариям на одном сервере доступ к свойствам документов на другом сервере.
^ «JavaScript 1.0 — 1995» . www.webdesignmuseum.org . Проверено 19 января 2020 г.
^ «Добро пожаловать в Netscape Navigator версии 2.0» . netscape.com . 14 июня 1997 г. Архивировано из оригинала 14 июня 1997 г. Проверено 16 февраля 2020 г.
^ «Справочник по безопасности браузера, часть 2» . Проверено 31 января 2014 г.
^ «Та же политика происхождения» . W3C . Проверено 31 января 2014 г.
^ Китамура, Эйдзи. «Понимание понятий «тот же сайт» и «тот же источник» » . Веб.разработчик . Google . Проверено 26 января 2023 г.
^ "Источник" . Веб-документы сети разработчиков Mozilla . Мозилла . Проверено 26 января 2023 г.
^ Лоуренс, Эрик. «IEInternals — Политика одинакового происхождения, часть 1» . Проверено 22 октября 2013 г.
^ Перейти обратно: ^а ^б «Netscape Navigator 3.0 — Что нового» . netscape.com . 14 июня 1997 г. Архивировано из оригинала 14 июня 1997 г. Проверено 16 февраля 2020 г.
^ «Руководство по JavaScript 1.3 — Безопасность» . netscape.com . 21 февраля 2003 г. Архивировано из оригинала 21 февраля 2003 г. Проверено 16 февраля 2020 г.
^ «Руководство по JavaScript 1.3 — Безопасность» . docs.oracle.com . Архивировано из оригинала 24 августа 2012 г. Проверено 16 февраля 2020 г.
^ ЛеПера, Скотт. «Проблемы междоменной безопасности» . Странный дзен JavaScript . Проверено 4 апреля 2014 г.
^ «Netscape 3.0 — Справочник по JavaScript» . netscape.com . Архивировано из оригинала 3 октября 2002 г. Проверено 16 февраля 2020 г.
^ Создание промежуточного программного обеспечения WSGI

Внешние ссылки

[1] «Руководство по Netscape 3.0 — дополнительные темы» . netscape.com . Архивировано из оригинала 8 августа 2002 г. Проверено 16 февраля 2020 г. Навигатор версии 2.02 и более поздних автоматически запрещает сценариям на одном сервере доступ к свойствам документов на другом сервере.

[2] «JavaScript 1.0 — 1995» . www.webdesignmuseum.org . Проверено 19 января 2020 г.

[3] «Добро пожаловать в Netscape Navigator версии 2.0» . netscape.com . 14 июня 1997 г. Архивировано из оригинала 14 июня 1997 г. Проверено 16 февраля 2020 г.

[4] «Справочник по безопасности браузера, часть 2» . Проверено 31 января 2014 г.

[W3C_Same_Origin_Document-5] «Та же политика происхождения» . W3C . Проверено 31 января 2014 г.

[6] Китамура, Эйдзи. «Понимание понятий «тот же сайт» и «тот же источник» » . Веб.разработчик . Google . Проверено 26 января 2023 г.

[7] "Источник" . Веб-документы сети разработчиков Mozilla . Мозилла . Проверено 26 января 2023 г.

[8] Лоуренс, Эрик. «IEInternals — Политика одинакового происхождения, часть 1» . Проверено 22 октября 2013 г.

[:0-9] Перейти обратно: ^а ^б «Netscape Navigator 3.0 — Что нового» . netscape.com . 14 июня 1997 г. Архивировано из оригинала 14 июня 1997 г. Проверено 16 февраля 2020 г.

[10] «Руководство по JavaScript 1.3 — Безопасность» . netscape.com . 21 февраля 2003 г. Архивировано из оригинала 21 февраля 2003 г. Проверено 16 февраля 2020 г.

[11] «Руководство по JavaScript 1.3 — Безопасность» . docs.oracle.com . Архивировано из оригинала 24 августа 2012 г. Проверено 16 февраля 2020 г.

[12] ЛеПера, Скотт. «Проблемы междоменной безопасности» . Странный дзен JavaScript . Проверено 4 апреля 2014 г.

[13] «Netscape 3.0 — Справочник по JavaScript» . netscape.com . Архивировано из оригинала 3 октября 2002 г. Проверено 16 февраля 2020 г.

[14] Создание промежуточного программного обеспечения WSGI

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]