File (схема URI)

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Схема URI file — это схема URI, документированная в 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) как есть, т.е. без %-кодирования[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

Схема file и браузеры[править | править вики-текст]

Браузер Поддержка схемы file (localhost) Пустой host (file:///) Сетевой host Буква диска в пути (C:)[Прим. т. 1] Обзор папок  %-кодированные символы 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[источник не указан 270 дней], Opera[источник не указан 270 дней]. При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также, контент по ссылке 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[источник не указан 270 дней]. В 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]. Но консенсус так и не был достигнут. Для продолжения работы над стандартом Майк Браун создал специальный вики-сайт http://offset.skew.org, где некоторое время велась работа по сбору информации, касающейся схемы 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 (англ.) (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. — С. 157-164.
  3. URL Schemes Supported in Lynx.The file URL. (англ.). Lynx User's Guide. http://lynx.isc.org+(July 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 (December 1994). Проверено 6 октября 2013.
  5. Marcos Cáceres. The app: URI scheme (англ.). W3C (16 May 2013). Проверено 8 октября 2013.
  6. 1 2 3 4 Dave Risney. File URIs in Windows (англ.). MSDN (December 6, 2006). Проверено 16 октября 2013.
  7. 1 2 Risney, Dave File URIs in Windows (англ.). IEBlog. Microsoft Corporation (2013). Проверено 7 августа 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 (October 26, 2007). Проверено 20 октября 2013.
  9. Bug 70871 - file://hostname/dir/dir/filename - hostname not implemented. (2001-03-04). Mozilla
  10. Zeke Odins-Lucas. The Bizarre and Unhappy Story of 'file:' URLs (англ.). MSDN (19 May 2005). Проверено 15 октября 2013.
  11. 1 2 Dave Risney. CreateURLMoniker Considered Harmful (англ.). MSDN (September 14, 2006). Проверено 16 октября 2013.
  12. file Protocol (англ.). MSDN. Проверено 20 октября 2013.
  13. Eric Law. Internet Explorer 9.0.2 Update (англ.). MSDN (12 Aug 2011). Проверено 19 октября 2013.
  14. 1 2 Links to local pages do not work (англ.). MozillaZine Knowledge Base. Mozilla. Проверено 19 октября 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.
  16. A. Barth, C. Jackson, C. Reis, and Google Chrome Team The Security Architecture of the Chromium Browser (англ.) : Technical report. — Stanford University, 2008. — С. 6.
  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. — С. 1240 - 1245. — ISBN 978-1-4244-7763-0.
  18. CVE-2009-1839 (англ.). Common Vulnerabilities and Exposures (29 May 2009). Проверено 19 октября 2013.
  19. Bug 230606 - Tighten the same-origin policy for local files (file: URLs, trusted, security). Bugzilla@Mozilla. Mozilla (10 января 2004). Проверено 20 октября 2013.
  20. Same-origin policy for file: URIs (англ.). Mozilla Developer Network. Проверено 20 октября 2013.
  21. Adam Barth. Security in Depth: Local Web Pages (англ.). Chromium (December 04, 2008). Проверено 20 октября 2013.
  22. Issue 4197: Further restrict access of file URL (англ.). Google. Проверено 20 октября 2013.
  23. Issue 47416: Allow a directory tree to be treated as a single origin (loosen file: URL restrictions) (англ.). Google. Проверено 20 октября 2013.
  24. Michal Zalewski. Browser Security Handbook, part 2 (англ.). Google (December 10, 2008). Проверено 20 октября 2013.
  25. Michal Zalewski. Announcing "Browser Security Handbook" (англ.). Google Online Security Blog (December 10, 2008). Проверено 20 октября 2013.
  26. CWE-611: Improper Restriction of XML External Entity Reference ('XXE') (англ.). Проверено 7 ноября 2013.
  27. CAPEC-201: External Entity Attack (англ.). Проверено 7 ноября 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 (Oct 29 2002). Проверено 25 октября 2013.
  30. Wilson, John Dereferencing Namespace URIs considered harmful (англ.). Список рассылки XML-DEV (01 Jan 2001). Проверено 12 октября 2013.
  31. Sabin, Miles Seen on BugTraq: XXE (Xml eXternal Entity) attack (англ.). Список рассылки XML-DEV (30 Oct 2002). Проверено 12 октября 2013.
  32. Vulnerability Summary for CVE-2008-0628 ("en"). Проверено 7 ноября 2013.
  33. 1 2 CVE-2008-0628 (англ.). Проверено 7 ноября 2013.
  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).&#32;Проверено 7 ноября 2013.
  36. Дмитрий Докучаев Обзор эксплойтов // Хакер. — 2009. — В. 127. — № 07. — С. 44-50.
  37. Apple Safari local file theft vulnerability (англ.). www.securityfocus.com (Jun 09 2009). Проверено 7 ноября 2013.
  38. CVE-2013-4152 XML External Entity (XXE) injection in Spring Framework (англ.). www.securityfocus.com (Aug 22 2013). Проверено 7 ноября 2013.
  39. CakePHP 2.x-2.2.0-RC2 XXE Injection (англ.). www.securityfocus.com (Jul 16 2012). Проверено 7 ноября 2013.
  40. Sverre H. Huseby. Adobe Reader 7: XML External Entity (XXE) Attack (англ.). www.securityfocus.com (Jun 16 2005). Проверено 7 ноября 2013.
  41. SEC Consult SA-20120626-0 :: Zend Framework - Local file disclosure via XXE injection (англ.). www.securityfocus.com (Jun 26 2012). Проверено 7 ноября 2013.
  42. Squiz CMS Multiple Vulnerabilities - Security Advisory - SOS-12-007 (англ.). www.securityfocus.com (Jun 18 2012). Проверено 7 ноября 2013.
  43. Hoffman, Paul Historic scheme drafts (англ.). Список рассылки uri@w3.org (19 Aug 2004). Проверено 26 сентября 2013.
  44. P. Hoffman. The file URI Scheme (англ.). IETF (August 17, 2004). Проверено 6 октября 2013.
  45. P. Hoffman. The file URI Scheme (англ.). IETF (September 18, 2004). Проверено 6 октября 2013.
  46. P. Hoffman. The file URI Scheme (англ.). IETF (November 30, 2004). Проверено 6 октября 2013.
  47. P. Hoffman. The file URI Scheme (англ.). IETF (January 2005). Проверено 6 октября 2013.
  48. M. Kerwin. The file URI Scheme (англ.). IETF (June 20, 2013). Проверено 6 октября 2013.
  49. M. Kerwin. The file URI Scheme (англ.). IETF (September 18, 2013). Проверено 6 октября 2013.

Ссылки[править | править вики-текст]