Fil (URI-schema)

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 24 januari 2021; kontroller kräver 10 redigeringar .

Filens URI - schema  är ett URI-schema dokumenterat i RFC 8089 , RFC 1630 , RFC 1738 och RFC 3986 , utformat för att adressera filer på en lokal dator eller lokalt nätverk genom deras direkta sökväg på en disk, nätverksmapp eller, i vissa fall, på en ftp-server. URI -schemafilen är registrerad hos IANA URI Scheme Registry [1] och listas under avsnittet "Permanenta URI-scheman".

Om schemat

Filschemat är ett av de äldsta URI- scheman . Det har funnits i mjukvara sedan Internets gryning. WorldWideWeb , den första webbläsaren som skapades 1991 av Tim Berners-Lee , uppfinnaren av World Wide Web , stödde filschemat . Specifikationen RFC 1630 , i vilken den först dokumenterades, skrevs också av Tim Berners-Lee i juni 1994, före skapandet av W3C , och är en av de äldsta Internetspecifikationerna.

Innan introduktionen av ftp - schemat användes filschemat för att referera till filer som finns på ftp-servrar. Tim Berners-Lee föreslog själv användningen av filschemat i URL :en för länkar till filer som är tillgängliga via ftp-protokollet , och han använde själv sådana länkar i avsnittet Referenser i sina publikationer [2] . Lynx- webbläsaren , en av de äldsta bevarade webbläsarna, har behållit denna tolkning av filschemat [3] till denna dag .

Till skillnad från de flesta kända scheman (t.ex. http, nfs, sip, telnet, etc.), är filschemat inte ett protokoll. Detta anges uttryckligen i RFC 1738 : "En egenskap hos detta schema är att det inte specificerar ett internetprotokoll eller filåtkomstmetod, så dess användning i nätverksprotokoll mellan värdar är begränsad" [4] . Filschemat anger helt enkelt sökvägen till en fil som en URL ( eller URI) på en specifik dator. Det står också att "det här schemat, till skillnad från de flesta andra URL-scheman, inte definierar en resurs som är allmänt tillgänglig över Internet."

Filschemat stöds av alla populära webbläsare , på alla operativsystem, även om det är baserat på en mycket gammal standard som beskriver URL-formatet, men som ännu inte har sin egen. Men på grund av ovanstående funktioner är dess användning begränsad. Det fungerar i adressfältet, men det här schemat finns nästan aldrig i HTML -uppmärkningen av webbplatser. Ett nytt schema , app , har utvecklats för att ersätta filen . Appschemat beskrivs i W3C- rekommendationen den 16 maj 2013 [5]

Format

URL:en med schemafilen har formatet [4] :

file:// <värd> / <sökväg>

där host är det fullt kvalificerade domännamnet på systemet där sökvägen är tillgänglig och sökvägen är en hierarkisk katalogsökväg i formatet katalog / katalog /.../ filnamn . Om värd utelämnas är standardvärden "localhost", den värd på vilken webbadressen tolkas. Före 2005 hade standarden ett krav så att om värden utelämnas så kan motsvarande snedstreck eller dubbla snedstreck inte utelämnas ("file:///foo.txt" kommer att fungera, men "file://foo.txt" kommer inte , även om vissa analyserare kunde hantera det här fallet). RFC 3986 , som släpptes 2005, tog bort detta krav. Enligt RFC 3986 utelämnar en utelämnande auktoritet (i detta fall motsvarande värd ) även det dubbla snedstrecket (//).

Betydelsen av snedstrecket

Det framåtgående snedstrecket (/) har en annan betydelse beroende på positionen i URI:n.

  1. Det dubbla snedstrecket (//) efter filen: -schemat är en del av URL- syntaxen och krävs när auktoritet anges ( värdfältet fungerar som auktoritet).
  2. Snedstrecket mellan värd och sökväg är också en del av URL-syntaxen, även om det kan vara en del av sökväg på Unix-system , eller utelämnas om den angivna sökvägen är relativ, dvs. börjar med "." eller "...".
  3. De återstående snedstreck separerar namnen på kataloger i sökvägsfältet i kataloghierarkin på den lokala datorn. I det här fallet är snedstrecket ett systemoberoende sätt att separera bandelar.

Andra URL-komponenter

Komponenterna inloggning (användarnamn), lösenord (lösenord) och port (port) används inte i URL:er med filschemat. Men samtidigt kan parametrarna (frågesträng) och ankare (fragmentidentifierare) ​​komponenter [6] användas av själva applikationen, som visar innehållet i den givna filens URL. Till exempel kan ett skript inuti ett HTML- dokument läsa parametrarna, och ett ankare kan användas på ett standardsätt för att navigera i dokumentet.

Giltiga tecken och deras kodningar

Fil-URL:er skiljer sig i teckenuppsättning från både traditionella URL:er och filsökvägar i filsystem. Eftersom sökvägar i filsystem kan innehålla tecken som är reserverade i URL:er för tjänsteändamål ('#', '%', etc.), kodas sådana tecken (tidigare även mellanslag ' ') när en sökväg konverteras till en fil-URL . Men samtidigt, till skillnad från URL:en, i filen URL rekommenderas det att använda tecken från främmande alfabet (det vill säga inte från US-ASCII-tabellen) som den är, det vill säga utan URL-kodning [6] . Detta beror på att de URL-kodade oktetterna i filens URL behandlas som byte i användarens aktuella teckentabell, vilket innebär att värdet på URL:en kommer att ändras beroende på lokaliteten där dokumentet visas [6] .

Exempel

UNIX och UNIX-liknande operativsystem

4 Unix - exempel som pekar på samma / etc / fstab-fil :

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

Ett exempel på en länk till filen rfc959.txt, som finns på nnsc.nsf.net ftp-servern [Anm. 1] :

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

2 exempel på Mac OS som pekar på samma /var/log/system.log-fil :

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

Exempel på sökvägar som stöds av Windows -program som pekar på filen 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

En exempelsökväg till start.swf -filen som finns i nätverksmappen produkter på en dator med nätverksnamnet applib [7] :

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

En exempelfil URI med %-kodade tecken och ett Unicode-tecken [7] (i Internet Explorer 6 och 7 kanske %20 -exemplet inte fungerar [8] ):

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

Filschemat och webbläsarna

Webbläsare Stöd för filschema (localhost) Tom värd ( file:/// ) Nätverksvärd _ Körbokstav i sökväg ( C: ) [Ex. v. 1] Mappöversikt URL-kodade tecken fillänkar i html
Google Chrome Ja Ja VINNER Ja Ja Ja Ja
Internet Explorer Ja Ja VINNER Ja Inte Ja Ja
Konqueror Ja Ja ? - Ja Ja Ja
Lodjur Ja Ja FTP Ja Ja Ja Ja
Mozilla Firefox Ja Ja VINNER [Ex. v. 2] Ja Ja Ja Ja
Opera Ja Ja VINNER Ja Ja Ja Ja
safari Ja ? ? - Inte ? ?
Yandex webbläsare Ja Ja VINNER Ja Ja Ja Ja
Tabellanteckningar
  1. ↑ Endast för webbläsare som stöder Windows
  2. ↑ Den vanliga sökvägen som file://hostname/share/path/to/a/file fungerar inte i Mozilla Firefox, men du kan ställa in den som file://///hostname/share/path/to/a /fil . 2001 introducerade Mozilla en bugg om detta, diskuterade det i flera år, men de fixade det inte (de hittade inte en rimlig lösning) [9]

Windows filschema

Fil-URI-schemat stöddes ursprungligen av Windows, dvs. med tillkomsten av URI-stöd [Anm. 2] i allmänhet, och specifikt med lanseringen av Internet Explorer 1 [10] . Den första versionen av Internet Explorer utvecklades 1995, när URL-standarden ännu inte existerade, och filschemat kunde tolkas på olika sätt, vilket hände med webbläsaren. Dess olika moduler hanterade filschemat på olika sätt. Efter omarbetning eliminerades denna situation. shlwapi.dll skapades , där all kod för att arbeta med URL:en placerades. Under omarbetningen kom man överens om två former av filschemat: en enligt URL-standarden, den andra en gammal form som kom från DOS-tiden. Microsofts anställda kallade det äldre fil-URL (föråldrad fil-URL). Exempel på äldre fil-URL:

Filsökväg: c:\windows\Mina dokument 100%20\foo.txt Äldre fil-URL: file://c:\windows\My Documents 100%20\foo.txt Standardfilens URL: file:///c:/windows/My%20Documents%20100%2520/foo.txt Filsökväg: \\server\share\My Documents 100%20\foo.txt Äldre fil-URL: file://\\server\share\My Documents 100%20\foo.txt Standardfil-URL: file://server/share/My%20Documents%20100%2520/foo.txt

Den nya dll-filen hanterar både nya och gamla fil-URL:er korrekt, så dess PathCreateFromUrl()- och UrlCreateFromPath()-funktioner rekommenderas för konvertering mellan Windows-sökvägar och fil-URL:er [6] [11] .

Utöver dessa funktioner skapades funktionen CreateURLMoniker() i urlmon.dll (som börjar med Internet Explorer 3 ) för att konvertera en sträng-URI till ett objekt som kan användas för att få informationen adresserad till den givna URI-en ( moniker ). Men den här funktionen orsakade också vissa problem med att konvertera filen URI [11] , som ett resultat av vilket en ny CreateURLMonikerEx()-funktion lades till och rekommenderades för användning (från och med Internet Explorer 5.5 ), där alla dessa problem fixades. Med lanseringen av Internet Explorer 7 lades ytterligare en CreateURLMonikerEx2()-funktion till som stöder relativa sökvägar.

Säkerhetsproblem

Med tillkomsten och spridningen av webbläsarstöd för skriptspråk som JavaScript har ett antal sårbarheter upptäckts relaterade till användningen av filschemat. Som ett resultat av detta har webbläsarleverantörer infört ett antal inbyggda webbläsarrestriktioner för användningen av fil-URL:er.

Stora fil URI-relaterade sårbarheter i webbläsaren

Länkar med filschemat i HTML-dokument som laddas över HTTP fungerar inte i nästan alla populära webbläsare: Internet Explorer (från version 6 SP1) [12] [Obs. 3] , Mozilla Firefox [14] [15] , Chromium [16] och Google Chrome [17] , Safari , Opera . Att klicka på sådana länkar varken navigerar eller visar ett felmeddelande, även om ett felmeddelande kan loggas i felkonsolen. Innehåll på en fil-URL läses inte heller in i ramarna för ett HTML-dokument som laddas med en HTTP-URL. Denna säkerhetspolicy infördes på grund av att sådana länkar orsakar ett antal sårbarheter:

  • Ett HTML-dokument som finns på en angripares webbplats kan ladda ner filer på användarens dator med hjälp av fil-URL:er och sedan skicka dem till en server som kontrolleras av angriparen. Angriparen får tillgång till användarens konfidentiella data;
  • Många webbläsare och plugins för webbläsare håller sina temporära filer och cache på förutsägbara platser på disken. En angripare kan först placera en HTML-fil på en av dessa platser under normal webbläsardrift (en angripare på en kontrollerad webbplats kan be om att spara en webbsida på disk eller skicka den i ett arkiv till e-post), och sedan försöka öppna det genom att anropa en speciellt förberedd fil-URL. Ett HTML-dokument som öppnas lokalt (via en fil-URL) har fler privilegier än ett fjärrdokument och kan både komma åt användarens känsliga data och utföra andra oönskade åtgärder. Denna attackmetod kallas även "fil-URL-till-fil-URL-skripting" [18] . Dessutom kan användaren öppna ett skadligt html-dokument lokalt på sin dator.
  • En lokalt öppnad html-fil kan ladda en fjärrwebbsida i en iframe (eftersom lokala filer på datorn inte omfattas av begränsningsregeln för endast webbplatsen för domäner ), till exempel en e-postwebbplats där användaren redan är inloggad, och därmed komma åt konfidentiell användardata som finns på Internet.

För att bekämpa den andra sårbarheten infördes också en policy som kallas " Domänbegränsningsregel " ( samma ursprungspolicy ), liknande policyn med samma namn som introducerades tidigare för webbplatser i http-zonen. Mozilla Firefox, som introducerade denna policy i webbläsarversion 3 ( Gecko 1.9-motor) 2007, var en av de första som gjorde det (det tog 3 år för Firefox-utvecklarna att diskutera och implementera denna policy [19] ). Enligt denna regel kan en fil endast läsa en annan fil om källfilens överordnade katalog är målfilens superkatalog [20] . Microsoft har tidigare varit tuffare och allmänt inaktiverat Javascript-körning när de öppnar lokala filer, med början i Internet Explorer 6 i Windows XP SP2, vilket har lagt till möjligheten för användare att köra ett skript genom att välja ett speciellt kommando från en popup-meny. Safari 3.2 tillåter inte användaren att öppna lokala fil-URL från någon annan källa än adressfältet. Opera 9.6 tillåter inte lokala HTML-sidor att ladda fjärrinnehåll (men detta skyddar inte mot möjligheten för en angripare att komma åt data på datorn). Chromium (och dess beroende Google Chrome) implementerade en policy som liknar den för Opera [21] och tog även hänsyn till Firefoxs policy, men implementerade senare en ännu mer restriktiv policy [22] genom att inte tillåta filadresser för skript på lokala webbsidor på alla (senare beslutades att mildra denna policy).

Det har förekommit många klagomål till följd av dessa begränsningar, eftersom de stör lokala webbplatser och webbkataloger, som används i stor utsträckning i många företags- och lokala nätverk, i CD-distributioner, i e-postbilagor och även används av webbutvecklare för felsökning. . webbplatser. Till exempel introducerades flera dussintals dubbletter av buggar i Mozilla om detta [15] . Därför har möjligheten att kringgå, inaktivera eller konfigurera denna policy stöds i webbläsare, och artiklar har dykt upp som föreslår hur man gör detta. Så i Internet Explorer konfigureras den här policyn av parametern "Webbplatser i mindre privilegierad webbinnehållszon kan navigera in i den här zonen" i inställningarna för zonen "Min dator" eller en annan. Dessutom förbigås detta förbud genom att lägga till webbplatser som orsaka inte någon oro för zonen Internet Explorer Trusted Sites . I Mozilla Firefox förbigås detta förbud med tilläggen LocalLink, Local Filesystem Links, IE Tab; eller en speciell säkerhetspolicyinställning (en speciell zon skapas för en grupp webbplatser med sina egna specifika säkerhetsinställningar) [14] . I Google Chrome från och med version 7 kan denna begränsning kringgås genom att starta webbläsaren med flaggan --allow-file-access-from-files eller genom att använda tillägget LocalLinks. Chromium har också beslutat att mildra policyn för " Domänbegränsningsregeln " för fil-URL:er [23] som ett resultat av många klagomål .

Säkerhetspolicybegränsningar i webbläsare

De huvudsakliga begränsningarna för säkerhetspolicyn i webbläsare återspeglas i tabellen [Anmärkning 2. 1] .

Testbeskrivning MSIE6 [Anmärkning v.2. 2] MSIE7 [Anmärkning v.2. 3] MSIE8 [Anmärkning v.2. fyra] FF2 [Notera v.2. 5] FF3 [Notera v.2. 6] Safari [Anmärkning v.2. 7] Opera [Anmärkning v.2. åtta] Chrome [Anmärkning v.2. 9]
Har lokala HTML-filer tillgång till orelaterade lokala filer via DOM? Ja Ja Ja Ja Inte Inte Ja Inte
Har lokala HTML-filer tillgång till orelaterade lokala filer via XMLHttpRequest? Inte Inte Inte Ja Inte Inte Ja Inte
Har lokala HTML-filer tillgång till webbplatser på Internet via XMLHttpRequest? Ja Ja Ja Inte Inte Inte Inte Inte
Fungerar document.cookie med fil-URL? Ja Ja Ja Ja Ja Ja Ja Inte
Är det tillåtet att ladda <IMG>-taggen med filen URI? Ja Ja Ja Inte Inte Inte Inte Inte
Är det tillåtet att ladda <SCRIPT>-taggen med filen URI? Ja Ja Ja Inte Inte Inte Inte Inte
Är det tillåtet att ladda <IFRAME>-taggen med filen URI? Ja Ja Ja Inte Inte Inte Inte Inte
Är det tillåtet att ladda <EMBED>-taggen med en fil-URI? Inte Inte Inte Inte Inte Inte Inte Inte
Är det tillåtet att ladda <APPLET>-taggen med filen URI? Ja Ja Ja Inte Inte Ja Inte Ja
Är det möjligt att ladda stilar (stilmall) via filen URI? Ja Ja Ja Inte Inte Inte Inte Inte
Är platsomdirigering tillåtna via fil-URI? Inte Inte Inte Inte Inte Inte Inte Inte
Är Refresh omdirigeringar tillåtna via fil-URI? Inte Inte Inte Inte Inte Inte Inte Inte
Tabellanteckningar
  1. ↑ Data i tabellen, för alla webbläsare, om inte annat anges, är hämtade från Michal Zalewskis "Browser Security Handbook" [24] , vars huvudmaterial skrevs tillbaka 2008 [25] , och kanske inte är relevant för nyare versioner av webbläsare
  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

XXE ( Xml eXternal Entity )  attacken är en av de mest kända sårbarheterna på Internet. Denna klass av sårbarheter är registrerad i de största sårbarhetskatalogerna: Common Weakness Enumeration [26] och CAPEC [27] . Kärnan i attacken är följande. Det finns tjänster som stöder SOAP- och XML-RPC-protokollen som accepterar input i form av ett XML - dokument. XML-dokumentstandarden stöder införandet av en DTD- sektion , och DTD-sektionerna kan i sin tur koppla ytterligare komponenter till dokumentet, de så kallade externa enheterna [ 28 ] . Externa enheter är separata filer och specificeras med nyckelordet SYSTEM och URI. Om XML-tolken inte är validerande kan den helt enkelt ladda den externa enheten och bifoga den till innehållet i XML-dokumentet. En angripare kan i den externa enhetsfilens URI ersätta en URI som pekar på en hårdvaruenhet på datorn eller till en lokal fil i systemet. Servern kommer att försöka läsa filen på angiven URI och inkludera dess innehåll i XML. När du använder en sådan mekanism är följande typer av attacker möjliga [29] :  

  • DoS (denial of service) attack mot en server genom att komma åt en systemenhet som /dev/urandom eller;
  • få obehörig åtkomst till privata serverfiler, såsom /etc/passwd eller c:/winnt/win.ini ;
  • skanna TCP-portar (även kringgå brandväggen);
  • DoS-attack på andra system (om parsern tillåter TCP-anslutningar till andra system)
  • stöld av NTLM-autentiseringsmaterial som initierats genom ett UNC -anrop till ett system under angriparens kontroll;
  • Domedagsscenario: En allmänt distribuerad, starkt uppkopplad serverapplikation som påverkas av denna sårbarhet kan användas för en DDoS -attack (Distributed Denial of Service).

XXE-sårbarheten i http: //xml.org-communityt (webbplatsen för den ideella organisationen OWASP ) har diskuterats sedan 2001 [30] , men det var bara teoretiska tankar om möjligheten till en attack av detta slag. Den första personen som drog allmänhetens uppmärksamhet till denna sårbarhet var Gregory Steuck [31 ] .  2002 skickade han en säkerhetsrådgivning (säkerhetsmanual ) till www.securityfocus.com [29] , där han beskrev sårbarheten i detalj och gav den namnet XXE Attack . 

Många produkter påverkades av XXE-attacken. Alla större databaser med sårbarheter i programvara kan hitta mjukvaruprodukter som är sårbara för XXE-attacker: National Vulnerability Database [32] , Common Vulnerabilities and Exposures [33] , Open Source Vulnerability Database [34] . Sårbarhet för "XXE-attacker" upptäcktes i så välkända produkter som JDK och JRE (6:e versionen, 3:e uppdateringen) [33] [35] , WebKit och webbläsaren baserad på det Safari (3:e versionen) [ 36] [37] , Spring Framework [38] , CakePHP [39] , Adobe Reader (version 7) [40] , Zend Framework [41] , Squiz [42] osv.

Standardisering och specifikationer

URI-filschemat beskrevs först i juni 1994 i den informativa RFC 1630 ("Universal Resource Identifiers in WWW"). I december samma år standardiserades den i RFC 1738 (Uniform Resource Locators (URL)). RFC 1738 beskriver det allmänna URL-formatet och är nu föråldrat, förutom två avsnitt som beskriver fil- och ftp-scheman. Den nya RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), som släpptes 2005, inkorporerade RFC 1738 , gjorde mindre ändringar, men den beskrev inte individuella scheman. Vid den tiden hade nästan alla system från den permanenta sektionen fått sin egen separata standard. Den gamla RFC 1738 angav bara formatet för schemat, men definierade inte reglerna för att tillämpa detta schema och konvertera en lokal sökväg till en URI och vice versa. Det fanns ett behov av att standardisera filschemat, liksom ett antal andra icke-standardiserade scheman.

2004 började Paul Hoffman, som har varit medlem i IETF sedan början av 1990-talet, processen att standardisera filschemat. Under juni skrev han separata specifikationer för filen, ftp, gopher, news och nntp, prospero och telnet-scheman, och den 17 juni 2004 publicerades de på ietf.org-webbplatsen och den 19 juni tillkännagav han det på sändlistan [43] . Den första revisionen av filschemastandarden kallades "The file URI Scheme" [44] . Den 19 juni meddelade Paul Hoffman att utkastet hade påbörjats en aktiv diskussion. Det fanns många kommentarer från IETF-gemenskapen, och den andra revisionen [45] följt av den tredje [46] och den fjärde [47] följde snart . Men någon konsensus nåddes aldrig. För att fortsätta arbeta med standarden skapade Mike Brown en speciell wikisajt https://offset.skew.org/wiki/URI/File_scheme , där man arbetade under en tid för att samla in information om filschemat . Men snart tog denna verksamhet slut, och standarden antogs aldrig.

2013 gör Matthew Kerwin ytterligare ett försök att standardisera filschemat. I juni 2013 publicerades den första revideringen av utkastet [48] , en diskussion om utkastet inleddes och under juni-8 september publicerades ytterligare revisioner. Den senaste (#8, d.v.s. nionde [not 4] ) revisionen av utkastet publicerades den 18 september 2013 [49]

Anteckningar

Kommentarer
  1. ↑ Det här exemplet fungerar bara i Lynx- webbläsaren
  2. ↑ Termen URI dök upp senare, vid den tiden var dess prototyp URL, nedan i artikeln kan URI betyda URL
  3. ↑ Länkar med ett filschema med en icke-lokal värd (dvs. URL:er som pekar på en UNC - sökväg, t.ex. file://dmitryt/public/readme.txt ) fungerade i Internet Explorer upp till version 9, men i en uppdatering fram till version 9.02 , släpptes i augusti 2011, den här funktionen inaktiverades [13]
  4. ↑ IETF-standardutkast är numrerade från 0
Källor
  1. ↑ Uniform Resource Identifier (URI) Schemes Arkiverade 11 oktober 2016 på 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, Frankrike, januari 1992  //  New Computing Techniques in Physics Research. Singapore: World Scientific. - S. 157-164 . Arkiverad från originalet den 24 september 2015.
  3. ↑ URL-scheman som stöds i Lynx. Filens URL.  (engelska) . Lynx användarhandbok . http://lynx.isc.org+ (5 juli 2009). Hämtad: 9 oktober 2013.  (inte tillgänglig länk)
  4. ↑ 1 2 T. Berners-Lee, L. Masinter, M. McCahill. 3.10 Filer/Uniform Resource Locators (URL:er  ) . Begäran om kommentarer: 1738 14. IETF (december 1994). Hämtad 6 oktober 2013. Arkiverad från originalet 15 oktober 2013.
  5. ↑ Marcos Caceres. Appen : URI-schema  . W3C (16 maj 2013). Hämtad 8 oktober 2013. Arkiverad från originalet 6 oktober 2013.
  6. ↑ 1 2 3 4 Dave Risney. Fil URI:er i Windows  . MSDN (6 december 2006). Hämtad 16 oktober 2013. Arkiverad från originalet 4 augusti 2013.
  7. ↑ 1 2 Risney, Dave Arkiv URI:er i  Windows . IEBlog . Microsoft Corporation (2013). Hämtad 7 augusti 2013. Arkiverad från original 4 augusti 2013.
  8. ↑ Du kan få ett felmeddelande när du klickar på en hyperlänk som refererar till en fil på din lokala dator eller på ditt lokala nätverk i Internet Explorer  . Microsoft (26 oktober 2007). Hämtad 20 oktober 2013. Arkiverad från originalet 16 januari 2006.
  9. ↑ Bug 70871 - file://hostname/dir/dir/filename - hostname not implemented Arkiverad 21 oktober 2013 på Wayback Machine . (2001-03-04). Mozilla
  10. ↑ Zeke Odins-Lucas. Den bisarra och olyckliga historien om "file : "-webbadresser  . MSDN (19 maj 2005). Datum för åtkomst: 15 oktober 2013. Arkiverad från originalet den 16 januari 2013.
  11. ↑ 1 2 Dave Risney. CreateURLMoniker anses  skadligt . MSDN (14 september 2006). Hämtad 16 oktober 2013. Arkiverad från originalet 17 oktober 2013.
  12. ↑ filprotokoll  . _ MSDN . Hämtad 20 oktober 2013. Arkiverad från originalet 4 maj 2016.
  13. ↑ Eric Law. Uppdatering för Internet Explorer 9.0.2  (engelska) . MSDN (12 augusti 2011). Hämtad 19 oktober 2013. Arkiverad från originalet 20 oktober 2013.
  14. ↑ 1 2 Länkar till lokala sidor fungerar inte  . MozillaZine kunskapsbas . Mozilla . Hämtad 19 oktober 2013. Arkiverad från originalet 20 oktober 2013.
  15. ↑ 1 2 Bug 122022 - (file://) [ISSUE] file:// URLs i en http | https-sidan fungerar inte (att klicka gör ingenting, ladda inte automatiskt, etc.) . Bugzilla@Mozilla . Mozilla (26 januari 2002). Datum för åtkomst: 20 oktober 2013. Arkiverad från originalet 24 oktober 2013.
  16. ↑ A. Barth, C. Jackson, C. Reis och Google Chrome Team. Chromium-webbläsarens säkerhetsarkitektur  :  Teknisk rapport. — Stanford University, 2008. — S. 6 . Arkiverad från originalet den 7 september 2011.
  17. ↑ Šilić, M.; Krolo, J.; Delac, G. Säkerhetssårbarheter i modern webbläsararkitektur  //  MIPRO, 2010 Proceedings of the 33rd International Convention. - Opatija, Kroatien, 2010. - P. 1240-1245 . — ISBN 978-1-4244-7763-0 . Arkiverad från originalet den 24 oktober 2022.
  18. ↑ CVE -2009-1839  . Vanliga sårbarheter och exponeringar (29 maj 2009). Datum för åtkomst: 19 oktober 2013. Arkiverad från originalet den 2 april 2015.
  19. ↑ Bug 230606 - Skärp samma ursprungspolicy för lokala filer (fil: URLs, betrodd, säkerhet) . Bugzilla@Mozilla . Mozilla (10 januari 2004). Hämtad 20 oktober 2013. Arkiverad från originalet 25 april 2014.
  20. ↑ Policy för samma ursprung för fil: URI:er  (engelska)  (nedlänk) . Mozillas utvecklarnätverk . Datum för åtkomst: 20 oktober 2013. Arkiverad från originalet den 16 augusti 2013.
  21. ↑ Adam Barth. Säkerhet på djupet: lokala  webbsidor . Chromium (4 december 2008). Hämtad 20 oktober 2013. Arkiverad från originalet 27 oktober 2013.
  22. ↑ Utgåva 4197: Begränsa åtkomsten till filens  URL ytterligare . Google . Datum för åtkomst: 20 oktober 2013. Arkiverad från originalet 24 oktober 2013.
  23. ↑ Utgåva 47416: Tillåt att ett katalogträd behandlas som ett enda ursprung (lossa filen: URL-begränsningar  ) . Google . Datum för åtkomst: 20 oktober 2013. Arkiverad från originalet 24 oktober 2013.
  24. ↑ Michal Zalewski. Handbok för webbläsarsäkerhet, del  2 . Google (10 december 2008). Hämtad 20 oktober 2013. Arkiverad från originalet 19 augusti 2016.
  25. ↑ Michal Zalewski. Tillkännage "Webbläsarsäkerhetshandbok  " . Google Online Security Blog (10 december 2008). Hämtad 20 oktober 2013. Arkiverad från originalet 25 april 2014.
  26. ↑ CWE-611: Felaktig begränsning av XML External Entity Reference ('XXE'  ) . Hämtad 7 november 2013. Arkiverad från originalet 30 mars 2020.
  27. ↑ CAPEC-201: Extern  enhetsattack . Hämtad 7 november 2013. Arkiverad från originalet 5 december 2013.
  28. ↑ Elliot Rusty Harold, W. Scott Means. xml. Referens = XML i ett nötskal, andra upplagan / Per. från engelska - St Petersburg. : Symbol-Plus, 2002. - S.  76 -80. — 576 sid. - ISBN 5-93286-025-1 .
  29. ↑ 1 2 Steuck, Gregory XXE (Xml eXternal Entity)  attack . www.securityfocus.com (29 oktober 2002). Hämtad 25 oktober 2013. Arkiverad från originalet 29 oktober 2013.
  30. ↑ Wilson, John Dereferencing Namespace URIs anses skadliga  . XML-DEV e-postlista (1 januari 2001). Hämtad: 12 oktober 2013.
  31. ↑ Sabin, Miles Ses på BugTraq : XXE (Xml eXternal Entity) attack  . XML-DEV e-postlista (30 oktober 2002). Hämtad: 12 oktober 2013.
  32. ↑ Sammanfattning av sårbarheter för CVE-2008-0628  (odefinierad) . Hämtad 7 november 2013. Arkiverad från originalet 2 juni 2013.
  33. ↑ 12 CVE - 2008-0628 . Hämtad 7 november 2013. Arkiverad från originalet 4 mars 2016. 
  34. ↑ 68033 : Splunk XML Parser XML External Entity (XXE) Ospecificerad fjärrprivilegieupptrappning  . Hämtad: 7 november 2013.  (otillgänglig länk)
  35. ↑ Chris Evans. Sun JDK6 bryter XXE-  attackskyddet . http://scary.beasts.org+(2007).+ Hämtad 7 november 2013. Arkiverad från originalet 10 januari 2013.
  36. ↑ Dmitrij Dokuchaev. Exploatöversikt  // Hacker . - 2009. - Utgåva. 127 , nr 07 . - S. 44-50 . Arkiverad från originalet den 25 april 2014.
  37. ↑ Sårbarhet för lokal filstöld i Apple Safari  . www.securityfocus.com (9 juni 2009). Hämtad 7 november 2013. Arkiverad från originalet 4 mars 2016.
  38. ↑ CVE-2013-4152 XML External Entity (XXE)-injektion i Spring  Framework . www.securityfocus.com (22 augusti 2013). Hämtad 7 november 2013. Arkiverad från originalet 7 september 2013.
  39. ↑ CakePHP 2.x-2.2.0-RC2 XXE  Injection . www.securityfocus.com (16 juli 2012). Hämtad 7 november 2013. Arkiverad från originalet 10 oktober 2012.
  40. ↑ Sverre H. Huseby. Adobe Reader 7 : XML External Entity (XXE) Attack  . www.securityfocus.com (16 juni 2005). Hämtad 7 november 2013. Arkiverad från originalet 4 mars 2016.
  41. ↑ SEC Consult SA-20120626-0 :: Zend Framework - Lokal filavslöjande via XXE-  injektion . www.securityfocus.com (26 juni 2012). Hämtad 7 november 2013. Arkiverad från originalet 7 juli 2012.
  42. ↑ Squiz CMS Multiple Vulnerabilities - Säkerhetsrådgivning - SOS-  12-007 . www.securityfocus.com (18 juni 2012). Hämtad 7 november 2013. Arkiverad från originalet 4 mars 2016.
  43. ↑ Hoffman, Paul Historiska schemautkast  . [email protected] e-postlista (19 augusti 2004). Hämtad: 26 september 2013.
  44. ↑ P. Hoffman. Filen URI  Scheme . IETF (17 augusti 2004). Hämtad 6 oktober 2013. Arkiverad från originalet 13 september 2014.
  45. ↑ P. Hoffman. Filen URI  Scheme . IETF (18 september 2004). Hämtad 6 oktober 2013. Arkiverad från originalet 13 september 2014.
  46. ↑ P. Hoffman. Filen URI  Scheme . IETF (30 november 2004). Hämtad 6 oktober 2013. Arkiverad från originalet 13 september 2014.
  47. ↑ P. Hoffman. Filen URI  Scheme . IETF (januari 2005). Datum för åtkomst: 6 oktober 2013. Arkiverad från originalet den 24 juli 2014.
  48. ↑ M. Kerwin. Filen URI  Scheme . IETF (20 juni 2013). Hämtad 6 oktober 2013. Arkiverad från originalet 4 februari 2015.
  49. ↑ M. Kerwin. Filen URI  Scheme . IETF (18 september 2013). Hämtad 6 oktober 2013. Arkiverad från originalet 4 februari 2015.

Se även

Länkar

 URI- scheman
Officiell
inofficiell