File (схема URI)

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

Схема 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 Да Да WINS Да Да Да Да
Internet Explorer Да Да WINS Да Нет Да Да
Konqueror Да Да ? - Да Да Да
Lynx Да Да FTP Да Да Да Да
Mozilla Firefox Да Да WINS[Прим. т. 2] Да Да Да Да
Opera Да Да WINS Да Да Да Да
Safari Да ? ? - Нет ? ?
Яндекс.Браузер Да Да WINS Да Да Да Да

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

  1. ↑ Только для браузеров, поддерживающих Windows
  2. ↑ Обыкновенно заданный путь в виде file://hostname/share/path/to/a/file в Mozilla Firefox не работает, но можно задать его как file://///hostname/share/path/to/a/file. В 2001 г. Mozillа был заведен баг по этому поводу, несколько лет шло обсуждение, но его так и не стали исправлять (не нашли разумного решения)[9]

Схема 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[источник не указан 4052 дня], Opera[источник не указан 4052 дня]. При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также контент по ссылке 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[источник не указан 4052 дня]. В Mozilla Firefox этот запрет обходится с помощью расширений LocalLink, Local Filesystem Links, IE Tab; или специальной настройкой политики безопасности (для группы сайтов создаётся специальная зона со своими специфическими настройками безопасности)[14]. В Google Chrome начиная с версии 7 этот запрет можно обойти, запустив браузер с флагом --allow-file-access-from-files или используя расширение LocalLinks. В Chromium также, как следствие многочисленных жалоб, решили ослабить политику «Правило ограничения домена» для file URL[23].

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

[править | править код]

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

Описание теста MSIE6[Прим.т.2. 2] MSIE7[Прим.т.2. 3] MSIE8[Прим.т.2. 4] FF2[Прим.т.2. 5] FF3[Прим.т.2. 6] Safari[Прим.т.2. 7] Opera[Прим.т.2. 8] Chrome[Прим.т.2. 9]
Имеют ли локальные 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? Нет Нет Нет Нет Нет Нет Нет Нет

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

  1. ↑ Данные таблицы, для всех браузеров, если это не указано отдельно, взяты из работы Михала Залевски «Browser Security Handbook»[24], основной материал которой был написан ещё в 2008 году[25], и могут быть неактуальны для более новых версий браузеров
  2. ↑ MSIE6 - Microsoft Internet Explorer 6 (v6.0.2900.5512)
  3. ↑ MSIE7 - Microsoft Internet Explorer 7 (v7.0.5730.11)
  4. ↑ MSIE8 - Microsoft Internet Explorer 8 (v8.0.6001.18702)
  5. ↑ FF2 - Mozilla Firefox 2 (v2.0.0.18)
  6. ↑ FF3 - Mozilla Firefox 3 (v3.6.8)
  7. ↑ Safari - Apple Safari v4.0
  8. ↑ Opera - Opera v9.62
  9. ↑ Chrome - Google Chrome v7.0.503.0

Атака XXE

[править | править код]

Атака 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]

Примечания

[править | править код]

Комментарии

  1. ↑ Этот пример работает только в браузере Lynx
  2. ↑ Термин URI появился позже, на тот момент его прототипом был URL, здесь и далее в статье под URI может подразумеваться URL
  3. ↑ Ссылки со схемой file с нелокальным хостом (т. е. URL, указывающие на UNC-путь, например, file://dmitryt/public/readme.txt), работали в Internet Explorer вплоть до 9-й версии, но в обновлении до версии 9.02, вышедшем в августе 2011 года, эта возможность была отключена [13]
  4. ↑ Черновики стандартов IETF нумеруются с 0

Источники

  1. ↑ Uniform Resource Identifier (URI) Schemes Архивная копия от 11 октября 2016 на Wayback Machine (англ.) (iana.org)
  2. ↑ Tim Berners-Lee, et. al. "World-Wide Web: an Information Infrastructure for High-Energy Physics", Proceedings of the Second Workshop on Artificial Intelligence and Software Engineering for High energy Physics, La Londe, France, January 1992 (англ.) // New Computing Techniques in Physics Research. — Singapore: World Scientific. — P. 157—164. Архивировано 24 сентября 2015 года.
  3. ↑ URL Schemes Supported in Lynx.The file URL. (англ.). Lynx User's Guide. http://lynx.isc.org+(5 июля 2009). Дата обращения: 9 октября 2013. (недоступная ссылка)
  4. ↑ 1 2 T. Berners-Lee, L. Masinter, M. McCahill. 3.10 Files / Uniform Resource Locators (URL) (англ.). Request for Comments: 1738 14. IETF (декабрь 1994). Дата обращения: 6 октября 2013. Архивировано 15 октября 2013 года.
  5. ↑ Marcos Cáceres. The app: URI scheme (англ.). W3C (16 мая 2013). Дата обращения: 8 октября 2013. Архивировано 6 октября 2013 года.
  6. ↑ 1 2 3 4 Dave Risney. File URIs in Windows (англ.). MSDN (6 декабря 2006). Дата обращения: 16 октября 2013. Архивировано 4 августа 2013 года.
  7. ↑ 1 2 Risney, Dave File URIs in Windows (англ.). IEBlog. Microsoft Corporation (2013). Дата обращения: 7 августа 2013. Архивировано 4 августа 2013 года.
  8. ↑ You may receive an error message when you click a hyperlink that references a file on your local computer or on your local network in Internet Explorer (англ.). Microsoft (26 октября 2007). Дата обращения: 20 октября 2013. Архивировано 16 января 2006 года.
  9. ↑ Bug 70871 - file://hostname/dir/dir/filename - hostname not implemented Архивная копия от 21 октября 2013 на Wayback Machine. (2001-03-04). Mozilla
  10. ↑ Zeke Odins-Lucas. The Bizarre and Unhappy Story of 'file:' URLs (англ.). MSDN (19 мая 2005). Дата обращения: 15 октября 2013. Архивировано 16 января 2013 года.
  11. ↑ 1 2 Dave Risney. CreateURLMoniker Considered Harmful (англ.). MSDN (14 сентября 2006). Дата обращения: 16 октября 2013. Архивировано 17 октября 2013 года.
  12. ↑ file Protocol (англ.). MSDN. Дата обращения: 20 октября 2013. Архивировано 4 мая 2016 года.
  13. ↑ Eric Law. Internet Explorer 9.0.2 Update (англ.). MSDN (12 августа 2011). Дата обращения: 19 октября 2013. Архивировано 20 октября 2013 года.
  14. ↑ 1 2 Links to local pages do not work (англ.). MozillaZine Knowledge Base. Mozilla. Дата обращения: 19 октября 2013. Архивировано 20 октября 2013 года.
  15. ↑ 1 2 Bug 122022 - (file://) [ISSUE] file:// URLs in a http | https page do not work (clicking does nothing, do not auto-load, etc.). Bugzilla@Mozilla. Mozilla (26 января 2002). Дата обращения: 20 октября 2013. Архивировано 24 октября 2013 года.
  16. ↑ A. Barth, C. Jackson, C. Reis, and Google Chrome Team. The Security Architecture of the Chromium Browser (англ.) : Technical report. — Stanford University, 2008. — P. 6. Архивировано 7 сентября 2011 года.
  17. ↑ Šilić, M. ; Krolo, J. ; Delac, G. Security Vulnerabilities in Modern Web Browser Architecture (англ.) // MIPRO, 2010 Proceedings of the 33rd International Convention. — Opatija, Croatia, 2010. — P. 1240—1245. — ISBN 978-1-4244-7763-0. Архивировано 23 ноября 2024 года.
  18. ↑ CVE-2009-1839 (англ.). Common Vulnerabilities and Exposures (29 мая 2009). Дата обращения: 19 октября 2013. Архивировано 2 апреля 2015 года.
  19. ↑ Bug 230606 - Tighten the same-origin policy for local files (file: URLs, trusted, security). Bugzilla@Mozilla. Mozilla (10 января 2004). Дата обращения: 20 октября 2013. Архивировано 25 апреля 2014 года.
  20. ↑ Same-origin policy for file: URIs (англ.). Mozilla Developer Network. Дата обращения: 20 октября 2013. Архивировано из оригинала 16 августа 2013 года.
  21. ↑ Adam Barth. Security in Depth: Local Web Pages (англ.). Chromium (4 декабря 2008). Дата обращения: 20 октября 2013. Архивировано 27 октября 2013 года.
  22. ↑ Issue 4197: Further restrict access of file URL (англ.). Google. Дата обращения: 20 октября 2013. Архивировано 24 октября 2013 года.
  23. ↑ Issue 47416: Allow a directory tree to be treated as a single origin (loosen file: URL restrictions) (англ.). Google. Дата обращения: 20 октября 2013. Архивировано 24 октября 2013 года.
  24. ↑ Michal Zalewski. Browser Security Handbook, part 2 (англ.). Google (10 декабря 2008). Дата обращения: 20 октября 2013. Архивировано 19 августа 2016 года.
  25. ↑ Michal Zalewski. Announcing "Browser Security Handbook" (англ.). Google Online Security Blog (10 декабря 2008). Дата обращения: 20 октября 2013. Архивировано 25 апреля 2014 года.
  26. ↑ CWE-611: Improper Restriction of XML External Entity Reference ('XXE') (англ.). Дата обращения: 7 ноября 2013. Архивировано 30 марта 2020 года.
  27. ↑ CAPEC-201: External Entity Attack (англ.). Дата обращения: 7 ноября 2013. Архивировано 5 декабря 2013 года.
  28. ↑ Эллиот Расти Гарольд, В. Скотт Минс. XML. Справочник = XML in a Nutshell, Second Edition / Пер. с англ.. — СПб.: Символ-Плюс, 2002. — С. 76-80. — 576 с. — ISBN 5-93286-025-1.
  29. ↑ 1 2 Steuck, Gregory XXE (Xml eXternal Entity) attack (англ.). www.securityfocus.com (29 октября 2002). Дата обращения: 25 октября 2013. Архивировано 29 октября 2013 года.
  30. ↑ Wilson, John (01 Jan 2001). "Dereferencing Namespace URIs considered harmful". XML-DEV (Mailing list) (англ.). Архивировано 29 октября 2013. Дата обращения: 12 октября 2013. {{cite mailing list}}: Проверьте значение даты: |date= (справка)
  31. ↑ Sabin, Miles (30 Oct 2002). "Seen on BugTraq: XXE (Xml eXternal Entity) attack". XML-DEV (Mailing list) (англ.). Архивировано 29 октября 2013. Дата обращения: 12 октября 2013.
  32. ↑ Vulnerability Summary for CVE-2008-0628 (англ.). Дата обращения: 7 ноября 2013. Архивировано 2 июня 2013 года.
  33. ↑ 1 2 CVE-2008-0628 (англ.). Дата обращения: 7 ноября 2013. Архивировано 4 марта 2016 года.
  34. ↑ 68033 : Splunk XML Parser XML External Entity (XXE) Unspecified Remote Privilege Escalation (англ.). Дата обращения: 7 ноября 2013. (недоступная ссылка)
  35. ↑ Chris Evans. Sun JDK6 breaks XXE attack protection (англ.). http://scary.beasts.org+(2007).+Дата обращения: 7 ноября 2013. Архивировано 10 января 2013 года.
  36. ↑ Дмитрий Докучаев. Обзор эксплойтов // Хакер. — 2009. — Вып. 127, № 07. — С. 44-50. Архивировано 25 апреля 2014 года.
  37. ↑ Apple Safari local file theft vulnerability (англ.). www.securityfocus.com (9 июня 2009). Дата обращения: 7 ноября 2013. Архивировано 4 марта 2016 года.
  38. ↑ CVE-2013-4152 XML External Entity (XXE) injection in Spring Framework (англ.). www.securityfocus.com (22 августа 2013). Дата обращения: 7 ноября 2013. Архивировано 7 сентября 2013 года.
  39. ↑ CakePHP 2.x-2.2.0-RC2 XXE Injection (англ.). securityfocus.com (16 июля 2012). Дата обращения: 7 ноября 2013. Архивировано 10 октября 2012 года.
  40. ↑ Sverre H. Huseby. Adobe Reader 7: XML External Entity (XXE) Attack (англ.). securityfocus.com (16 июня 2005). Дата обращения: 7 ноября 2013. Архивировано 4 марта 2016 года.
  41. ↑ SEC Consult SA-20120626-0 :: Zend Framework - Local file disclosure via XXE injection (англ.). www.securityfocus.com (26 июня 2012). Дата обращения: 7 ноября 2013. Архивировано 7 июля 2012 года.
  42. ↑ Squiz CMS Multiple Vulnerabilities - Security Advisory - SOS-12-007 (англ.). securityfocus.com (18 июня 2012). Дата обращения: 7 ноября 2013. Архивировано 4 марта 2016 года.
  43. ↑ Hoffman, Paul (19 Aug 2004). "Historic scheme drafts". uri@w3.org (Mailing list) (англ.). Архивировано 11 июня 2015. Дата обращения: 26 сентября 2013.
  44. ↑ P. Hoffman. The file URI Scheme (англ.). IETF (17 августа 2004). Дата обращения: 6 октября 2013. Архивировано 13 сентября 2014 года.
  45. ↑ P. Hoffman. The file URI Scheme (англ.). IETF (18 сентября 2004). Дата обращения: 6 октября 2013. Архивировано 13 сентября 2014 года.
  46. ↑ P. Hoffman. The file URI Scheme (англ.). IETF (30 ноября 2004). Дата обращения: 6 октября 2013. Архивировано 13 сентября 2014 года.
  47. ↑ P. Hoffman. The file URI Scheme (англ.). IETF (январь 2005). Дата обращения: 6 октября 2013. Архивировано 24 июля 2014 года.
  48. ↑ M. Kerwin. The file URI Scheme (англ.). IETF (20 июня 2013). Дата обращения: 6 октября 2013. Архивировано 4 февраля 2015 года.
  49. ↑ M. Kerwin. The file URI Scheme (англ.). IETF (18 сентября 2013). Дата обращения: 6 октября 2013. Архивировано 4 февраля 2015 года.

См. также

[править | править код]

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=File_(схема_URI)&oldid=140734473