Введение

Меры безопасности для клиентского скриптования. В информатике политика одного источника (SOP) — это концепция в модели безопасности веб-приложений. В соответствии с этой политикой веб-браузер разрешает скриптам, содержащимся на первой веб-странице, получать доступ к данным на второй веб-странице, но только если обе веб-страницы имеют один и тот же источник. Источник определяется как комбинация схемы URI, имени хоста и номера порта. Эта политика предотвращает получение доступа вредоносным скриптом с одной страницы к конфиденциальным данным на другой веб-странице через её DOM (Document Object Model). Этот механизм особенно важен для современных веб-приложений, которые активно используют HTTPS-куки для поддержания аутентифицированных пользовательских сеансов, поскольку серверы действуют на основе информации из HTTP-куки для раскрытия конфиденциальной информации или выполнения действий, изменяющих состояние. На клиентской стороне необходимо строго разделять контент, предоставляемый разными сайтами, чтобы предотвратить потерю конфиденциальности или целостности данных. Политика одного источника применяется только к скриптам. Это означает, что к ресурсам, таким как изображения, CSS и динамически загружаемые скрипты, можно получать доступ между разными источниками через соответствующие HTML-теги (за исключением шрифтов). Атаки используют тот факт, что политика одного источника не распространяется на HTML-теги.

История

Концепция политики одного источника была представлена в Netscape Navigator 2.02 в 1995 году, вскоре после появления JavaScript в Netscape 2.0. JavaScript обеспечил возможность написания скриптов на веб-страницах и, в частности, программного доступа к Document Object Model (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 Тот же самый scheme, host и port http://www.example.com/dir2/other.html Тот же самый scheme, host и port http://username:password@www.example.com/dir2/other.html Тот же самый scheme, host и port http://www.example.com:80/dir/other.html Большинство современных браузеров неявно присваивают порт протокола по умолчанию, если он не указан. http://www.example.com:81/dir/other.html Тот же самый scheme и host, но другой port https://www.example.com/dir/other.html Другой scheme http://en.example.com/dir/other.html Другой host http://example.com/dir/other.html Другой host (требуется точное совпадение) http://v2.www.example.com/dir/other.html Другой host (требуется точное совпадение) data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA= Другой scheme

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

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

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

Упрощение политики единого происхождения

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

Загрязнение данных

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

Документ.Доменная собственность

Если два окна (или фрейма) содержат скрипты, которые устанавливают домен на одно и то же значение, политика одинакового происхождения смягчается для этих двух окон, и каждое окно может взаимодействовать с другим. Например, взаимодействующие скрипты в документах, загруженных с orders.example.com и catalog.example.com, могут установить свойство `document.domain` в “example.com”, тем самым заставляя документы выглядеть как имеющие одинаковое происхождение и позволяя каждому документу читать свойства другого. Установка этого свойства неявно устанавливает порт в null, что большинство браузеров интерпретируют иначе, чем порт 80 или даже не указанный порт. Чтобы гарантировать, что доступ будет разрешен браузером, установите свойство `document.domain` на обеих страницах. Концепция `document.domain` была введена в составе Netscape Navigator 3, выпущенного в 1996 году. Она позволяет серверам использовать заголовок для явного перечисления источников, которым разрешено запрашивать файл, или использовать подстановочный знак и разрешать запрашивать файл с любого сайта. Браузеры, такие как Firefox 3.5, Safari 4 и Internet Explorer 10, используют этот заголовок для разрешения междоменных HTTP-запросов с XMLHttpRequest, которые в противном случае были бы запрещены политикой одинакового происхождения.

Пересылка сообщений между документами

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

JSONP

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

Веб-сокеты

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

Угловые корпуса

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

Атаки

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