В вычислениях, Политика одинакового происхождения (иногда сокращенно 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 окон и фреймов, принадлежащих другой домен. Затем браузер спросит пользователя, разрешить ли данный доступ.
Если два окна (или фрейма) содержат сценарии, устанавливающие для домена одно и то же значение, то же -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» в этом окне, вызывая любые определенные пользователем обработчики событий. Сценарий на одной странице по-прежнему не может напрямую обращаться к методам или переменным на другой странице, но они могут безопасно взаимодействовать с помощью этой техники передачи сообщений.
Поскольку элементам 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, то можно сделать вывод, что жертва запускает Дженкинса на своем компьютере. Таким образом, злоумышленник может найти потенциально уязвимые службы, например, во внутренней сети, даже при наличии политики одного происхождения. Если какая-либо служба уязвима для подделки межсайтовых запросов, они могут быть даже скомпрометированы.