Аннотация
Этот документ определяет понятие «origin» (происхождение/источник), которое часто используется в качестве области оснований или привилегий пользовательскими агентами. Обычно пользовательские агенты изолируют контент, полученный из разных источников, чтобы предотвратить вмешательство операторов вредоносных веб-сайтов в работу безопасных веб-сайтов. В дополнение к изложению принципов, лежащих в основе концепции происхождения, в этом документе подробно описано, как определить источник URI и как преобразовать источник в строку. Он также определяет поле заголовка HTTP с именем «Origin», которое указывает, какие источники связаны с запросом HTTP.
Оригинальная версия документа на английском языке RFC 6454 PDF
Оглавление
1. Введение
2. Соглашения
2.1. Критерии соответствия
2.2. Обозначение синтаксиса
2.3. Терминология
3. Принципы политики одинакового происхождения
3.1. Доверие
3.1.1. Ловушки
3.2. Происхождение
3.2.1. Примеры
3.3. Основание
3.3.1. Ловушки
3.4. Политика
3.4.1. Доступ к объекту
3.4.2. Доступ к сети
3.4.3. Ловушки
3.5. Вывод
4. Происхождение из URI
5. Сравнение происхождений
6. Сериализация происхождений
6.1. Юникод-сериализация происхождения
6.2. ASCII-сериализация происхождения
7. Поле заголовка происхождения HTTP
7.1. Синтаксис
7.2. Семантика
7.3. Требования к пользовательскому агенту
8. Соображения безопасности
8.1. Опора на DNS
8.2. Расходящиеся единицы изоляции
8.3. Окружающее основание
8.4. Зависимость IDNA и миграция
9. Соображения IANA
10. Ссылки
10.1. Нормативные ссылки
10.2. Информативные ссылки
Приложение A. Благодарности
1. Введение
Пользовательские агенты взаимодействуют с контентом, созданным большим количеством авторов. Хотя многие из этих авторов действуют из лучших побуждений, некоторые авторы могут быть злонамеренными. В той степени, в которой пользовательские агенты предпринимают действия на основе обрабатываемого контента, разработчики пользовательских агентов могут захотеть ограничить возможность злонамеренных авторов нарушать конфиденциальность или целостность другого контента или серверов.
В качестве примера рассмотрим агент пользователя HTTP, который отображает содержимое HTML, полученное с различных серверов. Если пользовательский агент выполняет сценарии, содержащиеся в этих документах, разработчик пользовательского агента может пожелать запретить сценариям, полученным с вредоносного сервера, читать документы, хранящиеся на честном сервере, который может, например, находиться за межсетевым экраном.
Традиционно пользовательские агенты разделяют контент по его «происхождению». В частности, пользовательские агенты позволяют контенту, полученному из одного источника, свободно взаимодействовать с другим контентом, полученным из этого источника, но пользовательские агенты ограничивают то, как этот контент может взаимодействовать с контентом из другого источника.
В этом документе описываются принципы, лежащие в основе так называемой политики одинакового происхождения (same-origin policy), а также основные принципы сравнения и сериализации источников. Этот документ не описывает все аспекты политики одного и того же происхождения, детали которой оставлены для других спецификаций, таких как HTML [HTML] и WebSockets [RFC6455 #], потому что детали часто зависят от приложения.
2. Соглашения
2.1. Критерии соответствия
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].
Требования, сформулированные в императиве как часть алгоритмов (такие как «убрать все начальные пробелы» или «вернуть ложь и прервать эти шаги»), должны интерпретироваться со значением ключевого слова («ОБЯЗАН», «ДОЛЖЕН», » МОЖЕТ »и т. д.), Используемых при представлении алгоритма.
Требования соответствия, сформулированные в виде алгоритмов или конкретных шагов, могут быть реализованы любым способом при условии, что конечный результат эквивалентен. В частности, алгоритмы, определенные в этой спецификации, предназначены для простоты понимания и не предназначены для обеспечения высокой производительности.
2.2. Обозначение синтаксиса
В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) из [RFC5234 #].
Следующие основные правила включены по ссылке, как определено в [RFC5234 #], Приложение B.1: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элементы управления), DIGIT (десятичные 0-9) , DQUOTE (двойные кавычки), HEXDIG (шестнадцатеричные 0-9 / AF / af), LF (перевод строки), OCTET (любая 8-битная последовательность данных), SP (пробел), HTAB (горизонтальная табуляция), CHAR (любая Символ USASCII), VCHAR (любой видимый символ US-ASCII) и WSP (пробел).
Правило OWS используется там, где может появиться ноль или более линейных октетов пробелов. OWS СЛЕДУЕТ либо не производиться, либо производиться как единый SP. Множественные октеты OWS, которые встречаются в содержимом поля, ДОЛЖНЫ быть заменены одним SP или преобразованы во все октеты SP (каждый октет, кроме SP, заменен на SP) перед интерпретацией значения поля или пересылкой сообщения в нисходящем направлении.
OWS = *( SP / HTAB / obs-fold ); "optional" whitespace obs-fold = CRLF ( SP / HTAB ); obsolete line folding
2.3. Терминология
Термины «пользовательский агент», «клиент», «сервер», «прокси» и «исходный сервер» имеют то же значение, что и в спецификации HTTP / 1.1 ([RFC2616 #], раздел 1.3).
«Глобально уникальный идентификатор» — это значение, которое отличается от всех других ранее существовавших значений. Например, достаточно длинная случайная строка, вероятно, будет глобально уникальным идентификатором. Если значение источника никогда не покидает пользовательский агент, монотонно увеличивающийся счетчик, локальный для пользовательского агента, также может служить глобальным уникальным идентификатором.
3. Принципы политики одинакового происхождения
Многие пользовательские агенты предпринимают действия от имени удаленных сторон. Например, пользовательские агенты HTTP следуют перенаправлениям, которые являются инструкциями с удаленных серверов, а пользовательские агенты HTML предоставляют интерфейсы многофункциональной объектной модели документа (DOM) сценариям, полученным с удаленных серверов.
Без какой-либо модели безопасности пользовательские агенты могут предпринимать действия, наносящие ущерб пользователю или другим сторонам. Со временем многие связанные с сетью технологии сошлись в направлении общей модели безопасности, известной в просторечии как «политика одного происхождения». Хотя эта модель безопасности развивалась в основном органически, политику одного и того же происхождения можно понять с помощью нескольких ключевых концепций. В этом разделе представлены эти концепции и даны советы о том, как их безопасно использовать.
3.1. Доверие
Политика того же происхождения определяет доверие по URI. Например, в HTML-документах указывается, какой сценарий запускать с помощью URI:
<script src="https://example.com/library.js"></script>
Когда пользовательский агент обрабатывает этот элемент, пользовательский агент выбирает сценарий по указанному URI и выполняет сценарий с привилегиями документа. Таким образом, документ предоставляет все имеющиеся у него привилегии ресурсу, указанному в URI. По сути, документ заявляет, что он доверяет целостности информации, полученной из этого URI.
Помимо импорта библиотек из URI, пользовательские агенты также отправляют информацию удаленным сторонам, обозначенным URI. Например, рассмотрим элемент формы HTML:
<form method="POST" action="https://example.com/login"> ... <input type="password"> ... </form>
Когда пользователь вводит свой пароль и отправляет форму, пользовательский агент отправляет пароль в конечную точку сети, обозначенную URI. Таким образом, документ экспортирует свои секретные данные в этот URI, по сути заявляя, что он доверяет конфиденциальности информации, отправленной на этот URI.
3.1.1. Ловушки
При разработке новых протоколов, использующих политику одного и того же происхождения, убедитесь, что важные различия доверия видны в URI. Например, если и безопасность транспортного уровня (TLS), и ресурсы, не защищенные TLS, используют схему URI «http» (как в [RFC2817 #]), документ не сможет указать, что он хочет получить сценарий только через TLS. Используя схему URI «https», документы могут указать, что они хотят взаимодействовать с ресурсами, которые защищены от активных сетевых злоумышленников.
3.2. Происхождение
В принципе, пользовательские агенты могут рассматривать каждый URI как отдельный домен защиты и требовать явного согласия для контента, полученного из одного URI, для взаимодействия с другим URI. К сожалению, такая конструкция обременительна для разработчиков, поскольку веб-приложения часто состоят из нескольких ресурсов, действующих согласованно.
Вместо этого пользовательские агенты группируют URI в домены защиты, называемые «источниками». Грубо говоря, два URI являются частью одного источника (т. е. представляют одного и того же принципала), если они имеют одинаковую схему, хост и порт. (См. Подробную информацию в разделе 4.)
Вопрос: Почему бы просто не использовать хост?
Ответ: Включение схемы в исходный кортеж важно для безопасности. Если бы пользовательские агенты не включали схему, не было бы изоляции между http://example.com и https://example.com, потому что у них один и тот же хост. Однако без этой изоляции активный сетевой злоумышленник может повредить контент, полученный с http://example.com, и получить от этого контента указание пользовательскому агенту нарушить конфиденциальность и целостность контента, полученного с https://example.com, в обход защите, предоставляемой TLS [RFC5246 #].
Вопрос: Зачем использовать полное имя хоста, а не просто домен верхнего уровня?
Ответ: Хотя DNS имеет иерархическое делегирование, доверительные отношения между именами узлов зависят от развертывания. Например, во многих образовательных учреждениях учащиеся могут размещать контент по адресу https://example.edu/~student/, но это не означает, что документ, созданный учащимся, должен принадлежать к тому же источнику (т. е. иметь одинаковую защиту домена) в качестве веб-приложения для управления оценками, размещенного на https://grades.example.edu/.
Развертывание «example.edu» показывает, что группировка ресурсов по происхождению не всегда полностью соответствует каждому сценарию развертывания. При таком развертывании веб-сайт каждого учащегося имеет одно и то же происхождение, что может быть нежелательно. В каком-то смысле гранулярность происхождения является историческим артефактом развития модели безопасности.
3.2.1. Примеры
Все следующие ресурсы имеют одинаковое происхождение:
http://example.com/ http://example.com:80/ http://example.com/path/file
Каждый из URI имеет одинаковую схему, компоненты хоста и порта.
Каждый из следующих ресурсов имеет свое происхождение, отличное от других.
http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ http://ietf.org/
В каждом случае по крайней мере один из компонентов схемы, хоста и порта будет отличаться от других в списке.
3.3. Основание
Хотя пользовательские агенты группируют URI в источники, не каждый ресурс в источнике имеет одинаковые полномочия (в смысле безопасности слова «authority», а не в смысле основания из [RFC3986 #]). Например, изображение является пассивным содержимым и, следовательно, не имеет полномочий, то есть изображение не имеет доступа к объектам и ресурсам, доступным для его источника. Напротив, документ HTML несет в себе все права доступа к источнику, и сценарии внутри документа (или импортированные в него) могут получить доступ к каждому ресурсу в его источнике.
Пользовательские агенты определяют, какие полномочия предоставить ресурсу, проверяя его тип носителя. Например, ресурсы с типом мультимедиа «image/png» обрабатываются как изображения, а ресурсы с типом мультимедиа «text/html» обрабатываются как документы HTML.
При размещении ненадежного контента (такого как контент, созданный пользователями) веб-приложения могут ограничивать полномочия этого контента, ограничивая его тип мультимедиа. Например, обслуживание созданного пользователем контента как «image/png» менее рискованно, чем обслуживание созданного пользователем контента как «text/html«. Конечно, многие веб-приложения включают в свои HTML-документы ненадежный контент. Если не сделать это осторожно, эти приложения рискуют утратить авторитет своего источника на ненадежный контент — уязвимость, известная как межсайтовый скриптинг (cross-site scripting).
3.3.1. Ловушки
При разработке новых частей веб-платформы будьте осторожны, чтобы не предоставлять права доступа к ресурсам независимо от типа носителя. Многие веб-приложения обслуживают ненадежный контент с ограниченными типами мультимедиа. Новая функция веб-платформы, которая предоставляет полномочия этим частям контента, рискует внести уязвимости в существующие приложения. Вместо этого предпочтите предоставить полномочия типам носителей, которые уже обладают полными полномочиями источника, или новым типам носителей, разработанным специально для того, чтобы нести новые полномочия.
Чтобы оставаться совместимыми с серверами, которые предоставляют неправильные типы мультимедиа, некоторые пользовательские агенты используют «сниффинг содержимого» и обрабатывают контент, как если бы он имел другой тип мультимедиа, чем тип мультимедиа, предоставленный сервером. Если не делать это осторожно, анализ содержимого может привести к уязвимостям безопасности, поскольку пользовательские агенты могут предоставлять типы носителей с низким уровнем доступа, такие как изображения, привилегии типов носителей с высоким уровнем полномочий, таких как документы HTML [SNIFF].
3.4. Политика
Вообще говоря, пользовательские агенты изолируют разные источники и разрешают контролируемую связь между источниками. Детали того, как пользовательские агенты обеспечивают изоляцию и обмен данными, зависят от нескольких факторов.
3.4.1. Доступ к объекту
Большинство объектов (также известных как интерфейсы прикладного программирования или API), предоставляемые пользовательским агентом, доступны только для одного и того же источника. В частности, контент, полученный из одного URI, может получить доступ к объектам, связанным с контентом, полученным из другого URI, если и только если два URI принадлежат одному источнику, например, имеют одинаковую схему, хост и порт.
Из этого общего правила есть некоторые исключения. Например, некоторые части интерфейса местоположения HTML доступны из разных источников (например, для обеспечения навигации в других контекстах просмотра). В качестве другого примера, интерфейс postMessage HTML явно виден в разных источниках для облегчения взаимодействия между источниками. Открывать объекты постороннему происхождению опасно, и его следует делать только с большой осторожностью, потому что это делает эти объекты уязвимыми для потенциальных злоумышленников.
3.4.2. Доступ к сети
Доступ к сетевым ресурсам зависит от того, находятся ли ресурсы в том же источнике, что и контент, пытающийся получить к ним доступ.
Как правило, чтение информации из другого источника запрещено. Однако источнику разрешено использовать некоторые виды ресурсов, извлеченных из других источников. Например, источнику разрешено выполнять сценарий, отображать изображения и применять таблицы стилей из любого источника. Точно так же источник может отображать контент из другого источника, например HTML-документ во фрейме HTML. Сетевые ресурсы также могут позволить другим источникам считывать их информацию, например, с помощью совместного использования ресурсов между источниками [CORS — Cross-Origin Resource Sharing]. В этих случаях доступ обычно предоставляется для каждого источника.
Отправка информации в другой источник разрешена. Однако отправка информации по сети в произвольных форматах опасна. По этой причине пользовательские агенты ограничивают документы отправкой информации с использованием определенных протоколов, например, в HTTP-запросе без пользовательских заголовков. Расширение набора разрешенных протоколов, например, путем добавления поддержки WebSockets, должно производиться осторожно, чтобы избежать появления уязвимостей [RFC6455 #].
3.4.3. Ловушки
Когда пользовательские агенты разрешают одному источнику взаимодействовать с ресурсами из другого источника, они вызывают проблемы безопасности. Например, возможность отображать изображения из другого источника приводит к утечке их высоты и ширины. Точно так же возможность отправлять сетевые запросы в другой источник приводит к уязвимости подделки межсайтовых запросов [CSRF]. Однако разработчики пользовательских агентов часто уравновешивают эти риски с преимуществами разрешения взаимодействия между источниками. Например, пользовательский агент HTML, блокирующий сетевые запросы из разных источников, не позволит своим пользователям переходить по гиперссылкам, что является основной функцией Интернета.
При добавлении новых функций к веб-платформе может возникнуть соблазн предоставить привилегию одному ресурсу, но удержать эту привилегию у другого ресурса в том же источнике. Однако удержание привилегий таким способом неэффективно, потому что ресурс без привилегии обычно может получить привилегию в любом случае, поскольку пользовательские агенты не изолируют ресурсы в источнике. Вместо этого привилегии должны предоставляться или отказываться от источника в целом (вместо того, чтобы проводить различие между отдельными ресурсами в пределах источника) [BOFGO].
3.5. Вывод
Политика одинакового происхождения использует URI для обозначения доверительных отношений. URI сгруппированы в источники, которые представляют собой домены защиты. Некоторым ресурсам в источнике (например, активному контенту) предоставляются полные полномочия источника, тогда как другим ресурсам в источнике (например, пассивному контенту) не предоставляются полномочия источника. Контенту, имеющему полномочия источника, предоставляется доступ к объектам и сетевым ресурсам в пределах его собственного источника. Этому контенту также предоставляется ограниченный доступ к объектам и сетевым ресурсам из других источников, но эти привилегии для разных источников должны быть тщательно разработаны, чтобы избежать уязвимостей безопасности.
4. Происхождение из URI (Источник из URI)
Происхождение URI — это значение, вычисленное по следующему алгоритму:
1. Если URI не использует иерархический элемент в качестве центра именования (см. [RFC3986 #], раздел 3.2) или если URI не является абсолютным URI, то сгенерируйте новый глобальный уникальный идентификатор и верните это значение.
ПРИМЕЧАНИЕ. Выполнение этого алгоритма несколько раз для одного и того же URI может каждый раз давать разные значения. Обычно пользовательские агенты вычисляют источник, например, документа HTML один раз и используют его для последующих проверок безопасности, а не повторно вычисляют источник для каждой проверки безопасности.
2. Пусть uri-scheme будет компонентом схемы URI, преобразованным в нижний регистр.
3. Если реализация не поддерживает протокол, заданный uri-scheme, создайте новый глобальный уникальный идентификатор и верните это значение.
4. Если uri-scheme является «file», реализация МОЖЕТ вернуть значение, определяемое реализацией.
ПРИМЕЧАНИЕ: Исторически пользовательские агенты предоставляли контенту из файловой схемы огромные привилегии. Однако предоставление всем локальным файлам таких широких привилегий может привести к атакам с повышением привилегий. Некоторым пользовательским агентам удалось предоставить привилегии локальных файлов на основе каталога, но этот подход не получил широкого распространения. Другие пользовательские агенты используют глобальные уникальные идентификаторы для каждого URI файла, что является наиболее безопасным вариантом.
5. Пусть uri-host будет компонентом хоста URI, преобразованным в нижний регистр (с использованием сопоставления i; ascii-casemap, определенного в [RFC4790 #]).
ПРИМЕЧАНИЕ. В этом документе предполагается, что пользовательский агент выполняет обработку и проверку интернационализации доменных имен в приложениях (IDNA) при построении URI. В частности, в этом документе предполагается, что uri-host будет содержать только метки LDH, поскольку пользовательский агент уже преобразовал любые метки, отличные от ASCII, в соответствующие им A-метки (см. [RFC5890 #]). По этой причине политики безопасности на основе происхождения чувствительны к алгоритму IDNA, используемому пользовательским агентом. См. Раздел 8.4 для дальнейшего обсуждения.
6. Если в URI нет компонента порта:
1. Пусть uri-port будет портом по умолчанию для протокола, заданного uri-scheme.
В противном случае
2. Пусть uri-port будет компонентом порта в URI.
7. Вернуть тройку (uri-scheme, uri-host, uri-port).
5. Сравнение происхождений (источников)
Два источника «одинаковы» тогда и только тогда, когда они идентичны. В частности:
- Если два источника представляют собой тройки (схема / хост / порт), эти два источника будут одинаковыми, если и только если они имеют идентичные схемы, хосты и порты.
- Источник, который является глобально уникальным идентификатором, не может совпадать с источником, который является тройкой (схемы / хоста / порта).
Два URI имеют одинаковое происхождение, если их происхождение одинаково.
ПРИМЕЧАНИЕ. URI не обязательно должен быть самим собой по происхождению. Например, URI data [RFC2397 #] не совпадает с самим собой по происхождению, потому что URI данных не используют серверный орган именования и, следовательно, имеют глобально уникальные идентификаторы в качестве источников.
6. Сериализация происхождений (источников)
В этом разделе определяется, как сериализовать источник в строку Unicode [Unicode6] и строку ASCII [RFC20 #].
6.1. Юникод-сериализация происхождения
Юникод-сериализация источника — это значение, возвращаемое следующим алгоритмом:
1. Если источник не является тройкой — схема / хост / порт, то верните строку
null
(т.е. последовательность кодовых точек U+006E, U+0075, U+006C, U+006C) и прервите эти шаги.
2. В противном случае пусть result будет схемной частью исходной тройки.
3. Добавьте к результату строку «: //».
4. Добавьте каждый компонент основной части исходной тройки (преобразованный следующим образом) к результату, разделив их кодовыми точками U+002E FULL STOP («.»):
1. Если компонент является A-меткой, используйте вместо нее соответствующую U-метку (см. [RFC5890 #] и [RFC5891 #]).
2. В противном случае используйте компонент дословно.
5. Если часть порта исходной тройки отличается от порта по умолчанию для протокола, заданного частью схемы исходной тройки:
1. Добавьте к результату кодовую точку U + 003A COLON («:») и заданный порт по основанию десять.
6. Вернуть результат.
6.2. ASCII-сериализация происхождения
Ascii-сериализация источника — это значение, возвращаемое следующим алгоритмом:
1. Если источник не является тройкой схема / хост / порт, то верните строку
null
(т.е. последовательность кодовых точек U+006E, U+0075, U+006C, U+006C) и прервите эти шаги.
2. В противном случае пусть result будет схемной частью исходной тройки.
3. Добавьте к результату строку «: //».
4. Добавьте к результату ведущую часть исходной тройки.
5. Если часть порта исходной тройки отличается от порта по умолчанию для протокола, заданного частью схемы исходной тройки:
1. Добавьте к результату кодовую точку U + 003A COLON («:») и заданный порт по основанию десять.
6. Вернуть результат.
7. Поле заголовка происхождения HTTP
В этом разделе определяется поле заголовка HTTP Origin.
7.1. Синтаксис
Поле заголовка «Origin» имеет следующий синтаксис:
origin = "Origin:" OWS origin-list-or-null OWS origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list origin-list = serialized-origin *( SP serialized-origin ) serialized-origin = scheme "://" host [ ":" port ] ; <scheme>, <host>, <port> from RFC 3986
7.2. Семантика
При включении в HTTP-запрос поле заголовка Origin указывает источник (и), который «заставил» пользовательский агент выдать запрос, как определено API, который инициировал пользовательский агент для отправки запроса.
Например, рассмотрим пользовательский агент, который выполняет сценарии от имени источников. Если один из этих сценариев заставляет пользовательский агент выдать HTTP-запрос, пользовательский агент МОЖЕТ использовать поле заголовка Origin для информирования сервера о контексте безопасности, в котором сценарий выполнялся, когда он заставил пользовательский агент выдать запрос.
В некоторых случаях несколько источников приводят к тому, что пользовательские агенты отправляют HTTP-запрос. В таких случаях пользовательский агент МОЖЕТ перечислить все источники в поле заголовка Origin. Например, если HTTP-запрос был первоначально отправлен одним источником, но затем перенаправлен другим источником, пользовательский агент МОЖЕТ сообщить серверу, что два источника были задействованы в том, что пользовательский агент выдал запрос.
7.3. Требования к пользовательскому агенту
Пользовательский агент МОЖЕТ включать поле заголовка Origin в любой HTTP-запрос.
Пользовательский агент НЕ ДОЛЖЕН включать более одного поля заголовка Origin в любой HTTP-запрос.
Всякий раз, когда пользовательский агент выдает HTTP-запрос из «конфиденциального» контекста, пользовательский агент ДОЛЖЕН отправить значение «null» в поле заголовка Origin.
ПРИМЕЧАНИЕ: Этот документ не определяет понятие контекста, чувствительного к конфиденциальности. Приложения, которые генерируют HTTP-запросы, могут определять контексты как конфиденциальные, чтобы наложить ограничения на то, как пользовательские агенты генерируют поля заголовка Origin.
При создании поля заголовка Origin пользовательский агент ДОЛЖЕН соответствовать следующим требованиям:
- Каждое из производств сериализованного происхождения в грамматике ДОЛЖНО быть ascii-сериализацией источника.
- Никакие два последовательных порождения сериализованного происхождения в грамматике не могут быть идентичными. В частности, если пользовательский агент сгенерирует два последовательных сериализованных источника, пользовательский агент НЕ ДОЛЖЕН генерировать второй.
8. Соображения безопасности
Политика одного и того же происхождения — один из краеугольных камней безопасности для многих пользовательских агентов, включая веб-браузеры. Исторически некоторые пользовательские агенты пробовали другие модели безопасности, включая отслеживание заражения и предотвращение утечки, но в то время эти модели оказалось трудно реализовать (хотя в последнее время появился интерес к возрождению некоторых из этих идей).
Оценить безопасность политики одного и того же происхождения сложно, потому что сама концепция происхождения играет центральную роль в ландшафте безопасности. Само по себе условное происхождение — это просто единица изоляции, несовершенная, как и большинство универсальных понятий. Тем не менее, есть некоторые системные недостатки, которые обсуждаются ниже.
8.1. Опора на DNS
На практике политика одного и того же происхождения полагается на систему доменных имен (DNS) для обеспечения безопасности, поскольку многие часто используемые схемы URI, такие как http, используют органы именования на основе DNS. Если DNS частично или полностью скомпрометирован, политика одного и того же происхождения может не обеспечить свойства безопасности, требуемые приложениями.
Некоторые схемы URI, такие как https, более устойчивы к взлому DNS, поскольку пользовательские агенты используют другие механизмы, такие как сертификаты, для проверки источника контента, полученного из этих URI. Другие схемы URI, такие как схема URI с расширением chrome (см. Раздел 4.3 [CRX]), используют центр именования на основе открытого ключа и полностью защищены от взлома DNS.
Концепция веб-происхождения изолирует контент, полученный из различных схем URI; это важно для сдерживания последствий взлома DNS.
8.2. Расходящиеся единицы изоляции
Со временем ряд технологий сошлись на концепции веб-происхождения как удобной единицы изоляции. Однако многие технологии, используемые сегодня, например файлы cookie [RFC6265], предшествуют современной концепции веб-происхождения. Эти технологии часто имеют разные единицы изоляции, что приводит к уязвимостям.
Один из альтернативных вариантов — использовать в качестве единицы изоляции только «управляемый реестром» домен, а не полное доменное имя (например, «example.com» вместо «www.example.com»). Эта практика проблематична по ряду причин и НЕ РЕКОМЕНДУЕТСЯ:
1. Идея домена, контролируемого реестром, является результатом человеческой практики, связанной с DNS, а не свойством самой DNS. Например, во многих муниципалитетах Японии публичные реестры ведутся довольно глубоко в иерархии DNS. Существуют широко используемые «общедоступные списки суффиксов», но эти списки сложно поддерживать в актуальном состоянии, и они варьируются в зависимости от реализации.
2. Эта практика несовместима со схемами URI, в которых не используется центр именования на основе DNS. Например, если данная схема URI использует открытые ключи в качестве органов именования, понятие открытого ключа, контролируемого реестром, несколько непоследовательно. Хуже того, некоторые схемы URI, такие как nntp, используют точечное делегирование в направлении, противоположном DNS (например, alt.usenet.kooks), а другие используют DNS, но представляют метки в обратном порядке (например, com.example.www).
В лучшем случае использование «управляемых реестром» доменов зависит от схемы URI и реализации. В худшем случае различия между схемами URI и реализациями могут привести к уязвимостям.
8.3. Окружающее основание
При использовании политики одного и того же происхождения пользовательские агенты предоставляют полномочия контенту на основе его URI, а не на основе того, какие объекты контент может обозначать. Такое отделение обозначения от авторитета является примером внешнего авторитета и может привести к уязвимости.
Рассмотрим, например, межсайтовый скриптинг в HTML-документах. Если злоумышленник может внедрить содержимое сценария в HTML-документ, эти сценарии будут выполняться с полномочиями источника документа, что, возможно, позволит сценарию получить доступ к конфиденциальной информации, такой как медицинские записи пользователя. Однако, если бы полномочия сценария были ограничены теми объектами, которые сценарий мог обозначить, злоумышленник не получил бы никаких преимуществ, внедряя сценарий в HTML-документ, размещенный третьей стороной.
8.4. Зависимость IDNA и миграция
Свойства безопасности политики одного и того же происхождения могут в решающей степени зависеть от деталей алгоритма IDNA, используемого пользовательским агентом. В частности, пользовательский агент может отображать некоторые международные доменные имена (например, те, которые содержат символ U + 00DF) в различные представления ASCII в зависимости от того, использует ли пользовательский агент IDNA2003 [RFC3490 #] или IDNA2008 [RFC5890 #].
Переход от одного алгоритма IDNA к другому может перерисовать ряд границ безопасности, потенциально создавая новые границы безопасности или, что еще хуже, срывая границы безопасности между двумя взаимно недоверчивыми объектами. Изменение границ безопасности рискованно, потому что объединение двух взаимно недоверчивых объектов в один и тот же источник может позволить одному атаковать другого.
9. Соображения IANA
Постоянный реестр полей заголовка сообщения (см. [RFC3864 #]) был обновлен со следующей регистрацией:
Имя поля заголовка: Origin
Применимый протокол: http
Статус: стандарт
Автор / Контроллер изменений: IETF
Документ спецификации: эта спецификация (раздел 7)
10. Ссылки
10.1. Нормативные ссылки
[RFC20] Cerf, V., «ASCII format for network interchange», RFC 20, October 1969.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, «Internet Application Protocol Collation Registry», RFC 4790, March 2007.
[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.
[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.
[RFC5891] Klensin, J., «Internationalized Domain Names in Applications (IDNA): Protocol», RFC 5891, August 2010.
[Unicode6] The Unicode Consortium, «The Unicode Standard, Version 6.0.0», 2011, <http://www.unicode.org/versions/Unicode6.0.0/>.
10.2. Информативные ссылки
[BOFGO] Jackson, C. and A. Barth, «Beware of Finer-Grained Origins», 2008, <http://w2spconf.com/2008/papers/s2p1.pdf>.
[CORS] van Kesteren, A., «Cross-Origin Resource Sharing», W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/2010/WD-cors-20100727/>.
Latest version available at <http://www.w3.org/TR/cors/>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, «Protecting Browsers from Extension Vulnerabilities», 2010, <http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, «Robust Defenses for Cross-Site Request Forgery», 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[HTML] Hickson, I., «HTML5», W3C Working Draft WD-html5-20110525, May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
Latest version available at <http://www.w3.org/TR/html5/>.
[RFC2397] Masinter, L., «The «data» URL scheme», RFC 2397, August 1998.
[RFC2817] Khare, R. and S. Lawrence, «Upgrading to TLS Within HTTP/1.1», RFC 2817, May 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.
[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.
[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, April 2011.
[RFC6455] Fette, I. and A. Melnikov, «The WebSocket Protocol», RFC 6455, December 2011.
[SNIFF] Barth, A. and I. Hickson, «Media Type Sniffing», Work in Progress, May 2011.
Приложение A. Благодарности
Мы хотели бы поблагодарить Лукаса Адамски, Стивена Фаррелла, Мигеля А. Гарсиа, Тобиаса Гондрома, Яна Хиксона, Анн ван Кестерен, Джеффа Ходжеса, Коллина Джексона, Ларри Масинтера, Алексея Мельникова, Марка Ноттингема, Джулиана Решке, Питера Сен-Андре, Джонаса Сикинга, Сида Штамма, Даниэля Ведитца и Криса Вебера за ценные отзывы об этом документе.
Автор
Adam Barth
Google, Inc.
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/
