Схема URI file — это [1], и входит в раздел «Перманентные схемы URI».

О схеме

Схема file является одной из старейших схем W3C, и является одной из старейших спецификаций Интернета.

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

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

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

Формат

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

file://<host>/<path>

где host — это 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) как есть, т.е. без %-кодирования^[6]. Вызвано это тем, что %-кодированные октеты в file URL рассматриваются как байты в текущей кодовой странице пользователя, т.е. значение URL будет меняться в зависимости от локали, в которой просматривается документ^[6].

Примеры

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

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

file://localhost/etc/fstab
file:///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

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

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

Cхема file в Windows

Схема 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 URI

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

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

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

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

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

Схема URI file впервые была описана в июне 1994 г. в информационном RFC 1738 лишь утверждал формат схемы, но не определял правил по применению этой схемы и конвертации локального пути в URI и обратно. Назревала необходимость стандартизировать схему file, а также ряд других нестандартизированных схем.

В 2004 г. Пол Хоффман, являющийся участником IETF ещё с ранних 1990-х, начал процесс стандартизации схемы file. В течение июня он написал отдельные спецификации для схем file, ftp, gopher, news и nntp, prospero и telnet и 17 июня 2004 они были опубликованы на сайте ietf.org, а 19 июня он объявил об этом в списке рассылки^{http://offset.skew.org, где некоторое время велась работа по сбору информации, касающейся схемы file. Но вскоре эта деятельность затухла, а стандарт так и не был принят.}

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

Примечания

Комментарии

Источники