Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
HTTP
Способы запроса
Поля заголовка
Коды состояния
Методы управления безопасным доступом
Уязвимости безопасности

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

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

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

История [ править ]

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

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

Реализация [ править ]

Все современные браузеры реализуют ту или иную форму политики одного и того же происхождения, поскольку это важный краеугольный камень безопасности. [7] Политики не обязательно должны соответствовать точной спецификации [8], но часто расширяются для определения примерно совместимых границ безопасности для других веб-технологий, таких как 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 не включает порт в вычисление источника, используя вместо него Зону безопасности. [9]

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

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

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

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

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

Порча данных [ править ]

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

свойство document.domain [ править ]

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

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

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

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

Обмен сообщениями между документами [ править ]

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

JSONP [ править ]

Основная статья: JSONP

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

WebSockets [ править ]

Основная статья: WebSocket

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

Угловые шкафы [ править ]

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

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

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

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

См. Также [ править ]

  • Совместное использование ресурсов из разных источников
  • Межсайтовый скриптинг
  • Подделка межсайтовых запросов
  • Обмен сообщениями между документами
  • Политика безопасности контента

Дальнейшее чтение [ править ]

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

Ссылки [ править ]

  1. ^ Механизм управления состоянием HTTP IETF , апрель 2011 г.
  2. ^ Кемп, Джон (2011-02-04). «Безопасность в сети» . Проверено 24 июля 2018 . Политика одинакового происхождения гласит, что документ из одного уникального источника может загружать ресурсы только из источника, из которого был загружен документ. В частности, это относится к вызовам XMLHttpRequest из документа. На изображения, CSS и динамически загружаемые скрипты не распространяется политика одинакового происхождения.
  3. ^ "@ font-face" . Веб-документы MDN . Проверено 24 июля 2018 . Веб-шрифты подлежат тому же ограничению домена (файлы шрифтов должны находиться в том же домене, что и страница, использующая их), если только элементы управления доступом HTTP не используются для ослабления этого ограничения.
  4. ^ «Руководство Netscape 3.0 - Дополнительные темы» . netscape.com . Архивировано из оригинала на 2002-08-08 . Проверено 16 февраля 2020 . Navigator версии 2.02 и выше автоматически запрещает скриптам на одном сервере доступ к свойствам документов на другом сервере.
  5. ^ «JavaScript 1.0 - 1995» . www.webdesignmuseum.org . Проверено 19 января 2020 .
  6. ^ «Добро пожаловать в Netscape Navigator версии 2.0» . netscape.com . 1997-06-14. Архивировано из оригинала на 1997-06-14 . Проверено 16 февраля 2020 .
  7. ^ "Руководство по безопасности браузера, часть 2" . google.com . Проверено 31 января 2014 года .
  8. ^ «Та же политика происхождения» . W3C . Проверено 31 января 2014 года .
  9. ^ Лоуренс, Эрик. «IEInternals - та же политика происхождения, часть 1» . Проверено 22 октября 2013 года .
  10. ^ a b «Netscape Navigator 3.0 - Что нового» . netscape.com . 1997-06-14. Архивировано из оригинала на 1997-06-14 . Проверено 16 февраля 2020 .
  11. ^ «Руководство по JavaScript 1.3 - Безопасность» . netscape.com . 21 февраля 2003 г. Архивировано из оригинала на 2003-02-21 . Проверено 16 февраля 2020 .
  12. ^ «Руководство по JavaScript 1.3 - Безопасность» . docs.oracle.com . Архивировано 24 августа 2012 года . Проверено 16 февраля 2020 .
  13. ^ LePera, Скотт. «Проблемы междоменной безопасности» . Странный дзен JavaScript . Проверено 4 апреля 2014 года .
  14. ^ "Netscape 3.0 - Руководство по JavaScript" . netscape.com . Архивировано из оригинала на 2002-10-03 . Проверено 16 февраля 2020 .
  15. ^ Создание промежуточного программного обеспечения WSGI
  16. ^ Определение внутреннего IP-адреса с помощью JavaScript
  17. ^ Атака на внутреннюю сеть из общедоступного Интернета с использованием браузера в качестве прокси

Внешние ссылки [ править ]

  • Подробное сравнение нескольких разновидностей политик одинакового происхождения
  • Обзор недостатков политик одинакового происхождения и их последствий для веб-безопасности на Wayback Machine (архив 11 февраля 2007 г.)
  • Образец спецификации политики одного и того же происхождения, предоставленный поставщиком
  • Определение происхождения в спецификации HTML5
  • Статья W3C о той же политике происхождения
  • RFC 6454 о концепции веб-происхождения
  • Сообщение в блоге: Политика одинакового происхождения файлов cookie
  • Плагин wordpress.org для Политики безопасности контента