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, имеет разное значение.

  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, Opera. При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также контент по ссылке 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. В 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 (англ.) (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.
  3. URL Schemes Supported in Lynx.The file URL. (англ.). Lynx User's Guide. http://lynx.isc.org+(5 июля 2009). Дата обращения: 9 октября 2013. (недоступная ссылка)
  4. 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 мая 2013). Дата обращения: 8 октября 2013.
  6. Dave Risney. File URIs in Windows (англ.). MSDN (6 декабря 2006). Дата обращения: 16 октября 2013.
  7. 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 (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 мая 2005). Дата обращения: 15 октября 2013.
  11. Dave Risney. CreateURLMoniker Considered Harmful (англ.). MSDN (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. Links to local pages do not work (англ.). MozillaZine Knowledge Base. Mozilla. Дата обращения: 19 октября 2013.
  15. 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. — P. 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. — P. 1240—1245. — ISBN 978-1-4244-7763-0. Архивировано 28 февраля 2022 года.
  18. CVE-2009-1839 (англ.). Common Vulnerabilities and Exposures (29 мая 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. Архивировано 16 августа 2013 года.
  21. Adam Barth. Security in Depth: Local Web Pages (англ.). Chromium (4 декабря 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. Steuck, Gregory XXE (Xml eXternal Entity) attack (англ.). www.securityfocus.com (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 (неопр.). Дата обращения: 7 ноября 2013.
  33. 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).+Дата обращения: 7 ноября 2013.
  36. Дмитрий Докучаев. Обзор эксплойтов // Хакер. — 2009. — Вып. 127, № 07. — С. 44-50.
  37. Apple Safari local file theft vulnerability (англ.). www.securityfocus.com (9 июня 2009). Дата обращения: 7 ноября 2013.
  38. CVE-2013-4152 XML External Entity (XXE) injection in Spring Framework (англ.). www.securityfocus.com (22 августа 2013). Дата обращения: 7 ноября 2013.
  39. CakePHP 2.x-2.2.0-RC2 XXE Injection (англ.). www.securityfocus.com (16 июля 2012). Дата обращения: 7 ноября 2013.
  40. Sverre H. Huseby. Adobe Reader 7: XML External Entity (XXE) Attack (англ.). www.securityfocus.com (16 июня 2005). Дата обращения: 7 ноября 2013.
  41. SEC Consult SA-20120626-0 :: Zend Framework - Local file disclosure via XXE injection (англ.). www.securityfocus.com (26 июня 2012). Дата обращения: 7 ноября 2013.
  42. Squiz CMS Multiple Vulnerabilities - Security Advisory - SOS-12-007 (англ.). www.securityfocus.com (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 (17 августа 2004). Дата обращения: 6 октября 2013.
  45. P. Hoffman. The file URI Scheme (англ.). IETF (18 сентября 2004). Дата обращения: 6 октября 2013.
  46. P. Hoffman. The file URI Scheme (англ.). IETF (30 ноября 2004). Дата обращения: 6 октября 2013.
  47. P. Hoffman. The file URI Scheme (англ.). IETF (January 2005). Дата обращения: 6 октября 2013.
  48. M. Kerwin. The file URI Scheme (англ.). IETF (20 июня 2013). Дата обращения: 6 октября 2013.
  49. M. Kerwin. The file URI Scheme (англ.). IETF (18 сентября 2013). Дата обращения: 6 октября 2013.

См. также

Ссылки
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.