Русская Википедия:File (схема URI)
Схема 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, имеет разное значение.
- Двойная косая черта (//) после схемы file: — это часть синтаксиса URL, является обязательной при указании authority (поле host выступает в качестве authority).
- Косая черта между host и path — это также часть синтаксиса URL, хотя может являться составной частью path на Unix-системах или отсутствовать, если указанный путь относительный, т. е. начинается с «.» или «..».
- Остальные косые черты разделяют названия каталогов в поле 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]
Примечания
- Комментарии
- Источники
См. также
Ссылки
- 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
- ↑ Uniform Resource Identifier (URI) Schemes Шаблон:WaybackШаблон:Ref-en (iana.org)
- ↑ Шаблон:Статья
- ↑ Шаблон:Cite webШаблон:Недоступная ссылка
- ↑ 4,0 4,1 Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ 6,0 6,1 6,2 6,3 Шаблон:Cite web
- ↑ 7,0 7,1 Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ 10,0 10,1 Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ 12,0 12,1 Шаблон:Cite web
- ↑ 13,0 13,1 Шаблон:Cite web
- ↑ Шаблон:Статья
- ↑ Шаблон:Статья
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Книга
- ↑ 25,0 25,1 Шаблон:Cite web
- ↑ Шаблон:Cite mailing list
- ↑ Шаблон:Cite mailing list
- ↑ Шаблон:Cite web
- ↑ 29,0 29,1 Шаблон:Cite web
- ↑ Шаблон:Cite webШаблон:Недоступная ссылка
- ↑ Шаблон:Cite web
- ↑ Шаблон:Статья
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite mailing list
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
Ошибка цитирования Для существующих тегов <ref> группы «Прим.» не найдено соответствующего тега <references group="Прим."/>
Ошибка цитирования Для существующих тегов <ref> группы «Прим. т.» не найдено соответствующего тега <references group="Прим. т."/>
