Схема 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 в иерархии каталогов локального компьютера. В данном случае косая черта — это независимый от системы способ отделения частей пути.

Компоненты логин (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].

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

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

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

Примеры путей, поддерживаемых приложениями 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

Примечания к таблице

Схема URI file начала поддерживаться в Windows изначально, т.е. с появлением поддержки URI^{[Прим. 2]} вообще, а конкретно — с выходом обозревателя Internet Explorer 1^[10]. Первая версия 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][11].

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

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

Ссылки со схемой file в документах HTML, загруженных по протоколу HTTP, не работают практически во всех популярных браузерах: Internet Explorer (начиная с версии 6 SP1)^{[12][Прим. 3]}, Mozilla Firefox^[14][15], Chromium^[16] и Google Chrome^[17], Safari^{[источник не указан 4123 дня]}, Opera^{[источник не указан 4123 дня]}. При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также контент по ссылке file URL не загружается во фреймы документа HTML, загруженного по HTTP URL. Такая политика безопасности была введена в связи с тем, что такие ссылки вызывают ряд уязвимостей:

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

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

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

Основные ограничения политики безопасности в браузерах отражены в таблице^{[Прим.т.2. 1]}.

Примечания к таблице

Атака XXE (англ. Xml eXternal Entity) — одна из известнейших уязвимостей в Интернете. Этот класс уязвимостей зарегистрирован в крупнейших каталогах уязвимостей: Common Weakness Enumeration^[26] и CAPEC^[27]. Суть атаки в следующем. Есть сервисы, поддерживающие протоколы SOAP и XML-RPC, которые принимают входные данные в виде XML-документа. Стандарт XML-документа поддерживает включение секции DTD, а секции DTD, в свою очередь, могут подключать к документу дополнительные компоненты, так называемые внешние сущности (англ. external entity)^[28]. Внешние сущности являются отдельными файлами и задаются с помощью ключевого слова SYSTEM и URI. Если XML-парсер невалидирующий, он может просто загрузить внешнюю сущность и подключить к содержимому XML-документа. Злоумышленник может подставить в URI внешней сущности file URI, указывающий на аппаратное устройство ЭВМ или на локальный файл в системе. Сервер попытается прочитать файл по указанному URI и включить его содержимое в XML. При использовании такого механизма возможны следующие виды атак^[29]:

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

Уязвимость XXE в сообществе http://xml.org (сайт некоммерческой организации OWASP) начали обсуждать ещё с 2001 года^[30], но это были лишь теоретические размышления о возможности атаки такого вида. Первый, кто обратил внимание общественности на эту уязвимость, был Грегори Стейк (англ. Gregory Steuck)^[31]. В 2002 году он отправил security advisory (инструкция по безопасности) на www.securityfocus.com^[29], в котором подробно описал уязвимость и дал ей название атака XXE (англ. XXE Attack).

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

Схема 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 июня он объявил об этом в списке рассылки^[43]. Первая ревизия стандарта схемы file имела название «The file URI Scheme»^[44]. 19 июня Пол Хоффман объявил о Началось активное обсуждение черновика. Сообщество IETF высказало много замечаний, и вскоре вышла вторая ревизия^[45], потом третья^[46] и четвертая^[47]. Но консенсус так и не был достигнут. Для продолжения работы над стандартом Майк Браун создал специальный вики-сайт https://offset.skew.org/wiki/URI/File_scheme, где некоторое время велась работа по сбору информации, касающейся схемы file. Но вскоре эта деятельность затихла, а стандарт так и не был принят.

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

Комментарии

Источники

• URI

• offset.skew.org - вики-сайт для сбора информации о схеме file и координации работ по стандартизации схемы file
• "File URIs in Windows" на сайте blogs.msdn.com - статья об использовании URI со схемой file в Windows API
• "URL Formatting Requirements" на сайте msdn.microsoft.com - о формате URI со схемой file в Windows 7
• "file paths and file URIs" на сайте blogs.oracle.com — статья об использовании URI со схемой file на языке Java
• "URI::file" на сайте cpan.org - использование URI со схемой file на языке Perl