RFC 8615 | Хорошо известные унифицированные идентификаторы ресурсов (URI)

RFC 8615 | Хорошо известные унифицированные идентификаторы ресурсов (URI)

Аннотация

Это примечание определяет префикс пути для «общеизвестных местоположений», «/.well-known/», в выбранных схемах универсального идентификатора ресурса (URI).

При этом он устаревает RFC 5785 и обновляет схемы URI, определенные в RFC 7230, чтобы зарезервировать это пространство. Он также обновляет RFC 7595 для отслеживания схем URI, которые поддерживают известные URI в их реестре.

Скачать оригинальную версию документа на английском языке RFC 8615 PDF

 

Оглавление

1. Введение
2. Условные обозначения
3. Хорошо известные URI
3.1. Регистрация известных URI
4. Вопросы безопасности
4.1. Защита известных ресурсов
4.2. Взаимодействие с веб-браузером
4.3. Области применения
4.4. Скрытые возможности
5. Соображения IANA
5.1. Известный реестр URI
5.2. Реестр схем универсального идентификатора ресурса (URI)
6. Ссылки
6.1. Нормативные ссылки
6.2. Информационные ссылки
Приложение А. Часто задаваемые вопросы
Приложение B. Изменения по сравнению с RFC 5785
Адрес автора

 

1. Введение

Некоторые приложения в Интернете требуют обнаружения информации о источнике [RFC6454 #] (иногда называемой «метаданными всего сайта») перед выполнением запроса. Например, протокол исключения роботов (http://www.robotstxt.org) определяет способ для автоматизированных процессов получить разрешение на доступ к ресурсам; Точно так же Платформа настроек конфиденциальности [P3P] сообщает пользовательским агентам, как найти политику конфиденциальности перед взаимодействием с исходным сервером.

Хотя существует несколько способов доступа к метаданным для каждого ресурса (например, поля заголовка HTTP, PROPFIND в Web Distributed Authoring and Versioning (WebDAV) [RFC4918 #]), воспринимаемые издержки (либо с точки зрения задержки, воспринимаемой клиентом, и / или трудностей развертывания) связанные с ними часто исключают их использование в этих сценариях.

В то же время стало более популярным использование HTTP в качестве субстрата для не-веб-протоколов. Иногда такие протоколы нуждаются в способе найти один или несколько ресурсов на данном хосте.

Когда это происходит, одним из решений является определение «общеизвестного местоположения» для данных или услуг, связанных с источником в целом, чтобы его можно было легко найти. Однако этот подход имеет недостаток риска столкновений, как с другими такими назначенными «хорошо известными местоположениями», так и с ресурсами, которые источник создал (или желает создать). Кроме того, определение общеизвестных местоположений узурпирует контроль источника над его собственным пространством URI [RFC7320 #].

Для решения этих задач в этом меморандуме резервируется префикс пути в URI HTTP, HTTPS, WebSocket (WS) и Secure WebSocket (WSS) для этих «общеизвестных расположений», «/.well-known/». Будущие спецификации, которым необходимо определить ресурс для таких метаданных, могут зарегистрировать их использование, чтобы избежать коллизий и минимизировать воздействие на пространство URI источника.

Хорошо известные URI могут также использоваться с другими схемами URI, но только когда определения этих схем явно разрешают это.

 

2. Условные обозначения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

 

3. Хорошо известные URI

Хорошо известным URI является URI [RFC3986 #], компонент пути которого начинается с символов «/.well-known/», при условии, что схема явно определена для поддержки известных URI.

Например, если приложение регистрирует имя «example», соответствующий известный URI на «http://www.example.com/» будет «http://www.example.com/.well-known/example».

В этой спецификации обновляются схемы «http» [RFC7230] и «https» [RFC7230 #] для поддержки известных URI. Другие существующие схемы могут использовать соответствующий процесс для обновления своих определений; например, [RFC8307 #] делает это для схем «ws» и «wss«. Реестр «Схемы универсального идентификатора ресурса (URI)» отслеживает, какие схемы поддерживают хорошо известные URI; см. раздел 5.2.

Приложения, которые хотят чеканить новые хорошо известные URI, ДОЛЖНЫ зарегистрировать их, следуя процедурам, описанным в разделе 5.1, с учетом следующих требований.

Зарегистрированные имена ДОЛЖНЫ соответствовать продукции «segment-nz»в [RFC3986 #]. Это означает, что они не могут содержать символ косой черты «/».

Зарегистрированные имена для конкретного приложения ДОЛЖНЫ быть соответственно точными; «сидеть на корточках» (squatting) на общих условиях не рекомендуется. Например, если Example приложения хочет иметь хорошо известное местоположение для метаданных, подходящее зарегистрированное имя может быть «example-metadata» или даже «example.com-metadata», а не «metadata».

Как минимум, регистрация будет ссылаться на спецификацию, которая определяет формат и связанный тип (типы) мультимедиа, которые должны быть получены путем разыменования хорошо известного URI, наряду со схемой (схемами) URI, с которой можно использовать известный URI. Если никакие схемы URI не указаны явно, подразумеваются «http» и «https».

Как правило, приложения будут использовать порт по умолчанию для данной схемы; если используется альтернативный порт, он ДОЛЖЕН быть явно задан соответствующим приложением.

Регистрации МОГУТ также содержать дополнительную информацию, такую как синтаксис дополнительных «компонентов пути«, «строки запросов» и/или «идентификаторы фрагментов«, которые должны быть добавлены к общеизвестному URI, или специфичные для протокола подробности (например, обработка метода HTTP [RFC7231 #]).

Обратите внимание, что эта спецификация не определяет ни то, как определить имя хоста, которое будет использоваться для поиска общеизвестного URI для конкретного приложения, ни область метаданных, обнаруженных путем разыменования общеизвестного URI; оба должны быть определены самим приложением.

Кроме того, эта спецификация не определяет формат или тип мультимедиа для ресурса, расположенного в «/.well-known/», и клиенты не должны ожидать, что ресурс будет существовать в этом месте.

Хорошо известные URI коренятся в верхней части иерархии пути; они не известны по определению в других частях пути. Например, «/.well-known/example» является хорошо известным URI, тогда как «/foo/.well-known/example» — нет.

Смотри также Раздел 4 для соображений безопасности относительно известных мест.

 

3.1. Регистрация известных URI

Реестр «Известных URI» находится по адресу <https://www.iana.org/assignments/well-known-uris/>. Запросы на регистрацию можно сделать, следуя расположенным там инструкциям, или отправив электронное письмо в список рассылки <wellknown-uri-review@ietf.org>.

Заявки на регистрацию состоят как минимум из следующей информации:

  • URI suffix
  • Change controller
  • Specification document(s)
  • Status
  • Related information

Суффикс URI (URI suffix): имя, запрошенное для известного URI, относительно «/.well-known/»; например, «example».

Контроллер изменений (Change controller): для RFC отслеживания стандартов, укажите «IETF». Для других укажите имя ответственной стороны. Другие детали (например, адрес электронной почты, URI домашней страницы) также могут быть включены.

Документ (ы) спецификации (Specification document(s)): Ссылка на документ, который определяет поле, предпочтительно, включая URI, который можно использовать для получения копии документа. Указание соответствующих разделов также может быть включено, но не обязательно.

Статус (Status): один из «постоянных» или «временных». Смотрите руководство ниже.

Информация, связанная с данной (Related information): При необходимости ссылки на дополнительные документы, содержащие дополнительную соответствующую информацию.


Общие требования к зарегистрированным значениям описаны в разделе 3.

Значения, определенные в RFC отслеживания стандартов и других открытых стандартах (в смысле [RFC2026 #], раздел 7.1.1), имеют статус «постоянный» (permanent). Другие значения также могут быть зарегистрированы как постоянные, если эксперты обнаружат, что они используются, по согласованию с сообществом. Другие значения должны быть зарегистрированы как «предварительные» (provisional).

Предварительные записи могут быть удалены экспертами, если — по согласованию с сообществом — эксперты обнаружат, что они не используются. Эксперты могут изменить статус предварительной записи на постоянный; при этом эксперты должны учитывать, насколько широко используется ценность, и предварительно проконсультироваться с сообществом.

Обратите внимание, что термин «проконсультироваться с сообществом» (consult the community) относится к тем, кто отвечает за рассматриваемые схемы URI. Как правило, это происходит в списках рассылки соответствующей Рабочей группы (групп) (возможно, заключенных) или на <art@ietf.org>, если такого списка не существует.

Хорошо известные URI могут быть зарегистрированы третьими лицами (включая эксперта (ов)), если эксперт (ы) определит, что незарегистрированный известный URI широко используется и вряд ли будет своевременно зарегистрирован в противном случае. Такие регистрации все еще подчиняются определенным требованиям, включая необходимость ссылки на спецификацию.

 

4. Вопросы безопасности

Прикладные программы, обрабатывающие новые известные URI, а также администраторы, развертывающие их, должны будут рассмотреть несколько вопросов, связанных с безопасностью, включая (но не ограничиваясь этим) уязвимость конфиденциальных данных, атаки типа «отказ в обслуживании» (denial-of-service) (в дополнение к обычным проблемам с нагрузкой). ), аутентификация сервера и клиента, уязвимость к атакам повторного связывания DNS и атакам, когда ограниченный доступ к серверу дает возможность влиять на то, как обслуживаются известные URI.

[RFC3552 #] содержит некоторые примеры потенциальных соображений безопасности, которые могут иметь отношение к протоколам приложений и администраторам, внедряющим их.

4.1. Защита известных ресурсов

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

4.2. Взаимодействие с веб-браузером

Приложения, использующие известные URI для URL «http» или «https», должны знать, что общеизвестные ресурсы будут доступны для веб-браузеров, и, следовательно, могут манипулировать контентом, полученным из других частей этого источника. Если злоумышленник сможет внедрить контент (например, с помощью уязвимости межсайтового скриптинга), он сможет сделать потенциально произвольные запросы к общеизвестному ресурсу.

HTTP и HTTPS также используют источники в качестве границы безопасности для многих других механизмов, включая (но не ограничиваясь ими) файлы cookie [RFC6265 #], веб-хранилище [WEBSTORAGE] и различные возможности.

Приложение, которое определяет известные местоположения, не должно предполагать, что оно имеет единственный доступ к этим механизмам или что это единственное приложение, использующее источник. В зависимости от характера приложения меры по смягчению могут включать:

  • Шифрование конфиденциальной информации
  • Предоставление гибкости в использовании идентификаторов (например, имен файлов cookie), чтобы избежать конфликтов с другими приложениями.
  • Использование флага «HttpOnly» на файлах cookie, чтобы гарантировать, что файлы cookie не доступны языкам сценариев браузера [RFC6265]
  • Использование параметра «Path» в файлах cookie, чтобы гарантировать, что они недоступны для других частей источника [RFC6265]
  • Использование X-Content-Type-Options: nosniff [FETCH], чтобы гарантировать, что контент, находящийся под контролем злоумышленника, не может быть преобразован в форму, которая интерпретируется как активный контент веб-браузером

Другие хорошие практики включают в себя:

  • Использование специфического для приложения типа носителя в поле заголовка Content-Type и требование сбоя клиентов, если оно не используется
  • Использование Content-Security-Policy [CSP] для ограничения возможностей активного контента (например, HTML [HTML5]), тем самым смягчая атаки межсайтового скриптинга.
  • Использование Referrer-Policy [REFERRER-POLICY] для предотвращения утечки конфиденциальных данных в URL в поле заголовка запроса «Referer»
  • Избегать использования сжатия любой конфиденциальной информации (например, токенов аутентификации, паролей), поскольку среда сценариев, предлагаемая веб-браузерами, позволяет злоумышленнику многократно проверять пространство сжатия; если злоумышленник имеет доступ к пути связи, он может использовать эту возможность для восстановления этой информации.

4.3. Области применения

В этой заметке не указывается область применения информации, полученной из известного URI, и не указывается, как найти известный URI для конкретного приложения.

Отдельные приложения, использующие этот механизм, должны определять оба аспекта; если это не указано, проблемы безопасности могут возникнуть из-за отклонений в реализации и путаницы в границах между приложениями.

Применение метаданных, обнаруженных в общеизвестном URI, к ресурсам, отличным от тех, которые расположены в одном источнике, создает риск административных и проблем безопасности. Например, разрешив «https://example.com/.well-known/example» применить политику к «https://department.example.com», «https://www.example.com» или даже «https://www.example.com:8000» предполагает связь между хостами, где их может и не быть, что дает контроль потенциальному злоумышленнику.

Аналогичным образом, указание того, что известный URI на конкретном имени хоста должен использоваться для начальной загрузки протокола, может вызвать большое количество нежелательных запросов. Например, если известный HTTPS URI используется для поиска политики в отношении отдельной службы, такой как электронная почта, это может привести к потоку запросов к веб-серверам, даже если они не реализуют известный URI. Такие нежелательные запросы могут напоминать атаку типа «отказ в обслуживании» (denial-of-service).

4.4. Скрытые возможности

Приложения, использующие известные местоположения, должны учитывать, что некоторые администраторы серверов могут не знать об их существовании (особенно в операционных системах, которые скрывают каталоги, имена которых начинаются с точки «.»). Это означает, что если у злоумышленника есть доступ на запись в хорошо известный каталог, он сможет контролировать его содержимое, возможно, даже если администратор этого не осознает.

 

5. Соображения IANA

5.1. Известный реестр URI

Эта спецификация обновляет процедуры регистрации для реестра «Хорошо известный URI», впервые определенного в [RFC5785 #]; см. раздел 3.1.

Известные URI регистрируются по рекомендации одного или нескольких экспертов с необходимой спецификацией (с использованием терминологии из [RFC8126 #]).

Основными соображениями экспертов при оценке заявок на регистрацию являются:

  • Соответствие требованиям раздела 3
  • Наличие и стабильность уточняющего документа
  • Соображения, изложенные в разделе 4

IANA будет направлять отправителей любых входящих запросов реестра в этот документ и, если определено, процессы, установленные экспертом (ами); как правило, это будет означать ссылку на веб-страницу реестра.

Согласно этому документу IANA имеет:

  • Обновлена процедура регистрации до Требуемой спецификации.
  • Добавлен столбец «Статус» (Status) в реестр и помечены все существующие регистрации как «постоянные» (permanent).

5.2. Реестр схем универсального идентификатора ресурса (URI)

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

Если схема URI была явно указана для использования хорошо известных URI согласно Разделу 3, значение изменяется на ссылку на эту спецификацию. Начальные значения, не равные «-», приведены в таблице 1.

Схема URI Хорошо известная поддержка URI
coap [RFC7252]
coap+tcp [RFC8323]
coap+ws [RFC8323]
coaps [RFC7252]
coaps+tcp [RFC8323]
coaps+ws [RFC8323]
http [RFC8615]
https [RFC8615]
ws [RFC8307]
wss [RFC8307]

Таблица 1: строки в реестре схемы URI с непустым новым столбцом

 

6. Ссылки

 

6.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC6454] Barth, A., «The Web Origin Concept», RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

 

6.2. Информационные ссылки

[CSP] West, M., «Content Security Policy Level 3», World Wide Web Consortium WD WD-CSP3-20160913, September 2016, <https://www.w3.org/TR/2016/WD-CSP3-20160913>.

[FETCH] WHATWG, «Fetch — Living Standard», <https://fetch.spec.whatwg.org>.

[HTML5] WHATWG, «HTML — Living Standard», <https://html.spec.whatwg.org>.

[P3P] Marchiori, M., «The Platform for Privacy Preferences 1.0 (P3P1.0) Specification», World Wide Web Consortium Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/2002/REC-P3P-20020416>.

[REFERRER-POLICY] Eisinger, J. and E. Stark, «Referrer Policy», World Wide Web Consortium CR CR-referrer-policy-20170126, January 2017, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[RFC3552] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC4918] Dusseault, L., Ed., «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)», RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, «Defining Well-Known Uniform Resource Identifiers (URIs)», RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.

[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, «The Constrained Application Protocol (CoAP)», RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7320] Nottingham, M., «URI Design and Ownership», BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>.

[RFC8307] Bormann, C., «Well-Known URIs for the WebSocket Protocol», RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.

[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., «CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets», RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.

[WEBSTORAGE] Hickson, I., «Web Storage (Second Edition)», World Wide Web Consortium Recommendation REC-webstorage-20160419,
April 2016, <http://www.w3.org/TR/2016/REC-webstorage-20160419>.

Приложение А. Часто задаваемые вопросы

Разве известные сайты не вредны для Интернета?

Они есть, но по разным причинам — как техническим, так и социальным — иногда они необходимы. Этот меморандум определяет для них «песочницу», чтобы снизить риск столкновения и минимизировать влияние на ранее существовавшие URI на сайтах.

Почему «/.well-known?»

Оно короткое, описательное и, согласно поисковым индексам, широко не используется.

Как это влияет на существующие механизмы, такие как P3P и robots.txt?

Нет, пока они не решат использовать этот механизм.

Почему не определены определенные местоположения для каждого каталога?

Разрешение каждому сегменту пути URI иметь хорошо известное местоположение (например, «/images/.well-known/») увеличило бы риск столкновения с ранее существующим URI на сайте, и, как правило, эти решения не масштабируются должным образом потому что они слишком «болтливы» (chatty).

Приложение B. Изменения по сравнению с RFC 5785

  • Разрешенные не-Web известные места
  • Скорректированные инструкции IANA
  • Обновленные ссылки
  • Сделаны различные другие уточнения
  • Отслеживаемые поддерживающие схемы в реестре «Схемы универсального идентификатора ресурса (URI)»

Адрес автора

Mark Nottingham
Email: mnot@mnot.net
URI: https://www.mnot.net/