Soubor (schéma URI)

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 24. ledna 2021; kontroly vyžadují 10 úprav .

Schéma URI souboru  je schéma URI zdokumentované v RFC 8089 , RFC 1630 , RFC 1738 a RFC 3986 , určené k adresování souborů v místním počítači nebo místní síti podle jejich přímé cesty na disku, síťové složce nebo v některých případech na ftp serveru. Soubor schématu URI je registrován v registru schémat IANA URI [1] a je uveden v části „Schémy trvalé URI“.

O schématu

Souborové schéma je jedním z nejstarších schémat URI . To bylo ztělesněno v softwaru od úsvitu internetu. WorldWideWeb , první webový prohlížeč vytvořený v roce 1991 Timem Berners-Lee , vynálezcem World Wide Web , podporoval souborové schéma . Specifikace RFC 1630 , ve které byla poprvé zdokumentována, byla také napsána Tim Berners-Lee v červnu 1994, před vytvořením W3C , a je jednou z nejstarších internetových specifikací.

Před zavedením ftp schématu se souborové schéma používalo k odkazování na soubory umístěné na ftp serverech. Tim Berners-Lee sám navrhl použití souborového schématu v URL pro odkazy na soubory přístupné přes ftp protokol a sám takové odkazy použil v sekci Reference ve svých publikacích [2] . Prohlížeč Lynx , jeden z nejstarších dochovaných prohlížečů, si zachoval tuto interpretaci schématu souboru [3] dodnes .

Na rozdíl od většiny známých schémat (např. http, nfs, sip, telnet atd.) není souborové schéma protokolem. Toto je výslovně uvedeno v RFC 1738 : "Vlastností tohoto schématu je, že nespecifikuje internetový protokol nebo metodu přístupu k souboru, takže jeho použití v síťových protokolech mezi hostiteli je omezené" [4] . Schéma souboru jednoduše určuje cestu k souboru jako URL (nebo URI) na jednom konkrétním počítači. Také říká, že "toto schéma, na rozdíl od většiny jiných schémat URL, nedefinuje zdroj, který je veřejně dostupný přes internet."

Souborové schéma podporují všechny populární prohlížeče , na všech operačních systémech, i když je založeno na velmi starém standardu, který popisuje formát URL, ale zatím nemá svůj vlastní. Ale vzhledem k výše uvedeným vlastnostem je jeho použití omezené. Funguje to v adresním řádku, ale toto schéma se téměř nikdy nenachází v označení HTML webových stránek. Bylo vyvinuto nové schéma , aplikace , které nahrazuje soubor . Schéma aplikace je popsáno v doporučení W3C z 16. května 2013 [5]

Formát

Adresa URL se souborem schématu má formát [4] :

file:// <hostitel> / <cesta>

kde hostitel je plně kvalifikovaný název domény v systému, kde je cesta k dispozici , a cesta je cesta k hierarchickému adresáři ve formátu adresář / adresář /.../název_souboru . Pokud je hostitel vynechán, výchozí je "localhost", hostitel, na kterém je adresa URL analyzována. Před rokem 2005 měl standard takový požadavek, že pokud je vynechán hostitel, pak nelze vynechat odpovídající lomítko nebo dvojité lomítko („file:///foo.txt“ bude fungovat, ale „file://foo.txt“ nebude, ačkoli některé analyzátory tento případ dokázaly zvládnout). RFC 3986 vydaný v roce 2005 tento požadavek odstranil. Podle RFC 3986 vynechání autority (v tomto případě ekvivalentní k hostiteli ) také vynechá dvojité lomítko (//).

Význam lomítka

Dopředné lomítko (/) má různý význam v závislosti na pozici v URI.

  1. Dvojité lomítko (//) za schématem file: je součástí syntaxe URL a je vyžadováno při zadávání oprávnění ( pole hostitele funguje jako oprávnění).
  2. Lomítko mezi hostitelem a cestou je také součástí syntaxe adresy URL, i když může být součástí cesty na systémech Unix nebo může být vynecháno, pokud je zadaná cesta relativní, tj. začíná "." nebo "..".
  3. Zbývající lomítka oddělují názvy adresářů v poli cesta v hierarchii adresářů místního počítače. V tomto případě je lomítko systémově nezávislý způsob oddělování částí cesty.

Další součásti URL

Komponenty login (uživatelské jméno), heslo (heslo) a port (port) se v adresách URL se schématem souborů nepoužívají. Zároveň však komponenty parametry (řetězec dotazu) a kotva (identifikátor fragmentu) [6] může používat samotná aplikace, která zobrazuje obsah URL daného souboru. Skript v dokumentu HTML může například číst parametry a pro navigaci v dokumentu lze standardním způsobem použít kotvu.

Platné znaky a jejich kódování

Adresy URL souborů se liší znakovou sadou jak od tradičních adres URL, tak od cest k souborům v systémech souborů. Protože cesty v souborových systémech mohou obsahovat znaky vyhrazené v URL pro servisní účely ('#', '%' atd.), jsou takové znaky (dříve také mezera ' ') při převodu cesty na URL souboru zakódovány . Zároveň se ale na rozdíl od URL v URL souboru doporučuje používat znaky cizích abeced (tedy ne z tabulky US-ASCII) tak, jak jsou, tedy bez kódování URL [6] . Je to proto, že oktety zakódované v URL v URL souboru jsou na aktuální kódové stránce uživatele považovány za bajty, což znamená, že hodnota adresy URL se bude měnit v závislosti na národním prostředí, ve kterém je dokument zobrazen [6] .

Příklady

UNIX a operační systémy podobné UNIXu

4 Unixové příklady ukazující na stejný soubor / etc / fstab :

file://localhost/etc/fstab file:///etc/fstab file:///etc/./fstab file:///etc/../etc/fstab

Příklad odkazu na soubor rfc959.txt, který se nachází na ftp serveru nnsc.nsf.net [Poznámka. 1] :

soubor://nnsc.nsf.net/rfc/rfc959.txt Mac OS

2 příklady na Mac OS ukazující na stejný soubor /var/log/system.log :

file://localhost/var/log/system.log file:///var/log/system.log Windows

Příklady cest podporovaných aplikacemi Windows směřujícími na soubor 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

Příklad cesty k souboru start.swf umístěnému v síťové složce products na počítači se síťovým názvem applib [7] :

file://applib/products/ab/abc_9/4148.920a/media/start.swf

Příklad URI souboru se znaky kódovanými % a znakem Unicode [7] (v aplikaci Internet Explorer 6 a 7 nemusí příklad %20 fungovat [8] ):

file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc soubor:///C:/exampleㄓ.txt

Schéma souboru a prohlížeče

Prohlížeč Podpora schématu souborů (localhost) Prázdný hostitel ( file:/// ) Hostitel sítě Písmeno jednotky v cestě ( C: ) [Příkl. v. 1] Přehled složek URL kódované znaky odkazy na soubory v html
Google Chrome Ano Ano VÍTĚZÍ Ano Ano Ano Ano
internet Explorer Ano Ano VÍTĚZÍ Ano Ne Ano Ano
Konqueror Ano Ano ? - Ano Ano Ano
Rys Ano Ano FTP Ano Ano Ano Ano
Mozilla Firefox Ano Ano VÝHRA [Př. v. 2] Ano Ano Ano Ano
Opera Ano Ano VÍTĚZÍ Ano Ano Ano Ano
safari Ano ? ? - Ne ? ?
Prohlížeč Yandex Ano Ano VÍTĚZÍ Ano Ano Ano Ano
Poznámky ke stolu
  1. ↑ Pouze pro prohlížeče, které podporují Windows
  2. ↑ Běžně udávaná cesta jako file://hostname/share/path/to/a/file nefunguje v Mozilla Firefox, ale můžete ji nastavit jako file://///hostname/share/path/to/a /soubor . V roce 2001 Mozilla představila chybu ohledně této chyby, diskutovala o ní několik let, ale neopravili ji (nenašli rozumné řešení) [9]

Schéma souborů Windows

Schéma URI souboru bylo původně podporováno systémem Windows, tzn. s příchodem podpory URI [pozn. 2] obecně a konkrétně s vydáním Internet Exploreru 1 [10] . První verze Internet Exploreru byla vyvinuta v roce 1995, kdy ještě neexistoval standard URL a souborové schéma bylo možné interpretovat různými způsoby, což se stalo v prohlížeči. Jeho různé moduly zacházely se schématem souborů odlišně. Po přepracování byl tento stav odstraněn. Byl vytvořen shlwapi.dll , do kterého byl umístěn veškerý kód pro práci s URL. Při přepracování byly dohodnuty dvě podoby souborového schématu: jedna podle standardu URL, druhá stará forma, která pocházela z dob DOSu. Zaměstnanci Microsoftu to nazvali legacy file URL (zastaralé URL souboru). Příklady adres URL starších souborů:

Cesta k souboru: c:\windows\My Documents 100%20\foo.txt Adresa URL staršího souboru: file://c:\windows\My Documents 100%20\foo.txt Standardní adresa URL souboru: file:///c:/windows/My%20Documents%20100%2520/foo.txt Cesta k souboru: \\server\share\My Documents 100%20\foo.txt Adresa URL staršího souboru: file://\\server\share\My Documents 100%20\foo.txt Standardní adresa URL souboru: file://server/share/My%20Documents%20100%2520/foo.txt

Nová knihovna dll správně zpracovává nové i staré adresy URL souborů, takže její funkce PathCreateFromUrl() a UrlCreateFromPath() jsou doporučeny pro převod mezi cestami Windows a URL souborů [6] [11] .

Kromě těchto funkcí byla v urlmon.dll (počínaje Internet Explorerem 3 ) vytvořena funkce CreateURLMoniker() pro převod URI řetězce na objekt, který lze použít k získání dat adresovaných danému URI ( zástupný název ). Tato funkce ale také způsobovala určité problémy s převodem URI souboru [11] , v důsledku čehož byla přidána a doporučena k použití nová funkce CreateURLMonikerEx() (počínaje Internet Explorerem 5.5 ), ve které byly všechny tyto problémy opraveny. S vydáním aplikace Internet Explorer 7 byla přidána další funkce CreateURLMonikerEx2(), která podporuje relativní cesty.

Bezpečnostní problémy

S příchodem a rozšířením podpory prohlížečů pro skriptovací jazyky , jako je JavaScript , byla objevena řada zranitelností souvisejících s používáním souborového schématu. V důsledku toho prodejci prohlížečů zavedli řadu vestavěných omezení prohlížečů na používání adres URL souborů.

Chyby zabezpečení prohlížeče související s URI hlavního souboru

Odkazy se schématem souborů v dokumentech HTML načítaných přes HTTP nefungují téměř ve všech populárních prohlížečích: Internet Explorer (od verze 6 SP1) [12] [Poznámka. 3] , Mozilla Firefox [14] [15] , Chromium [16] a Google Chrome [17] , Safari , Opera . Kliknutím na takové odkazy nedojde k navigaci ani zobrazení chybové zprávy, i když chybová zpráva může být zaznamenána v chybové konzoli. Obsah na adrese URL souboru se také nenačte do rámců dokumentu HTML načteného na adrese URL HTTP. Tato bezpečnostní politika byla zavedena kvůli skutečnosti, že takové odkazy způsobují řadu zranitelností:

  • Dokument HTML hostovaný na webu útočníka může stáhnout soubory do počítače uživatele pomocí adres URL souborů a poté je odeslat na server ovládaný útočníkem. Útočník získá přístup k důvěrným datům uživatele;
  • Mnoho prohlížečů a pluginů prohlížečů uchovává své dočasné soubory a mezipaměť na předvídatelných místech na disku. Útočník může nejprve umístit soubor HTML na jedno z těchto míst během běžné činnosti prohlížeče (útočník na kontrolovaném webu může požádat o uložení webové stránky na disk nebo o odeslání v archivu na e-mail) a poté se pokusit otevřít to voláním přes speciálně připravenou URL souboru. Dokument HTML otevřený lokálně (prostřednictvím URL souboru) má více oprávnění než vzdálený dokument a může jak přistupovat k citlivým datům uživatele, tak provádět další nežádoucí akce. Tato metoda útoku se také nazývá "file-URL-to-file-URL scripting" [18] . Kromě toho může uživatel otevřít škodlivý html dokument lokálně na svém počítači.
  • Místně otevřený soubor html může načíst vzdálenou webovou stránku do prvku iframe (protože místní soubory v počítači nepodléhají pravidlu omezení domény pouze pro web ), jako je e-mailová stránka, na které je uživatel již přihlášen, a tedy přístup důvěrná uživatelská data umístěná na internetu.

V rámci boje s druhou zranitelností byla také zavedena zásada nazvaná „ Pravidlo omezení domény “ ( stejná zásada původu ), podobná stejnojmenné zásadě, která byla dříve zavedena pro weby v zóně http. Mozilla Firefox, který tuto zásadu zavedl ve verzi prohlížeče 3 ( motor Gecko 1.9) v roce 2007, byl jedním z prvních, kdo tak učinil (trvalo 3 roky, než vývojáři Firefoxu tuto zásadu prodiskutovali a implementovali [19] ). Podle tohoto pravidla může soubor číst jiný soubor pouze v případě, že nadřazeným adresářem zdrojového souboru je nadadresář cílového souboru [20] . Společnost Microsoft byla dříve přísnější a obecně zakázala spouštění Javascriptu při otevírání jakýchkoli místních souborů, počínaje aplikací Internet Explorer 6 v systému Windows XP SP2 a přidala možnost uživatelům spouštět skript výběrem speciálního příkazu z rozbalovací nabídky. Safari 3.2 neumožňuje uživateli otevřít adresy URL místních souborů z jiného zdroje než z adresního řádku. Opera 9.6 neumožňuje lokálním html stránkám načítat vzdálený obsah (to ale nechrání před možností, že by se útočník dostal k datům v počítači). Chromium (a na něm závislý Google Chrome) implementoval politiku podobnou zásadě Opery [21] a vzal v úvahu také politiku Firefoxu, ale později implementoval ještě přísnější politiku [22] tím, že zakázal adresy URL souborů pro skripty na místních webových stránkách na adrese všechny (později bylo rozhodnuto tuto politiku zmírnit).

V důsledku těchto omezení se objevilo mnoho stížností, protože narušují místní stránky a webové adresáře, které jsou široce používány v mnoha podnikových a místních sítích, v distribucích CD, v přílohách e-mailů a jsou také používány webovými vývojáři k ladění. . Například v Mozille o tom bylo zavedeno několik desítek duplicitních chyb [15] . Proto byla v prohlížečích podporována možnost tuto zásadu obejít, zakázat nebo nakonfigurovat a objevily se články, které navrhují, jak to udělat. V aplikaci Internet Explorer je tedy tato zásada konfigurována parametrem „Webové stránky v zóně méně privilegovaného webového obsahu mohou přejít do této zóny“ v nastavení zóny „Můj počítač“ nebo jiné. Tento zákaz se také obchází přidáním webových stránek, které neznepokojují zónu Důvěryhodné servery aplikace Internet Explorer . V Mozilla Firefox se tento zákaz obchází pomocí rozšíření LocalLink, Local Filesystem Links, IE Tab; nebo speciální nastavení bezpečnostní politiky (pro skupinu webů je vytvořena speciální zóna s vlastním specifickým nastavením zabezpečení) [14] . V prohlížeči Google Chrome od verze 7 lze toto omezení obejít spuštěním prohlížeče s příznakem --allow-file-access-from-files nebo použitím rozšíření LocalLinks. Chromium se také rozhodl uvolnit zásadu „ Domain Restriction Rule “ pro adresy URL souborů [23] v důsledku četných stížností .

Omezení bezpečnostní politiky v prohlížečích

Hlavní omezení bezpečnostní politiky v prohlížečích jsou uvedena v tabulce [Poznámka 2. 1] .

Popis testu MSIE6 [Poznámka v.2. 2] MSIE7 [Poznámka v.2. 3] MSIE8 [Poznámka v.2. čtyři] FF2 [Poznámka v.2. 5] FF3 [Poznámka v.2. 6] Safari [Poznámka v.2. 7] Opera [Poznámka v.2. osm] Chrome [Poznámka v.2. 9]
Mají místní HTML přístup k nesouvisejícím místním souborům přes DOM? Ano Ano Ano Ano Ne Ne Ano Ne
Mají místní HTML přístup k nesouvisejícím místním souborům prostřednictvím XMLHttpRequest? Ne Ne Ne Ano Ne Ne Ano Ne
Mají místní HTML přístup k webům na internetu prostřednictvím XMLHttpRequest? Ano Ano Ano Ne Ne Ne Ne Ne
Funguje document.cookie s URL souboru? Ano Ano Ano Ano Ano Ano Ano Ne
Je povoleno načíst značku <IMG> s URI souboru? Ano Ano Ano Ne Ne Ne Ne Ne
Je povoleno načíst značku <SCRIPT> s URI souboru? Ano Ano Ano Ne Ne Ne Ne Ne
Je povoleno načíst značku <IFRAME> s URI souboru? Ano Ano Ano Ne Ne Ne Ne Ne
Je povoleno načíst značku <EMBED> s identifikátorem URI souboru? Ne Ne Ne Ne Ne Ne Ne Ne
Je povoleno načíst značku <APPLET> s URI souboru? Ano Ano Ano Ne Ne Ano Ne Ano
Je možné načíst styly (stylesheet) přes soubor URI? Ano Ano Ano Ne Ne Ne Ne Ne
Jsou povolena přesměrování polohy prostřednictvím URI souboru? Ne Ne Ne Ne Ne Ne Ne Ne
Jsou přes URI souboru povolena přesměrování Obnovit? Ne Ne Ne Ne Ne Ne Ne Ne
Poznámky ke stolu
  1. ↑ Údaje v tabulce pro všechny prohlížeče, pokud není uvedeno jinak, jsou převzaty z „Příručky zabezpečení prohlížeče“ Michala Zalewského [24] , jejíž hlavní materiál byl napsán již v roce 2008 [25] , a pro novější nemusí být relevantní. verze prohlížečů
  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

Attack XXE

Útok  XXE ( Xml eXternal Entity ) je jednou z nejznámějších zranitelností na internetu. Tato třída zranitelností je registrována v největších katalozích zranitelností: Common Weakness Enumeration [26] a CAPEC [27] . Podstata útoku je následující. Existují služby, které podporují protokoly SOAP a XML-RPC, které přijímají vstup ve formě dokumentu XML . Standard dokumentu XML podporuje zahrnutí sekce DTD a sekce DTD zase mohou k dokumentu připojovat další komponenty, tzv . externí entity [ 28 ] .  Externí entity jsou samostatné soubory a jsou určeny pomocí klíčového slova SYSTEM a URI. Pokud analyzátor XML není validní, může jednoduše načíst externí entitu a připojit ji k obsahu dokumentu XML. Útočník může v URI souboru externí entity nahradit URI odkazující na hardwarové zařízení počítače nebo na místní soubor v systému. Server se pokusí přečíst soubor na zadaném URI a zahrnout jeho obsah do XML. Při použití takového mechanismu jsou možné následující typy útoků [29] :

  • DoS (denial of service) útok na server přístupem k systémovému zařízení, jako je /dev/urandom nebo;
  • získání neoprávněného přístupu k souborům soukromého serveru, jako je /etc/passwd nebo c:/winnt/win.ini ;
  • skenování TCP portů (i obcházení firewallu);
  • DoS útok na jiné systémy (pokud parser umožňuje připojení TCP k jiným systémům)
  • krádež ověřovacích materiálů NTLM zahájená prostřednictvím volání UNC do systému pod kontrolou útočníka;
  • Scénář soudného dne: Široce nasazená, vysoce propojená serverová aplikace postižená touto chybou zabezpečení by mohla být použita pro útok DDoS (Distributed Denial of Service).

O zranitelnosti XXE v ​​komunitě http://xml.org (web neziskové organizace OWASP ) se diskutuje již od roku 2001 [30] , ale byly to pouze teoretické úvahy o možnosti útoku tohoto druhu. První osobou, která na tuto zranitelnost upozornila veřejnost, byl Gregory Steuck [31 ] .  V roce 2002 zaslal na www.securityfocus.com [29] bezpečnostní radu (bezpečnostní manuál ) , ve které zranitelnost podrobně popsal a pojmenoval ji XXE Attack . 

Mnoho produktů bylo zasaženo útokem XXE. Všechny hlavní databáze softwarových zranitelností mohou najít softwarové produkty zranitelné vůči útokům XXE: National Vulnerability Database [32] , Common Vulnerabilities and Exposures [33] , Open Source Vulnerability Database [34] . Zranitelnost vůči "XXE útokům" byla objevena v tak známých produktech jako JDK a JRE (6. verze, 3. aktualizace) [33] [35] , WebKit a na něm založený prohlížeč Safari (3. verze) [ 36] [37] , Spring Framework [38] , CakePHP [39] , Adobe Reader (Verze 7) [40] , Zend Framework [41] , Squiz [42] atd.

Standardizace a specifikace

Souborové schéma URI bylo poprvé popsáno v červnu 1994 v informačním RFC 1630 ("Universal Resource Identifiers in WWW"). V prosinci téhož roku byl standardizován v RFC 1738 (Uniform Resource Locators (URL)). RFC 1738 popisuje obecný formát URL a je nyní zastaralý, s výjimkou dvou částí, které popisují schémata souborů a ftp. Nový RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), vydaný v roce 2005, obsahoval RFC 1738 , provedl drobné změny, ale nepopisoval jednotlivá schémata. Do té doby téměř všechna schémata ze stálé sekce obdržela svůj vlastní samostatný standard. Starý RFC 1738 uváděl pouze formát schématu, ale nedefinoval pravidla pro aplikaci tohoto schématu a převod místní cesty na URI a naopak. Bylo potřeba standardizovat souborové schéma, stejně jako řadu dalších nestandardizovaných schémat.

V roce 2004 zahájil Paul Hoffman, který je členem IETF od počátku 90. let, proces standardizace souborového schématu. Během června napsal samostatné specifikace pro schémata file, ftp, gopher, news a nntp, prospero a telnet a 17. června 2004 byly zveřejněny na webu ietf.org a 19. června to oznámil na mailing listu [43] . První revize standardu souborového schématu se jmenovala "Schéma URI souboru" [44] . 19. června Paul Hoffman oznámil, že návrh zahájil aktivní diskusi. Od komunity IETF bylo mnoho připomínek a brzy následovala druhá revize [45] následovaná třetí [46] a čtvrtou [47] . Nikdy však nebylo dosaženo konsensu. Aby Mike Brown pokračoval v práci na standardu, vytvořil speciální wiki stránku https://offset.skew.org/wiki/URI/File_scheme , kde se nějakou dobu pracovalo na sběru informací týkajících se souborového schématu. Brzy však tato činnost utichla a standard nebyl nikdy přijat.

V roce 2013 udělal Matthew Kerwin další pokus o standardizaci souborového schématu. V červnu 2013 byla zveřejněna první revize návrhu [48] , začalo projednávání návrhu a v průběhu června-září bylo zveřejněno 8 dalších revizí. Poslední (#8, tedy devátá [Poznámka 4] ) revize návrhu byla zveřejněna 18. září 2013 [49]

Poznámky

Komentáře
  1. ↑ Tento příklad funguje pouze v prohlížeči Lynx
  2. ↑ Termín URI se objevil později, v té době byl jeho prototypem URL, dále v článku může URI znamenat URL
  3. ↑ Odkazy se schématem souborů s nelokálním hostitelem (tj. adresy URL ukazující na cestu UNC , např. file://dmitryt/public/readme.txt ) fungovaly v Internet Exploreru do verze 9, ale v aktualizaci do verze 9.02 , vydané v srpnu 2011, tato funkce byla zakázána [13]
  4. ↑ Návrhy norem IETF jsou číslovány od 0
Prameny
  1. ↑ Schémata Uniform Resource Identifier (URI) Archived 11. října 2016 na Wayback Machine ( iana.org ) 
  2. ↑ Tim Berners-Lee, et. al. "World-Wide Web: Informační infrastruktura pro fyziku vysokých energií", sborník z druhého workshopu o umělé inteligenci a softwarovém inženýrství pro fyziku vysokých energií, La Londe, Francie, leden 1992  //  Nové výpočetní techniky ve fyzikálním výzkumu. Singapur: World Scientific. - S. 157-164 . Archivováno z originálu 24. září 2015.
  3. ↑ Schémata URL podporovaná v Lynx. URL souboru.  (anglicky) . Lynx uživatelská příručka . http://lynx.isc.org+ (5. července 2009). Staženo: 9. října 2013.  (nedostupný odkaz)
  4. ↑ 1 2 T. Berners-Lee, L. Masinter, M. McCahill. 3.10 Soubory/Uniform Resource Locator (URL  ) . Žádost o připomínky: 1738 14. IETF (prosinec 1994). Získáno 6. října 2013. Archivováno z originálu 15. října 2013.
  5. ↑ Marcos Caceres. Aplikace : schéma URI  . W3C (16. května 2013). Získáno 8. října 2013. Archivováno z originálu 6. října 2013.
  6. ↑ 1 2 3 4 Dave Risney. Identifikátory URI souborů ve Windows  . MSDN (6. prosince 2006). Získáno 16. října 2013. Archivováno z originálu dne 4. srpna 2013.
  7. ↑ 1 2 Risney, Dave File URI ve  Windows . IEBlog . Microsoft Corporation (2013). Získáno 7. srpna 2013. Archivováno z originálu dne 4. srpna 2013.
  8. ↑ Po klepnutí na hypertextový odkaz, který odkazuje na soubor ve vašem místním počítači nebo v místní síti v aplikaci Internet Explorer  , se může zobrazit chybová zpráva . Microsoft (26. října 2007). Získáno 20. října 2013. Archivováno z originálu 16. ledna 2006.
  9. ↑ Chyba 70871 - file://hostname/dir/dir/filename - hostname neimplementováno Archivováno 21. října 2013 na Wayback Machine . (2001-03-04). Mozilla
  10. ↑ Zeke Odins-Lucas. Bizarní a nešťastný příběh URL  'file : ' . MSDN (19. května 2005). Datum přístupu: 15. října 2013. Archivováno z originálu 16. ledna 2013.
  11. ↑ 1 2 Dave Risney. CreateURLMoniker považován za  škodlivý . MSDN (14. září 2006). Získáno 16. října 2013. Archivováno z originálu 17. října 2013.
  12. ↑ protokol  souboru . MSDN . Získáno 20. října 2013. Archivováno z originálu 4. května 2016.
  13. ↑ Eric Law. Aktualizace Internet Explorer 9.0.2  (anglicky) . MSDN (12. srpna 2011). Získáno 19. října 2013. Archivováno z originálu 20. října 2013.
  14. ↑ 1 2 Odkazy na místní stránky  nefungují . Znalostní báze MozillaZine . Mozilla . Získáno 19. října 2013. Archivováno z originálu 20. října 2013.
  15. ↑ 1 2 Chyba 122022 - (file://) [PROBLÉM] file:// URL v http | https stránka nefunguje (kliknutí nedělá nic, nenačte se automaticky atd.) . Bugzilla@Mozilla . Mozilla (26. ledna 2002). Datum přístupu: 20. října 2013. Archivováno z originálu 24. října 2013.
  16. ↑ A. Barth, C. Jackson, C. Reis a tým Google Chrome. Bezpečnostní architektura prohlížeče Chromium  :  Technická zpráva. — Stanford University, 2008. — S. 6 . Archivováno z originálu 7. září 2011.
  17. ↑ Šilić, M.; Krolo, J.; Delac, G. Bezpečnostní zranitelnosti v moderní architektuře webových prohlížečů  //  MIPRO, 2010 Proceedings of the 33rd International Convention. - Opatija, Chorvatsko, 2010. - S. 1240-1245 . — ISBN 978-1-4244-7763-0 . Archivováno z originálu 24. října 2022.
  18. ↑ CVE -2009-1839  . Běžné zranitelnosti a ohrožení (29. května 2009). Datum přístupu: 19. října 2013. Archivováno z originálu 2. dubna 2015.
  19. ↑ Chyba 230606 – Zpřísnění zásady stejného původu pro místní soubory (soubor: URL, důvěryhodné, zabezpečení) . Bugzilla@Mozilla . Mozilla (10. ledna 2004). Získáno 20. října 2013. Archivováno z originálu dne 25. dubna 2014.
  20. ↑ Zásady stejného původu pro soubor: URI  (anglicky)  (downlink) . Mozilla Developer Network . Datum přístupu: 20. října 2013. Archivováno z originálu 16. srpna 2013.
  21. ↑ Adam Barth. Zabezpečení do hloubky: Místní webové  stránky . Chromium (4. prosince 2008). Získáno 20. října 2013. Archivováno z originálu 27. října 2013.
  22. ↑ Vydání 4197: Další omezení přístupu k URL souboru  . Google _ Datum přístupu: 20. října 2013. Archivováno z originálu 24. října 2013.
  23. ↑ Problém 47416: Povolit, aby byl strom adresářů považován za jeden zdroj (uvolněný soubor: omezení URL  ) . Google _ Datum přístupu: 20. října 2013. Archivováno z originálu 24. října 2013.
  24. ↑ Michal Zalewski. Příručka zabezpečení prohlížeče, část  2 . Google (10. prosince 2008). Získáno 20. října 2013. Archivováno z originálu 19. srpna 2016.
  25. ↑ Michal Zalewski. Oznamujeme "Příručku zabezpečení prohlížeče  " . Blog Google Online Security (10. prosince 2008). Získáno 20. října 2013. Archivováno z originálu dne 25. dubna 2014.
  26. ↑ CWE-611: Nesprávné omezení odkazu na externí entity XML ('XXE'  ) . Získáno 7. listopadu 2013. Archivováno z originálu dne 30. března 2020.
  27. ↑ CAPEC-201:  Útok externí entity . Získáno 7. listopadu 2013. Archivováno z originálu 5. prosince 2013.
  28. ↑ Elliot Rusty Harold, W. Scott Means. xml. Reference = XML v kostce, druhé vydání / Per. z angličtiny.- Petrohrad. : Symbol-Plus, 2002. - S.  76 -80. — 576 s. - ISBN 5-93286-025-1 .
  29. ↑ 1 2 Steuck, Gregory XXE (Xml eXternal Entity)  útok . www.securityfocus.com (29. října 2002). Získáno 25. října 2013. Archivováno z originálu 29. října 2013.
  30. ↑ Wilson, John Dereferencování URI jmenného prostoru považované za škodlivé  . XML-DEV mailing list (1. ledna 2001). Staženo: 12. října 2013.
  31. ↑ Sabin, Miles Seen na BugTraq : XXE (Xml eXternal Entity) útok  . XML-DEV mailing list (30. října 2002). Staženo: 12. října 2013.
  32. ↑ Souhrn chyb zabezpečení pro CVE-2008-0628  (nedefinováno) . Získáno 7. listopadu 2013. Archivováno z originálu 2. června 2013.
  33. ↑ 12 CVE - 2008-0628 . Získáno 7. listopadu 2013. Archivováno z originálu dne 4. března 2016. 
  34. ↑ 68033 : Splunk XML Parser Externí entita XML (XXE) Nespecifikovaná eskalace vzdálených oprávnění  . Staženo: 7. listopadu 2013.  (nepřístupný odkaz)
  35. ↑ Chris Evans. Sun JDK6 porušuje ochranu před útoky  XXE . http://scary.beasts.org+(2007).+ Získáno 7. listopadu 2013. Archivováno z originálu 10. ledna 2013.
  36. ↑ Dmitrij Dokučajev. Přehled využití  // Hacker . - 2009. - Vydání. 127 , č. 07 . - S. 44-50 . Archivováno z originálu 25. dubna 2014.
  37. ↑ Chyba zabezpečení proti krádeži místních souborů v Apple Safari  . www.securityfocus.com (9. června 2009). Získáno 7. listopadu 2013. Archivováno z originálu dne 4. března 2016.
  38. ↑ Vložení CVE-2013-4152 XML External Entity (XXE) v Spring  Frameworku . www.securityfocus.com (22. srpna 2013). Získáno 7. listopadu 2013. Archivováno z originálu 7. září 2013.
  39. ↑ CakePHP 2.x-2.2.0-RC2 XXE  Injection . www.securityfocus.com (16. července 2012). Získáno 7. listopadu 2013. Archivováno z originálu 10. října 2012.
  40. ↑ Sverre H. Huseby. Adobe Reader 7 : Útok na externí entity XML (XXE)  . www.securityfocus.com (16. června 2005). Získáno 7. listopadu 2013. Archivováno z originálu dne 4. března 2016.
  41. ↑ SEC Consult SA-20120626-0 :: Zend Framework – Zpřístupnění místního souboru prostřednictvím XXE  injection . www.securityfocus.com (26. června 2012). Získáno 7. listopadu 2013. Archivováno z originálu dne 7. července 2012.
  42. ↑ Squiz CMS Multiple Vulnerabilities - Security Advisory -  SOS- 12-007 . www.securityfocus.com (18. června 2012). Získáno 7. listopadu 2013. Archivováno z originálu dne 4. března 2016.
  43. ↑ Hoffman, Paul Návrhy historických schémat  . [email protected] mailing list (19. srpna 2004). Staženo: 26. září 2013.
  44. ↑ P. Hoffman. Soubor  schéma URI . IETF (17. srpna 2004). Získáno 6. října 2013. Archivováno z originálu 13. září 2014.
  45. ↑ P. Hoffman. Soubor  schéma URI . IETF (18. září 2004). Získáno 6. října 2013. Archivováno z originálu 13. září 2014.
  46. ↑ P. Hoffman. Soubor  schéma URI . IETF (30. listopadu 2004). Získáno 6. října 2013. Archivováno z originálu 13. září 2014.
  47. ↑ P. Hoffman. Soubor  schéma URI . IETF (leden 2005). Datum přístupu: 6. října 2013. Archivováno z originálu 24. července 2014.
  48. ↑ M. Kerwin. Soubor  schéma URI . IETF (20. června 2013). Získáno 6. října 2013. Archivováno z originálu 4. února 2015.
  49. ↑ M. Kerwin. Soubor  schéma URI . IETF (18. září 2013). Získáno 6. října 2013. Archivováno z originálu 4. února 2015.

Viz také

Odkazy

 Schémata URI
Oficiální
neoficiální