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

редактировать
Мера безопасности для сценариев на стороне клиента

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

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

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

Содержание

  • 1 История
  • 2 Реализация
  • 3 Правила определения источника
  • 4 Приложения безопасности
  • 5 Ослабление политики одного и того же происхождения
    • 5.1 Распространение данных
    • 5.2 document.domain свойство
    • 5.3 Совместное использование ресурсов между источниками
    • 5.4 Обмен сообщениями между документами
    • 5.5 JSONP
    • 5.6 WebSockets
  • 6 Угловые случаи
  • 7 Атаки на основе политики одного источника
  • 8 См. Также
  • 9 Дополнительная литература
  • 10 Ссылки
  • 11 Внешние ссылки

История

Концепция политики одинакового происхождения была введена в 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

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

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

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

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

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

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

JSONP

Поскольку элементам HTML

WebSockets

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

Угловые случаи

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

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

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

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

См. Также

Дополнительная литература

Ссылки

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

Последняя правка сделана 2021-06-06 09:13:20
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте