Русская Википедия:File (схема URI)

Материал из Онлайн справочника
Версия от 16:43, 14 июля 2023; EducationBot (обсуждение | вклад) (Новая страница: «{{Русская Википедия/Панель перехода}} Схема URI '''file''' — это схема URI, документированная в RFC 8089, RFC 1630, RFC 1738 и RFC 3986, предназначенная для того, чтобы адресовать файлы на локальном компьютере или в локальной сети, по их прямому пути на диске, в сетевой папке...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Перейти к навигацииПерейти к поиску

Схема URI file — это схема URI, документированная в RFC 8089, RFC 1630, RFC 1738 и RFC 3986, предназначенная для того, чтобы адресовать файлы на локальном компьютере или в локальной сети, по их прямому пути на диске, в сетевой папке или, в отдельных случаях, на ftp-сервере. Схема URI file зарегистрирована в реестре схем URI IANA[1] и входит в раздел «Перманентные схемы URI».

О схеме

Схема file является одной из старейших схем URI. Она была воплощена в программном обеспечении ещё на заре существования Интернета. WorldWideWeb, первый веб-браузер, созданный в 1991 г. Тимом Бернерсом-Ли, изобретателем Всемирной паутины, поддерживал схему file. Спецификация RFC 1630, в которой она была впервые документирована, была написана также Тимом Бернерсом-Ли в июне 1994 г., ещё до создания консорциума W3C, и является одной из старейших спецификаций Интернета.

До введения схемы ftp схема file использовалась для указания ссылок на файлы, находящиеся на ftp-серверах. Сам Тим Бернерс-Ли предложил использование схемы file в URL для ссылок на файлы, доступные по ftp-протоколу, и сам же применял такие ссылки в разделе «Список литературы» в своих публикациях[2]. Браузер Lynx, один из старейших браузеров, доживший до наших дней, до нынешних дней сохранил такую интерпретацию схемы file[3].

В отличие от большинства известных схем (например, http, nfs, sip, telnet и т. д.), схема file не является протоколом. Об этом явно сказано в RFC 1738: «Особенностью этой схемы является то, что она не указывает интернет-протокол или метод доступа к файлу, поэтому её использование в сетевых протоколах между хостами ограничено»[4]. Схема file просто указывает путь к файлу в виде URL (или URI) на одном конкретном компьютере. Там же сказано, что «эта схема, в отличие от большинства других схем URL, не определяет ресурс, который общедоступен через Интернет».

Схема file поддерживается всеми популярными браузерами, во всех операционных системах, хотя и базируется на очень старом стандарте, описывающем формат URL, а собственного пока не имеет. Но из-за указанных выше особенностей её использование ограничено. Она работает в адресной строке, но в HTML-разметке веб-сайтов эта схема практически не встречается. В настоящее время разработана новая схема app, которая должна прийти на замену file. Схема app описана в рекомендации W3C от 16 мая 2013 г.[5]

Формат

URL со схемой file имеет формат[4]:

file://<host>/<path>

где host — это полное имя домена в системе, в которой доступен путь path, а path — это иерархический путь к каталогу, имеющий формат каталог/каталог/.../имя_файла. Если host пропущен, используется значение по умолчанию «localhost», машина, на которой обрабатывается URL. До 2005 года в стандарте было требование, такое, что если хост опускается, то соответствующую косую черту или двойную косую черту опускать нельзя («file:///foo.txt» сработает, но «file://foo.txt» — нет, хотя некоторые парсеры способны были обрабатывать данный случай). RFC 3986, вышедшее в 2005 г., отменило это требование. Согласно RFC 3986, при опускании authority (в данном случае это эквивалент host) опускается также и двойная косая черта (//).

Значение косой черты

Косая черта (/), в зависимости от позиции в URI, имеет разное значение.

  1. Двойная косая черта (//) после схемы file: — это часть синтаксиса URL, является обязательной при указании authority (поле host выступает в качестве authority).
  2. Косая черта между host и path — это также часть синтаксиса URL, хотя может являться составной частью path на Unix-системах или отсутствовать, если указанный путь относительный, т. е. начинается с «.» или «..».
  3. Остальные косые черты разделяют названия каталогов в поле path в иерархии каталогов локального компьютера. В данном случае косая черта — это независимый от системы способ отделения частей пути.

Другие компоненты URL

Компоненты логин (username), пароль (password) и порт (port) не используются в URL со схемой file. Но при этом могут использоваться компоненты параметры (query string) и якорь (fragment identifier)[6] самим приложением, отображающим содержимое данного file URL. Например, скрипт внутри HTML-документа может прочитать параметры, а якорь может использоваться стандартным образом для навигации по документу.

Допустимые символы и их кодирование

File URL отличается по набору символов и от традиционных URL и от путей к файлу в файловых системах. Так как пути в файловых системах могут содержать символы, зарезервированные в URL для служебных целей ('#', '%' и др.), то такие символы (ранее также и пробел ' ') при конвертации пути в file URL кодируются. Но при этом, в отличие от URL, в file URL рекомендуется использовать символы иностранных алфавитов (то есть не из таблицы US-ASCII) как есть, то есть без URL-кодирования[6]. Вызвано это тем, что URL-кодированные октеты в file URL рассматриваются как байты в текущей кодовой странице пользователя, то есть значение URL будет меняться в зависимости от локали, в которой просматривается документ[6].

Примеры

UNIX и UNIX-подобные операционные системы

4 примера на Unix, указывающие на один и тот же файл /etc/fstab:

file://localhost/etc/fstab
file:///etc/fstab
file:///etc/./fstab
file:///etc/../etc/fstab

Пример ссылки на файл rfc959.txt, который находится на ftp-сервере nnsc.nsf.net[Прим. 1]:

file://nnsc.nsf.net/rfc/rfc959.txt

Mac OS

2 примера на Mac OS, указывающие на один и тот же файл /var/log/system.log:

file://localhost/var/log/system.log
file:///var/log/system.log

Windows

Примеры путей, поддерживаемых приложениями Windows, указывающие на файл c:\WINDOWS\clock.avi:

file://localhost/c|/WINDOWS/clock.avi
file:///c|/WINDOWS/clock.avi
file://localhost/c:/WINDOWS/clock.avi
file:///c:/WINDOWS/clock.avi

Пример пути к файлу start.swf, расположенному в сетевой папке products на компьютере с сетевым именем applib[7]:

file://applib/products/a-b/abc_9/4148.920a/media/start.swf

Пример file URI с %-кодированными символами и с символом Unicode[7] (в Internet Explorer 6-й и 7-й версии пример с %20 может не работать[8]):

file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc
file:///C:/exampleㄓ.txt

Схема file и браузеры

Браузер Поддержка схемы file (localhost) Пустой host (file:///) Сетевой host Буква диска в пути (C:)[Прим. т. 1] Обзор папок URL-кодированные символы file-ссылки в html
Google Chrome
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Internet Explorer
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Нет
Да
Да
Да
Да
Konqueror
Да
Да
Да
Да
?
Неизвестно
Неизвестно
Да
Да
Да
Да
Да
Да
Lynx
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Mozilla Firefox
Да
Да
Да
Да
Шаблон:ЧастичноШаблон:Ref+
Да
Да
Да
Да
Да
Да
Да
Да
Opera
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Safari
Да
Да
? ?
Неизвестно
Неизвестно
Нет
Нет
? ?
Яндекс.Браузер
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Примечания к таблице

Шаблон:Примечания

Схема file в Windows

Схема URI file начала поддерживаться в Windows изначально, т.е. с появлением поддержки URI[Прим. 2] вообще, а конкретно — с выходом обозревателя Internet Explorer 1[9]. Первая версия Internet Explorer разрабатывалась в 1995 г., когда стандарта URL ещё не было, и схему file можно было трактовать по-разному, что и произошло с браузером. Разные его модули по-разному обрабатывали схему file. После переработки эта ситуация была устранена. Был создан shlwapi.dll, в который поместили весь код для работы с URL. В ходе переделки были согласованы две формы схемы file: одна по стандарту URL, другая — старая форма, пришедшая из времен DOS. Сотрудники Microsoft называли её legacy file URL (устаревший file URL). Примеры устаревших file URL:

Путь к файлу:         c:\windows\My Documents 100%20\foo.txt 
Устаревший file URL:  file://c:\windows\My Documents 100%20\foo.txt 
Стандартный file URL: file:///c:/windows/My%20Documents%20100%2520/foo.txt

Путь к файлу:         \\server\share\My Documents 100%20\foo.txt 
Устаревший file URL:  file://\\server\share\My Documents 100%20\foo.txt
Стандартный file URL: file://server/share/My%20Documents%20100%2520/foo.txt 

Новая dll умеет правильно обрабатывать и новые, и старые file URL, поэтому её функции PathCreateFromUrl() и UrlCreateFromPath() рекомендуется использовать для конвертации между путями Windows и file URL[6][10].

Кроме данных функций, была создана функция CreateURLMoniker() в urlmon.dll (начиная с Internet Explorer 3), предназначенная для того, чтобы сконвертировать строковый URI в объект, с помощью которого можно получить данные, адресованные данным URI (моникер). Но и эта функция вызывала некоторые проблемы с конвертацией file URI[10], в результате чего была добавлена и рекомендована для использования новая функция CreateURLMonikerEx() (начиная с Internet Explorer 5.5), в которой все эти проблемы были исправлены. С выходом Internet Explorer 7 была добавлена ещё одна функция CreateURLMonikerEx2(), которая поддерживает относительные пути.

Проблемы безопасности

С появлением и распространением в браузерах поддержки скриптовых языков, таких, как JavaScript, был обнаружен ряд уязвимостей, связанных с использованием схемы file. В связи с этим разработчики браузеров ввели ряд встроенных ограничений в браузерах на использование file URL.

Основные уязвимости браузеров, связанные с file URI

Ссылки со схемой file в документах HTML, загруженных по протоколу HTTP, не работают практически во всех популярных браузерах: Internet Explorer (начиная с версии 6 SP1)[11]Шаблон:Ref+, Mozilla Firefox[12][13], Chromium[14] и Google Chrome[15], SafariШаблон:Нет АИ, OperaШаблон:Нет АИ. При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также контент по ссылке file URL не загружается во фреймы документа HTML, загруженного по HTTP URL. Такая политика безопасности была введена в связи с тем, что такие ссылки вызывают ряд уязвимостей:

  • HTML-документ, размещенный на сайте злоумышленника, может подгрузить файлы на компьютере пользователя при помощи ссылок file URL, и затем отправить их на сервер, находящийся под контролем этого злоумышленника. Злоумышленник получает доступ к конфиденциальным данным пользователя;
  • Многие браузеры и плагины к ним держат свои временные файлы и кэш в предсказуемых местах на диске. Атакующий может вначале разместить файл HTML в одном из этих мест во время обычной работы браузера (злоумышленник на контролируемом сайте может попросить сохранить веб-страницу на диск или прислать её в архиве на электронную почту), и затем попробовать открыть его, вызвав через специально подготовленный file URL. HTML-документ, открытый локально (через file URL), имеет больше привилегий, чем удалённый, и может как получить доступ к конфиденциальным данным пользователя, так и совершать другие нежелательные действия. Этот метод атаки также называют «file-URL-to-file-URL scripting»[16]. Кроме того, пользователь может сам открыть вредный html-документ локально у себя на компьютере.
  • Локально открытый html-файл может загрузить удалённую веб-страницу в iframe (так как локальные файлы на компьютере не подпадают под Правило ограничения домена, действующее только для сайтов), например, сайт электронной почты, где пользователь уже залогинен, и получить таким образом доступ к конфиденциальным данным пользователя, находящимся в интернете.

Для борьбы со второй уязвимостью была также введена политика под названием «Правило ограничения домена» (same origin policy), аналогичная одноимённой политике, введённой ранее для сайтов http-зоны. Mozilla Firefox, который ввёл эту политику в версии браузера 3 (движок Gecko 1.9) в 2007 г., был в этом одним из первых (на обсуждение и реализацию этой политики у разработчиков Firefox ушло 3 года[17]). Согласно этому правилу, файл может читать другой файл, только если родительский каталог исходного файла является надкаталогом для целевого файла[18]. Microsoft ранее поступил жёстче и вообще отключил исполнение Javascript при открытии любых локальных файлов, начиная с Internet Explorer 6 в Windows XP SP2, добавив пользователям возможность выполнить сценарий выбором специальной команды во всплывающем меню. Safari 3.2 не даёт пользователю возможности открыть локальные file URL из каких-либо других источников, кроме как из адресной строки. Opera 9.6 не позволяет локальным html-страницам загружать удалённый контент (но это не защищает от возможности доступа злоумышленника к данным на компьютере). Chromium (и зависящий от него Google Chrome) реализовал политику, аналогичную политике Opera[19] и взял также на рассмотрение политику Firefox, но позже реализовал ещё более жёсткую политику[20], запретив обращения к file URL для скриптов в локальных веб-страницах вообще (позже было решено ослабить эту политику).

В результате ввода таких ограничений появилось много жалоб, так как это препятствовало работе локальных сайтов и веб-справочников, которые широко применяются во многих корпоративных и локальных сетях, в дистрибутивах на CD, в приложениях к электронной почте, а также используются веб-разработчиками для отладки сайтов. Например, в Mozilla по этому поводу было заведено несколько десятков багов-дубликатов[13]. Поэтому в браузерах была поддержана возможность обхода, отключения или конфигурирования этой политики, а также появились статьи, подсказывающие, как это сделать. Так, в Internet Explorer эта политика настраивается параметром «Websites in less privileged web content zone can navigate into this zone» " в настройках зоны «My computer» или другой. Также этот запрет обходится добавлением веб-сайтов, не вызывающих никаких опасений, в зону «Надежные узлы» Internet ExplorerШаблон:Нет АИ. В Mozilla Firefox этот запрет обходится с помощью расширений LocalLink, Local Filesystem Links, IE Tab; или специальной настройкой политики безопасности (для группы сайтов создаётся специальная зона со своими специфическими настройками безопасности)[12]. В Google Chrome начиная с версии 7 этот запрет можно обойти, запустив браузер с флагом --allow-file-access-from-files или используя расширение LocalLinks. В Chromium также, как следствие многочисленных жалоб, решили ослабить политику «Правило ограничения домена» для file URL[21].

Ограничения политики безопасности в браузерах

Основные ограничения политики безопасности в браузерах отражены в таблицеШаблон:Ref+.

Описание теста MSIE6Шаблон:Ref+ MSIE7Шаблон:Ref+ MSIE8Шаблон:Ref+ FF2Шаблон:Ref+ FF3Шаблон:Ref+ SafariШаблон:Ref+ OperaШаблон:Ref+ ChromeШаблон:Ref+
Имеют ли локальные HTML доступ к несвязанным локальным файлам через DOM?
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Да
Да
Нет
Нет
Имеют ли локальные HTML доступ к несвязанным локальным файлам через XMLHttpRequest?
Нет
Нет
Нет
Нет
Нет
Нет
Да
Да
Нет
Нет
Нет
Нет
Да
Да
Нет
Нет
Имеют ли локальные HTML доступ к сайтам в Интернет через XMLHttpRequest?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Работает ли document.cookie с file URL?
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Нет
Разрешается ли загружать тег <IMG> с file URI?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешается ли загружать тег <SCRIPT> с file URI?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешается ли загружать тег <IFRAME> с file URI?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешается ли загружать тег <EMBED> с file URI?
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешается ли загружать тег <APPLET> с file URI?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Да
Да
Нет
Нет
Да
Да
Можно ли загружать стили (stylesheet) через file URI?
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешены ли редиректы (Location redirection) через file URI?
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Разрешены ли редиректы (Refresh redirection) через file URI?
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Примечания к таблице

Шаблон:Примечания

Атака XXE

Атака XXE (Шаблон:Lang-en) — одна из известнейших уязвимостей в Интернете. Этот класс уязвимостей зарегистрирован в крупнейших каталогах уязвимостей: Common Weakness Enumeration[22] и CAPEC[23]. Суть атаки в следующем. Есть сервисы, поддерживающие протоколы SOAP и XML-RPC, которые принимают входные данные в виде XML-документа. Стандарт XML-документа поддерживает включение секции DTD, а секции DTD, в свою очередь, могут подключать к документу дополнительные компоненты, так называемые внешние сущности (Шаблон:Lang-en)[24]. Внешние сущности являются отдельными файлами и задаются с помощью ключевого слова SYSTEM и URI. Если XML-парсер невалидирующий, он может просто загрузить внешнюю сущность и подключить к содержимому XML-документа. Злоумышленник может подставить в URI внешней сущности file URI, указывающий на аппаратное устройство ЭВМ или на локальный файл в системе. Сервер попытается прочитать файл по указанному URI и включить его содержимое в XML. При использовании такого механизма возможны следующие виды атак[25]:

  • DoS-атака (отказ в обслуживании) сервера, посредством обращения к устройству системы, такому, как /dev/urandom или;
  • получение несанкционированного доступа к закрытым файлам сервера, например, /etc/passwd или c:/winnt/win.ini;
  • сканирование TCP-портов (даже в обход фаервола);
  • DoS-атака других систем (если парсер позволяет устанавливать TCP-соединения в другие системы)
  • кража материалов NTLM-аутентификации, инициированная через UNC-обращение к системе, находящейся под контролем злоумышленника;
  • сценарий «судный день»: широко развернутое и имеющее большое количество подключений серверное приложение, подверженное этой уязвимости, может использоваться для DDoS-атаки (распределённый отказ от обслуживания).

Уязвимость XXE в сообществе http://xml.org (сайт некоммерческой организации OWASP) начали обсуждать ещё с 2001 года[26], но это были лишь теоретические размышления о возможности атаки такого вида. Первый, кто обратил внимание общественности на эту уязвимость, был Грегори Стейк (Шаблон:Lang-en)[27]. В 2002 году он отправил security advisory (инструкция по безопасности) на www.securityfocus.com[25], в котором подробно описал уязвимость и дал ей название атака XXE (Шаблон:Lang-en).

Атаке XXE были подвержены многие продукты. Во всех крупнейших базах данных уязвимостей программного обеспечения можно найти программные продукты, уязвимые для атак XXE: в National Vulnerability Database[28], в Common Vulnerabilities and Exposures[29], в Open Source Vulnerability Database[30]. Уязвимость для «атак XXE» была обнаружена в таких известных продуктах, как JDK и JRE (6-я версия, 3-е обновление)[29][31], WebKit и сделанный на его основе браузер Safari (3-я версия)[32][33], Spring Framework[34], CakePHP[35], Adobe Reader (7-я версия)[36], Zend Framework[37], Squiz[38] и др.

Стандартизация и спецификации

Схема URI file впервые была описана в июне 1994 г. в информационном RFC 1630 («Universal Resource Identifiers in WWW»). В декабре того же года она была стандартизирована в RFC 1738 (Uniform Resource Locators (URL)). RFC 1738 описывает общий формат URL и на данный момент уже является устаревшим, за исключением двух секций, в которых описываются схемы file и ftp. Новый RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), вышедший в 2005, вобрал в себя RFC 1738, внёс небольшие изменения, но он не описывал отдельные схемы. К тому времени почти все схемы из раздела перманентных получили свой собственный отдельный стандарт. Старый RFC 1738 лишь утверждал формат схемы, но не определял правил по применению этой схемы и конвертации локального пути в URI и обратно. Назревала необходимость стандартизировать схему file, а также ряд других нестандартизированных схем.

В 2004 г. Пол Хоффман, являющийся участником IETF ещё с ранних 1990-х, начал процесс стандартизации схемы file. В течение июня он написал отдельные спецификации для схем file, ftp, gopher, news и nntp, prospero и telnet, и 17 июня 2004 они были опубликованы на сайте ietf.org, а 19 июня он объявил об этом в списке рассылки[39]. Первая ревизия стандарта схемы file имела название «The file URI Scheme»[40]. 19 июня Пол Хоффман объявил о Началось активное обсуждение черновика. Сообщество IETF высказало много замечаний, и вскоре вышла вторая ревизия[41], потом третья[42] и четвертая[43]. Но консенсус так и не был достигнут. Для продолжения работы над стандартом Майк Браун создал специальный вики-сайт https://offset.skew.org/wiki/URI/File_scheme, где некоторое время велась работа по сбору информации, касающейся схемы file. Но вскоре эта деятельность затихла, а стандарт так и не был принят.

В 2013 г. Мэтью Кервин делает новую попытку стандартизировать схему file. В июне 2013 была опубликована первая ревизия черновика[44], началось обсуждение черновика, и в течение июня-сентября вышло ещё 8 ревизий. Последняя (№8, т.е. девятая[Прим. 3]) ревизия черновика была опубликована 18 сентября 2013[45]

Примечания

Комментарии

Шаблон:Примечания

Источники

Шаблон:Примечания

См. также

Ссылки

Шаблон:URI scheme


Ошибка цитирования Для существующих тегов <ref> группы «Прим.» не найдено соответствующего тега <references group="Прим."/>
Ошибка цитирования Для существующих тегов <ref> группы «Прим. т.» не найдено соответствующего тега <references group="Прим. т."/>