В вычислительной технике политика одного и того же источника ( SOP ) — это концепция в модели безопасности веб-приложений. Согласно этой политике, веб-браузер разрешает скриптам, содержащимся на первой веб-странице, получать доступ к данным на второй веб-странице, но только если обе веб-страницы имеют один и тот же источник . Источник определяется как комбинация схемы URI, имени хоста и номера порта. Эта политика не позволяет вредоносному скрипту на одной странице получать доступ к конфиденциальным данным на другой веб-странице через (DOM) этой страницы.
Этот механизм имеет особое значение для современных веб-приложений, которые в значительной степени зависят от HTTPS-cookie для поддержания аутентифицированных сеансов пользователей, поскольку серверы действуют на основе информации 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 ».
В отличие от других браузеров, Internet Explorer не учитывает порт при расчете источника, используя вместо него Зону безопасности. [8]
Политика одного и того же источника защищает от повторного использования аутентифицированных сеансов между источниками. Следующий пример иллюстрирует потенциальный риск безопасности, который может возникнуть без политики одного и того же источника. Предположим, что пользователь посещает банковский веб-сайт и не выходит из системы. Затем пользователь переходит на другой сайт, на котором есть вредоносный код JavaScript, запрашивающий данные с банковского сайта. Поскольку пользователь все еще находится в системе на банковском сайте, вредоносный код может сделать все, что пользователь мог бы сделать на банковском сайте. Например, он может получить список последних транзакций пользователя, создать новую транзакцию и т. д. Это связано с тем, что в изначальном духе всемирной паутины браузеры должны помечать данные аутентификации, такие как файлы cookie сеанса и типы заголовка запроса авторизации на уровне платформы, на банковском сайте на основе домена банковского сайта.
Владельцы банковских сайтов ожидают, что обычные браузеры пользователей, посещающих вредоносный сайт, не разрешат коду, загруженному с вредоносного сайта, получать доступ к cookie-файлу банковского сеанса или авторизации на уровне платформы. Хотя верно, что JavaScript не имеет прямого доступа к cookie-файлу банковского сеанса, он все равно может отправлять и получать запросы на банковский сайт с cookie-файлом банковского сайта. Политика одного и того же источника была введена как требование для браузеров, заботящихся о безопасности, запрещать доступ на чтение ответов из разных источников, при условии, что большинство пользователей предпочитают использовать совместимые браузеры. Политика не запрещает запись. Противодействие злоупотреблению разрешением на запись требует дополнительных мер защиты CSRF со стороны целевых сайтов.
В некоторых случаях политика одного и того же источника слишком ограничительна, что создает проблемы для крупных веб-сайтов, использующих несколько поддоменов . Сначала для передачи данных между документами, находящимися в разных доменах, использовались такие обходные пути, как использование идентификатора фрагмента или window.nameсвойства. Современные браузеры поддерживают несколько методов контролируемого ослабления политики одного и того же источника:
Netscape Navigator недолгое время содержал функцию проверки на наличие заражения . Эта функция была экспериментально введена в 1997 году как часть Netscape 3. [9] По умолчанию эта функция была отключена, но если ее включить пользователем, она позволяла веб-сайтам пытаться читать свойства JavaScript окон и фреймов, принадлежащих другому домену. Затем браузер спрашивал пользователя, разрешить ли доступ, о котором идет речь. [10] [11]
Если два окна (или фрейма) содержат скрипты, которые устанавливают домен на одно и то же значение, политика одного и того же источника смягчается для этих двух окон, и каждое окно может взаимодействовать с другим. Например, взаимодействующие скрипты в документах, загруженных с orders.example.com и catalog.example.com, могут устанавливать свои document.domainсвойства на «example.com», тем самым создавая видимость того, что документы имеют одно и то же происхождение, и позволяя каждому документу читать свойства другого. Установка этого свойства неявно устанавливает порт на null, который большинство браузеров будут интерпретировать иначе, чем порт 80 или даже неуказанный порт. Чтобы гарантировать, что доступ будет разрешен браузером, установите свойство document.domain обеих страниц. [12]
Эта document.domainконцепция была представлена как часть Netscape Navigator 3, [13] выпущенного в 1996 году. [9]
Другой метод ослабления политики одного и того же источника стандартизирован под названием Cross-Origin Resource Sharing (CORS). Этот стандарт расширяет HTTP новым заголовком запроса Origin и новым заголовком ответа Access-Control-Allow-Origin. [14] Он позволяет серверам использовать заголовок для явного перечисления источников, которые могут запрашивать файл, или использовать подстановочный знак и разрешать запрашивать файл любым сайтом. Такие браузеры, как Firefox 3.5, Safari 4 и Internet Explorer 10, используют этот заголовок для разрешения HTTP-запросов кросс-источника с XMLHttpRequest, которые в противном случае были бы запрещены политикой одного и того же источника.
Другая техника, кросс-документный обмен сообщениями, позволяет скрипту с одной страницы передавать текстовые сообщения скрипту на другой странице независимо от происхождения скрипта. Вызов метода postMessage() для объекта Window асинхронно запускает событие "onmessage" в этом окне, запуская любые пользовательские обработчики событий. Скрипт на одной странице по-прежнему не может напрямую обращаться к методам или переменным на другой странице, но они могут безопасно взаимодействовать с помощью этой техники передачи сообщений.
Поскольку HTML- <script>элементам разрешено извлекать и выполнять контент из других доменов, страница может обойти политику одного и того же источника и получать данные JSON из другого домена, загрузив ресурс, который возвращает полезную нагрузку JSONP. Полезная нагрузка JSONP состоит из внутренней полезной нагрузки JSON, обернутой предопределенным вызовом функции. Когда ресурс скрипта загружается браузером, назначенная функция обратного вызова будет вызвана для обработки обернутой полезной нагрузки JSON.
Современные браузеры разрешают скрипту подключаться к адресу WebSocket без применения политики одного и того же источника. Однако они распознают, когда используется WebSocket URI, и вставляют заголовок Origin: в запрос, который указывает источник скрипта, запрашивающего соединение. Для обеспечения межсайтовой безопасности сервер WebSocket должен сравнить данные заголовка со списком разрешенных источников, которым разрешено получать ответ.
Поведение проверок на одинаковое происхождение и связанных с ними механизмов не является четко определенным в ряде особых случаев, например, для псевдопротоколов, которые не имеют четко определенного имени хоста или порта, связанного с их URL-адресами ( file:, data: и т. д.). Это исторически вызывало довольно много проблем безопасности, таких как в целом нежелательная способность любого локально сохраненного HTML-файла получать доступ ко всем другим файлам на диске или взаимодействовать с любым сайтом в Интернете.
Наконец, некоторые типы атак, такие как перепривязка DNS или прокси-серверы, позволяют частично обойти проверку имени хоста и позволяют мошенническим веб-страницам напрямую взаимодействовать с сайтами через адреса, отличные от их «истинного», канонического происхождения. Влияние таких атак ограничивается очень специфическими сценариями, поскольку браузер по-прежнему считает, что взаимодействует с сайтом злоумышленника, и поэтому не раскрывает злоумышленнику сторонние файлы cookie или другую конфиденциальную информацию.
Даже когда действует политика одного источника (без смягчения Cross-Origin Resource Sharing), могут быть выполнены определенные атаки с использованием кросс-источника. WebRTC можно использовать для определения внутреннего IP-адреса жертвы. При попытке подключения к порту с кросс-источником ответы не могут быть прочитаны из-за политики одного источника, но JavaScript все равно может делать выводы о том, открыт или закрыт порт, проверяя, срабатывает ли событие onload/onerror или истекает ли время ожидания. Это дает возможности для сканирования портов с разных источников . Кроме того, фрагменты JavaScript могут использовать такие методы, как кросс-сайтовые утечки, чтобы использовать давние утечки информации в браузере для вывода информации о кросс-источнике.
Navigator версии 2.02 и более поздних автоматически предотвращает доступ скриптов на одном сервере к свойствам документов на другом сервере.