Fájl (URI-séma)

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2021. január 24-én felülvizsgált verziótól ; az ellenőrzésekhez 10 szerkesztés szükséges .

A fájl URI séma  egy RFC 8089 , RFC 1630 , RFC 1738 és RFC 3986 szabványban dokumentált URI séma , amelyet arra terveztek , hogy a helyi számítógépen vagy helyi hálózaton lévő fájlokat a lemezen, hálózati mappában vagy bizonyos esetekben ftp szerveren. Az URI - sémafájl regisztrálva van az IANA URI-séma-nyilvántartásban [1] , és az „Állandó URI-sémák” részben található.

A sémáról

A fájlséma az egyik legrégebbi URI séma . Az internet hajnala óta szoftverekben testesül meg. A WorldWideWeb , az első webböngésző, amelyet 1991-ben Tim Berners-Lee , a World Wide Web feltalálója hozott létre, támogatta a fájlsémát . Az RFC 1630 specifikációt , amelyben először dokumentálták, szintén Tim Berners-Lee írta 1994 júniusában, a W3C létrehozása előtt , és ez az egyik legrégebbi internetes specifikáció.

Az ftp -séma bevezetése előtt a fájlsémát használták az ftp-szervereken található fájlok hivatkozására. Tim Berners-Lee maga javasolta a fájlséma használatát az URL - ben az ftp protokollon keresztül elérhető fájlok hivatkozásainál , és maga is használt ilyen hivatkozásokat publikációi [2] Hivatkozások részében . A Lynx böngésző , az egyik legrégebbi fennmaradt böngésző, a fájl [3] sémájának ezt az értelmezését a mai napig megőrizte .

A legtöbb ismert sémától eltérően (pl. http, nfs, sip, telnet stb.) a fájlséma nem protokoll. Ezt az RFC 1738 kifejezetten kimondja : "Ennek a sémának az egyik jellemzője, hogy nem határoz meg internetprotokollt vagy fájlelérési módot, így a hosztok közötti hálózati protokollokban korlátozott a használata" [4] . A fájlséma egyszerűen megadja a fájl elérési útját URL-ként ( vagy URI-ként) egy adott gépen. Azt is mondja, hogy "ez a séma, ellentétben a legtöbb más URL-sémával, nem határoz meg olyan erőforrást, amely nyilvánosan elérhető az interneten."

A fájlsémát minden népszerű böngésző támogatja, minden operációs rendszeren, bár egy nagyon régi szabványon alapul, amely leírja az URL formátumot, de még nincs saját. De a fenti tulajdonságok miatt használata korlátozott. A címsávban működik, de ez a séma szinte soha nem található meg a webhelyek HTML -jelölésében. Egy új sémát , az alkalmazást fejlesztettek ki a fájl lecserélésére . Az alkalmazássémát a 2013. május 16-i W3C -ajánlás írja le [5]

Formátum

A sémafájlt tartalmazó URL formátuma [4] :

file:// <host> / <elérési út>

ahol a gazdagép a teljes képzésű tartománynév azon a rendszeren, ahol elérhető az elérési út , az elérési út pedig egy hierarchikus könyvtár elérési útja a könyvtár / könyvtár /.../ fájlnév formátumban . Ha a gazdagépet kihagyjuk, az alapértelmezett a „localhost”, az a gazdagép, amelyen az URL-t elemzi. 2005 előtt a szabványnak volt egy olyan követelménye, hogy a gazdagép elhagyása esetén a megfelelő perjel vagy dupla perjel nem hagyható ki (a "file:///foo.txt" működik, de a "file://foo.txt" nem fog , bár néhány elemző képes volt kezelni ezt az esetet). A 2005-ben kiadott RFC 3986 megszüntette ezt a követelményt. Az RFC 3986 szerint a jogosultság elhagyása (jelen esetben a host -nak felel meg ) a dupla perjelet (//) is elhagyja.

A perjel jelentése

A perjel (/) az URI-ban elfoglalt pozíciótól függően eltérő jelentéssel bír.

  1. A fájl: séma után a dupla perjel (//) az URL szintaxis része, és a jogosultság megadásakor szükséges (a gazdagép mező jogosultságként működik).
  2. A gazdagép és az elérési út közötti perjel szintén része az URL szintaxisának, bár Unix rendszereken az elérési út része lehet , vagy elhagyható, ha a megadott elérési út relatív, azaz ""-vel kezdődik. vagy "...".
  3. A fennmaradó perjelek elválasztják a könyvtárak neveit az elérési út mezőben a helyi számítógép címtárhierarchiájában. Ebben az esetben a perjel az útvonalrészek elválasztásának rendszerfüggetlen módja.

Egyéb URL-összetevők

A bejelentkezési név (felhasználónév), jelszó (jelszó) és port (port) összetevőket nem használják a fájlsémával rendelkező URL-ekben. Ugyanakkor a paraméterek (lekérdezési karakterlánc) és a horgony (töredékazonosító) komponenseket [6] maga az alkalmazás is használhatja, megjelenítve az adott fájl URL-címének tartalmát. Például egy HTML -dokumentumban található szkript képes beolvasni a paramétereket, és egy horgony használható szabványos módon a dokumentumban való navigáláshoz.

Érvényes karakterek és kódolásaik

A fájlok URL-címei karakterkészletben különböznek a hagyományos URL-ektől és a fájlrendszerek fájlútvonalaitól. Mivel a fájlrendszerek elérési útjai tartalmazhatnak az URL-ekben szolgáltatási célból fenntartott karaktereket ('#', '%' stb.), az ilyen karakterek (korábban szóköz is ' ') kódolásra kerülnek, amikor egy elérési utat fájl URL-címmé alakítanak át . Ugyanakkor, ellentétben az URL-lel, a fájl URL-jében ajánlatos idegen ábécé karaktereit használni (vagyis nem az US-ASCII táblából) úgy, ahogy van, azaz URL-kódolás nélkül [6] . Ennek az az oka, hogy a fájl URL-jében található URL-kódolású oktetteket a rendszer bájtként kezeli a felhasználó aktuális kódlapján, ami azt jelenti, hogy az URL értéke attól függően változik, hogy a dokumentumot milyen nyelven tekintik meg [6] .

Példák

UNIX és UNIX-szerű operációs rendszerek

4 Unix példa , amely ugyanarra az / etc / fstab fájlra mutat :

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

Példa az rfc959.txt fájlra mutató hivatkozásra, amely az nnsc.nsf.net ftp-kiszolgálón található [Megjegyzés. 1] :

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

2 példa Mac OS rendszeren , amelyek ugyanarra a /var/log/system.log fájlra mutatnak :

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

Példák a Windows alkalmazások által támogatott elérési utakra, amelyek a c: \ WINDOWS \ clock.avi fájlra mutatnak :

file://localhost/c|/WINDOWS/clock.avi file:///c|/WINDOWS/clock.avi file://localhost/c:/WINDOWS/clock.avi file:///c:/WINDOWS/clock.avi

Példa a start.swf fájl elérési útjára, amely a hálózati mappatermékekben található egy applib [7] nevű számítógépen :

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

Példafájl URI %-kódolt karakterekkel és Unicode karakterrel [7] (Internet Explorer 6 és 7 esetén előfordulhat, hogy a %20 példa nem működik [8] ):

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

A fájlséma és a böngészők

Böngésző Fájlséma támogatás (localhost) Üres gazdagép ( file:/// ) Hálózati gazdagép Meghajtóbetűjel az útvonalban ( C: ) [Pl. v. 1] Mappa áttekintése URL kódolt karakterek fájl hivatkozások html -ben
Google Chrome Igen Igen GYŐZ Igen Igen Igen Igen
internet böngésző Igen Igen GYŐZ Igen Nem Igen Igen
Konqueror Igen Igen ? - Igen Igen Igen
Hiúz Igen Igen FTP Igen Igen Igen Igen
Mozilla Firefox Igen Igen WINS [Pl. 2. v.] Igen Igen Igen Igen
Opera Igen Igen GYŐZ Igen Igen Igen Igen
szafari Igen ? ? - Nem ? ?
Yandex böngésző Igen Igen GYŐZ Igen Igen Igen Igen
Táblázat megjegyzései
  1. ↑ Csak a Windowst támogató böngészőkhöz
  2. ↑ Az általánosan megadott elérési út ( file://hostname/share/path/to/a/file ) nem működik a Mozilla Firefoxban, de beállíthatja a következőre: file://///hostname/share/path/to/a /fájl . 2001-ben a Mozilla bevezetett egy hibát ezzel kapcsolatban, több évig tárgyalt róla, de nem javították ki (ésszerű megoldást nem találtak) [9]

Windows fájlséma

A fájl URI sémát eredetileg a Windows támogatta, azaz. az URI támogatás megjelenésével [Megjegyzés. 2] általában, és konkrétan az Internet Explorer 1 [10] kiadásával . Az Internet Explorer első verzióját 1995-ben fejlesztették ki, amikor még nem létezett az URL szabvány, és a fájlsémát többféleképpen lehetett értelmezni, ami a böngészővel meg is történt. Különböző moduljai eltérően kezelték a fájlsémát. Átdolgozás után ez a helyzet megszűnt. Létrejött az shlwapi.dll fájl , amelybe az URL-lel való munkavégzéshez szükséges összes kódot elhelyezték. Az átdolgozás során a fájlséma két formáját egyeztették: az egyik az URL szabvány szerint, a másik egy régi forma, amely a DOS idejéből származott. A Microsoft alkalmazottai örökölt fájl URL-nek (elavult fájl URL-nek) nevezték el. Példák a régi fájl URL-jére:

Fájl elérési útja: c:\windows\My Documents 100%20\foo.txt A régi fájl URL-je: file://c:\windows\My Documents 100%20\foo.txt Szabványos fájl URL-címe: file:///c:/windows/My%20Documents%20100%2520/foo.txt Fájl elérési útja: \\server\share\My Documents 100%20\foo.txt A régi fájl URL-je: file://\\server\share\My Documents 100%20\foo.txt Szabványos fájl URL-cím: file://server/share/My%20Documents%20100%2520/foo.txt

Az új dll mind az új, mind a régi fájl URL-eket helyesen kezeli, ezért a PathCreateFromUrl() és UrlCreateFromPath() függvényei a Windows elérési utak és a fájl URL-ek közötti konvertáláshoz ajánlottak [6] [11] .

Ezeken a függvényeken kívül az urlmon.dll-ben létrejött a CreateURLMoniker() függvény ( Internet Explorer 3 -tól kezdve ), hogy egy karakterlánc-URI-t olyan objektummá alakítson át, amellyel az adatok az adott URI-hoz ( moniker ) címezhetők. De ez a funkció okozott némi gondot az URI [11] fájl konvertálásakor is , aminek eredményeként egy új CreateURLMonikerEx() függvény került beépítésre és ajánlott ( Internet Explorer 5.5 -től kezdődően ), melyben ezeket a problémákat kijavították. Az Internet Explorer 7 kiadásával egy másik CreateURLMonikerEx2() függvény is bekerült, amely támogatja a relatív elérési utat.

Biztonsági problémák

A szkriptnyelvek , például a JavaScript böngészők támogatásának megjelenésével és elterjedésével számos, a fájlséma használatával kapcsolatos sebezhetőséget fedeztek fel. Ennek eredményeként a böngészőgyártók számos beépített böngészőkorlátozást vezettek be a fájl URL-ek használatára vonatkozóan.

Főbb fájl-URI-val kapcsolatos böngészősebezhetőségek

A HTTP-n keresztül betöltött HTML-dokumentumokban a fájlsémára mutató hivatkozások nem működnek szinte minden népszerű böngészőben: Internet Explorer (6-os SP1-től) [12] [Megjegyzés. 3] , Mozilla Firefox [14] [15] , Chromium [16] és Google Chrome [17] , Safari , Opera . Az ilyen hivatkozásokra kattintva nem navigál, és nem jelenik meg hibaüzenet, bár előfordulhat, hogy a hibaüzenet naplózásra kerül a hibakonzolon. Ezenkívül a fájl URL-címén található tartalom nem töltődik be a HTTP URL-címen betöltött HTML-dokumentumok kereteibe. Ezt a biztonsági szabályzatot azért vezették be, mert az ilyen hivatkozások számos sebezhetőséget okoznak:

  • A támadó webhelyén tárolt HTML-dokumentum fájlokat tölthet le a felhasználó számítógépére az URL-címek használatával, majd elküldheti azokat a támadó által vezérelt szerverre. A támadó hozzáfér a felhasználó bizalmas adataihoz;
  • Sok böngésző és böngészőbővítmény előre látható helyen tárolja ideiglenes fájljait és gyorsítótárát a lemezen. A támadó a böngésző normál működése során először elhelyezhet egy HTML-fájlt ezen helyek egyikén (a támadó egy ellenőrzött webhelyen kérheti, hogy mentse a weboldalt lemezre, vagy küldje el egy archívumban e-mailre), majd megpróbálja megnyitni. egy speciálisan elkészített fájl URL-en keresztül. A helyileg (fájl URL-címén keresztül) megnyitott HTML-dokumentum több jogosultsággal rendelkezik, mint egy távoli, és hozzáférhet a felhasználó érzékeny adataihoz és egyéb nemkívánatos műveleteket is végrehajthat. Ezt a támadási módszert "fájl-URL-fájl-URL-szkriptnek" is nevezik [18] . Ezenkívül a felhasználó a számítógépén helyileg is megnyithat egy káros html dokumentumot.
  • Egy helyileg megnyitott html-fájl betölthet egy távoli weboldalt egy iframe-be (mivel a számítógépen lévő helyi fájlok nem tartoznak a webhelyekre vonatkozó tartománykorlátozási szabály hatálya alá ), például egy e-mail webhely, ahol a felhasználó már be van jelentkezve, és így hozzáférhet az interneten található bizalmas felhasználói adatok.

A második sebezhetőség leküzdése érdekében bevezették a „ Domain korlátozási szabály ” ( azonos származási szabályzat ) elnevezésű szabályzatot is, hasonlóan a http zónában lévő webhelyekre korábban bevezetett azonos nevű szabályzathoz. A Mozilla Firefox, amely 2007-ben vezette be ezt az irányelvet a böngésző 3-as verziójában ( Gecko 1.9 motor), az elsők között tette ezt meg (3 évbe telt, amíg a Firefox fejlesztői megvitatták és végrehajtották ezt az irányelvet [19] ). E szabály szerint egy fájl csak akkor tud másik fájlt olvasni, ha a forrásfájl szülőkönyvtára a célfájl szuperkönyvtára [20] . A Microsoft korábban szigorúbb volt, és általában letiltotta a Javascript végrehajtását a helyi fájlok megnyitásakor, kezdve az Internet Explorer 6 -tal a Windows XP SP2 rendszerben, és lehetővé tette a felhasználók számára, hogy a szkriptet egy előugró menüből egy speciális parancs kiválasztásával hajtsák végre. A Safari 3.2 nem teszi lehetővé a felhasználó számára, hogy a címsoron kívül más forrásból nyissa meg a helyi fájlok URL-címeit. Az Opera 9.6 nem teszi lehetővé a helyi html oldalak távoli tartalom betöltését (de ez nem véd az ellen, hogy egy támadó hozzáférjen a számítógépen lévő adatokhoz). A Chromium (és a függő Google Chrome) az Operához hasonló házirendet implementált [21] , és figyelembe vette a Firefox szabályzatát is, de később még szigorúbb szabályzatot [22] vezetett be azzal, hogy letiltotta a fájlok URL-címét a helyi weboldalakon a szkriptekhez. minden (később úgy döntöttek, hogy lazítanak ezen a politikán).

Számos panasz érkezett ezekre a korlátozásokra, mivel zavarják a helyi webhelyeket és webcímtárakat, amelyeket számos vállalati és helyi hálózatban széles körben használnak, CD-terjesztésben, e-mail mellékletekben, és a webfejlesztők is használják hibakeresésre. webhelyek. Például több tucat duplikált bugot vezettek be ezzel kapcsolatban a Mozillában [15] . Ezért a böngészők támogatják a házirend megkerülését, letiltását vagy konfigurálását, és megjelentek olyan cikkek, amelyek ennek módját javasolják. Tehát az Internet Explorerben ezt a házirendet a „Sajátgép” zóna beállításainál a „Kisebb kiváltságokkal rendelkező webtartalom zónában lévő webhelyek navigálhatnak ebbe a zónába” paraméterrel konfigurálják. Ezenkívül ez a tilalom megkerülhető olyan webhelyek hozzáadásával, amelyek ne okozzon aggodalmat az Internet Explorer megbízható helyek zónájának . A Mozilla Firefoxban ez a tiltás megkerülhető a LocalLink, Local Filesystem Links, IE Tab kiterjesztéssel; vagy egy speciális biztonsági házirend-beállítás (egy speciális zóna jön létre a webhelyek egy csoportjához saját speciális biztonsági beállításokkal) [14] . A Google Chrome 7-es verziójától kezdődően ez a korlátozás megkerülhető a böngésző --allow-file-access-from-files jelzővel történő elindításával vagy a LocalLinks bővítmény használatával. A Chromium számos panasz eredményeként úgy döntött, hogy enyhíti a " Domain Restriction Rule " szabályait a fájlok URL-jére [23] .

Biztonsági szabályzat korlátozásai a böngészőkben

A böngészők biztonsági szabályzatának fő korlátait a táblázat tartalmazza [Megjegyzés 2. 1] .

Teszt leírása MSIE6 [Megjegyzés v.2. 2] MSIE7 [Megjegyzés v.2. 3] MSIE8 [Megjegyzés v.2. négy] FF2 [Megjegyzés v.2. 5] FF3 [Megjegyzés v.2. 6] Safari [Megjegyzés v.2. 7] Opera [Megjegyzés v.2. nyolc] Chrome [Megjegyzés v.2. 9]
A helyi HTML-ek hozzáférhetnek nem kapcsolódó helyi fájlokhoz a DOM-on keresztül? Igen Igen Igen Igen Nem Nem Igen Nem
A helyi HTML-ek hozzáférhetnek a nem kapcsolódó helyi fájlokhoz az XMLHttpRequest segítségével? Nem Nem Nem Igen Nem Nem Igen Nem
A helyi HTML-ek hozzáférhetnek az internet webhelyeihez az XMLHttpRequest segítségével? Igen Igen Igen Nem Nem Nem Nem Nem
Működik a document.cookie a fájl URL-címével? Igen Igen Igen Igen Igen Igen Igen Nem
Letölthető az <IMG> címke URI fájllal? Igen Igen Igen Nem Nem Nem Nem Nem
Letölthető a <SCRIPT> címke URI fájllal? Igen Igen Igen Nem Nem Nem Nem Nem
Letölthető az <IFRAME> címke URI fájllal? Igen Igen Igen Nem Nem Nem Nem Nem
Be lehet tölteni az <EMBED> címkét egy fájl URI-val? Nem Nem Nem Nem Nem Nem Nem Nem
Megengedett az <APPLET> címke betöltése URI fájllal? Igen Igen Igen Nem Nem Igen Nem Igen
Lehet stílusokat (stíluslapot) betölteni az URI fájlon keresztül? Igen Igen Igen Nem Nem Nem Nem Nem
Engedélyezett-e a helyátirányítás az URI fájlon keresztül? Nem Nem Nem Nem Nem Nem Nem Nem
Engedélyezettek a Refresh átirányítások az URI-n keresztül? Nem Nem Nem Nem Nem Nem Nem Nem
Táblázat megjegyzései
  1. ↑ A táblázatban szereplő adatok minden böngészőre vonatkozóan, hacsak másképp nem jelezzük, Michal Zalewski "Böngészőbiztonsági kézikönyvéből" [24] származnak , amelynek fő anyaga még 2008-ban készült [25] , és lehet, hogy az újabbak számára nem releváns. böngészők verziói
  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

Az  XXE ( Xml eXternal Entity ) támadás az egyik leghíresebb sebezhetőség az interneten. A sérülékenységek ezen osztálya a legnagyobb sebezhetőségi katalógusokban található: Common Weakness Enumeration [26] és CAPEC [27] . A támadás lényege a következő. Vannak olyan szolgáltatások, amelyek támogatják a SOAP és XML-RPC protokollokat , amelyek XML dokumentum formájában fogadják a bemenetet . Az XML dokumentumszabvány támogatja a DTD szakasz beépítését, a DTD szekciók pedig további komponenseket, úgynevezett külső entitásokat kapcsolhatnak a dokumentumhoz [ 28 ] .  A külső entitások külön fájlok, és a SYSTEM kulcsszóval és URI-val vannak megadva. Ha az XML-elemző nem érvényesít, egyszerűen betöltheti a külső entitást, és csatolhatja az XML-dokumentum tartalmához. A támadó a külső entitásfájl URI-jában helyettesítheti a számítógép hardvereszközére vagy a rendszerben lévő helyi fájlra mutató URI-t. A szerver megpróbálja beolvasni a fájlt a megadott URI-n, és belefoglalja a tartalmát az XML-be. Egy ilyen mechanizmus használatakor a következő típusú támadások lehetségesek [29] :

  • DoS (szolgáltatásmegtagadás) támadás egy kiszolgáló ellen olyan rendszereszköz elérésével, mint a /dev/urandom vagy;
  • jogosulatlan hozzáférés a privát szerverfájlokhoz, például /etc/passwd vagy c:/winnt/win.ini ;
  • a TCP portok vizsgálata (még a tűzfal megkerülésével is);
  • DoS-támadás más rendszerek ellen (ha az elemző engedélyezi a TCP-kapcsolatokat más rendszerekhez)
  • NTLM hitelesítési anyagok ellopása, amelyet a támadó irányítása alatt álló rendszer UNC -hívása kezdeményezett;
  • Doomsday forgatókönyv: A biztonsági rés által érintett, széles körben telepített, erősen összekapcsolt szerveralkalmazások használhatók DDoS (Distributed Denial of Service) támadásokhoz.

A http://xml.org közösségben (az OWASP non-profit szervezet webhelye) található XXE sebezhetőségről 2001 óta beszélnek [30] , de ezek csak elméleti gondolatok voltak egy ilyen jellegű támadás lehetőségéről. Az első személy, aki felhívta a nyilvánosság figyelmét erre a sebezhetőségre, Gregory Steuck volt [31 ] .  2002-ben biztonsági tanácsot (security manual ) küldött a www.securityfocus.com [29] címre , amelyben részletesen leírta a sérülékenységet, és az XXE Attack nevet adta neki . 

Sok terméket érintett az XXE támadás. A szoftversérülékenységek összes jelentős adatbázisa találhat XXE támadásokkal szemben sérülékeny szoftvertermékeket: National Vulnerability Database [32] , Common Vulnerability and Exposures [33] , Open Source Vulnerability Database [34] . Az "XXE támadásokkal" szembeni sebezhetőséget olyan ismert termékeknél fedezték fel, mint a JDK és a JRE (6. verzió, 3. frissítés) [33] [35] , a WebKit és az arra épülő böngésző Safari (3. verzió) [36] [37] , Spring Framework [38] , CakePHP [39] , Adobe Reader (7-es verzió) [40] , Zend Framework [41] , Squiz [42] stb.

Szabványosítás és specifikációk

Az URI fájlsémát először 1994 júniusában írták le az RFC 1630 ("Universal Resource Identifiers in WWW") tájékoztató jellegű dokumentumban. Ugyanezen év decemberében szabványosították az RFC 1738 -ban (Uniform Resource Locators (URL)). Az RFC 1738 az általános URL-formátumot írja le, és mára elavult, kivéve két szakaszt, amelyek a fájl- és ftp-sémákat írják le. A 2005-ben kiadott új RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), amely magában foglalta az RFC 1738 -at , kisebb változtatásokat végzett, de nem írt le egyedi sémákat. Addigra az állandó részleg szinte minden rendszere megkapta a saját szabványát. A régi RFC 1738 csak a séma formátumát írta elő, de nem határozta meg a séma alkalmazásának szabályait, valamint a helyi elérési út URI-vé alakítását és fordítva. Szükség volt a fájlséma szabványosítására, valamint számos más, nem szabványosított sémára.

2004-ben Paul Hoffman, aki az 1990-es évek eleje óta tagja az IETF-nek, megkezdte a fájlséma szabványosításának folyamatát. Június folyamán külön specifikációkat írt a fájl, ftp, gopher, news és nntp, prospero és telnet sémákhoz, majd 2004. június 17-én közzétették az ietf.org weboldalon, majd június 19-én bejelentette. a levelezőlistán [43] . A fájlséma-szabvány első változatának neve "The file URI Scheme" [44] volt . Június 19-én Paul Hoffman bejelentette, hogy a tervezet aktív vitát kezdett. Sok megjegyzés érkezett az IETF közösségétől, és hamarosan a második verzió [45] , majd a harmadik [46] és a negyedik [47] következett . De soha nem sikerült konszenzusra jutni. A szabványon való munka folytatásához Mike Brown létrehozott egy speciális wiki webhelyet https://offset.skew.org/wiki/URI/File_scheme , ahol egy ideig dolgoztak a fájlsémával kapcsolatos információk gyűjtésén. De ez a tevékenység hamarosan megszűnt, és a szabványt soha nem fogadták el.

2013-ban Matthew Kerwin újabb kísérletet tesz a fájlséma szabványosítására. 2013 júniusában megjelent a tervezet első revíziója [48] , megkezdődött a tervezet vitája, június-szeptember folyamán pedig további 8 revízió jelent meg. A tervezet legutóbbi (8., azaz kilencedik [4. megjegyzés] ) revíziója 2013. szeptember 18-án jelent meg [49]

Jegyzetek

Hozzászólások
  1. ↑ Ez a példa csak a Lynx böngészőben működik
  2. ↑ Az URI kifejezés később jelent meg, akkoriban a prototípusa URL volt, a továbbiakban a cikkben az URI URL-t jelenthet
  3. ↑ A nem helyi gazdagéppel rendelkező fájlsémát tartalmazó hivatkozások (azaz UNC elérési útra mutató URL-ek , pl. file://dmitryt/public/readme.txt ) működtek az Internet Explorerben a 9-es verzióig, de a frissítésben a 9.02-es verzióig , amelyet 2011 augusztusában adtak ki, ezt a funkciót letiltották [13]
  4. ↑ Az IETF szabványtervezetek 0-tól vannak számozva
Források
  1. ↑ Egységes erőforrás-azonosító (URI) sémák archiválva 2016. október 11-én a Wayback Machine -nél ( 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, Franciaország, 1992. január  //  New Computing Techniques in Physics Research. Szingapúr: World Scientific. - 157-164 . o . Az eredetiből archiválva : 2015. szeptember 24.
  3. ↑ A Lynx által támogatott URL-sémák A fájl URL-je.  (angol) . Lynx felhasználói kézikönyv . http://lynx.isc.org+ ( 2009. július 5.). Letöltve: 2013. október 9.  (nem elérhető link)
  4. ↑ 1 2 T. Berners-Lee, L. Masinter, M. McCahill. 3.10 Fájlok / Egységes erőforrás-keresők (URL-ek  ) . Hozzászólások kérése: 1738 14. IETF (1994. december). Letöltve: 2013. október 6. Az eredetiből archiválva : 2013. október 15..
  5. ↑ Marcos Caceres. Az alkalmazás : URI-séma  . W3C (2013. május 16.). Letöltve: 2013. október 8. Az eredetiből archiválva : 2013. október 6..
  6. ↑ 1 2 3 4 Dave Risney. Fájl-URI-k a Windows rendszerben  . MSDN (2006. december 6.). Letöltve: 2013. október 16. Az eredetiből archiválva : 2013. augusztus 4..
  7. ↑ 1 2 Risney, Dave fájl URI-k a  Windowsban . IEBlog . Microsoft Corporation (2013). Letöltve: 2013. augusztus 7. Az eredetiből archiválva : 2013. augusztus 4..
  8. ↑ Hibaüzenet jelenhet meg, ha az Internet Explorer programban  a helyi számítógépén vagy a helyi hálózatán lévő fájlra hivatkozó hivatkozásra kattint . Microsoft (2007. október 26.). Letöltve: 2013. október 20. Az eredetiből archiválva : 2006. január 16..
  9. ↑ 70871 hiba - file://hostname/dir/dir/filename - hosztnév nincs implementálva Archiválva 2013. október 21-én a Wayback Machine -nél . (2001-03-04). Mozilla
  10. ↑ Zeke Odins-Lucas. A "file : " URL-ek  bizarr és boldogtalan története . MSDN (2005. május 19.). Hozzáférés időpontja: 2013. október 15. Az eredetiből archiválva : 2013. január 16.
  11. ↑ 1 2 Dave Risney. CreateURLMoniker  ártalmasnak tekinthető . MSDN (2006. szeptember 14.). Letöltve: 2013. október 16. Az eredetiből archiválva : 2013. október 17..
  12. ↑ fájl protokoll  . MSDN . Letöltve: 2013. október 20. Az eredetiből archiválva : 2016. május 4..
  13. ↑ Eric Law. Internet Explorer 9.0.2 frissítés  (angol) . MSDN (2011. augusztus 12.). Letöltve: 2013. október 19. Az eredetiből archiválva : 2013. október 20..
  14. ↑ 1 2 A helyi oldalakra mutató hivatkozások nem  működnek . MozillaZine Tudásbázis . Mozilla . Letöltve: 2013. október 19. Az eredetiből archiválva : 2013. október 20..
  15. ↑ 1 2 122022-es hiba - (file://) [ISSUE] file:// URL-ek egy http | A https oldal nem működik (a kattintás nem csinál semmit, nem tölt be automatikusan stb. ) Bugzilla@Mozilla . Mozilla (2002. január 26.). Hozzáférés dátuma: 2013. október 20. Az eredetiből archiválva : 2013. október 24.
  16. ↑ A. Barth, C. Jackson, C. Reis és a Google Chrome csapata. A Chromium Browser biztonsági architektúrája  :  Műszaki jelentés. - Stanford University, 2008. - 6. o . Archiválva az eredetiből 2011. szeptember 7-én.
  17. ↑ Šilić, M.; Krolo, J.; Delac, G. Biztonsági sebezhetőségek a modern webböngésző-architektúrában  //  MIPRO, 2010 Proceedings of the 33rd International Convention. - Opatija, Horvátország, 2010. - P. 1240-1245 . — ISBN 978-1-4244-7763-0 . Archiválva az eredetiből 2022. október 24-én.
  18. ↑ CVE -2009-1839  . Gyakori sebezhetőségek és kitettségek (2009. május 29.). Hozzáférés időpontja: 2013. október 19. Az eredetiből archiválva : 2015. április 2..
  19. ↑ 230606. hiba - Szigorítsa meg az azonos eredetű házirendet a helyi fájlokhoz (fájl: URL-ek, megbízható, biztonság) . Bugzilla@Mozilla . Mozilla (2004. január 10.). Letöltve: 2013. október 20. Az eredetiből archiválva : 2014. április 25..
  20. ↑ Azonos eredetű szabályzat a fájlhoz: URI-k  (angol)  (lefelé mutató hivatkozás) . Mozilla fejlesztői hálózat . Hozzáférés dátuma: 2013. október 20. Az eredetiből archiválva : 2013. augusztus 16.
  21. ↑ Barth Ádám. Mélyreható biztonság: Helyi  weboldalak . Chromium (2008. december 4.). Letöltve: 2013. október 20. Az eredetiből archiválva : 2013. október 27..
  22. ↑ 4197. probléma: A fájl  URL -címéhez való hozzáférés további korlátozása . Google . Hozzáférés dátuma: 2013. október 20. Az eredetiből archiválva : 2013. október 24.
  23. ↑ 47416. probléma: Engedélyezze a könyvtárfa egyetlen eredetként való kezelését (fájl lazítása: URL-korlátozások  ) . Google . Hozzáférés dátuma: 2013. október 20. Az eredetiből archiválva : 2013. október 24.
  24. ↑ Michal Zalewski. Böngészőbiztonsági kézikönyv,  2. rész . Google (2008. december 10.). Letöltve: 2013. október 20. Az eredetiből archiválva : 2016. augusztus 19..
  25. ↑ Michal Zalewski. A "Böngészőbiztonsági kézikönyv  " bejelentése . Google Online Security Blog (2008. december 10.). Letöltve: 2013. október 20. Az eredetiből archiválva : 2014. április 25..
  26. ↑ CWE-611: Az XML külső entitáshivatkozás helytelen korlátozása ('XXE'  ) . Letöltve: 2013. november 7. Az eredetiből archiválva : 2020. március 30.
  27. ↑ CAPEC-201: Külső entitások  támadása . Letöltve: 2013. november 7. Az eredetiből archiválva : 2013. december 5..
  28. ↑ Elliot Rusty Harold, W. Scott Means. xml. Hivatkozás = XML dióhéjban, második kiadás / Per. angolból – Szentpétervár. : Symbol-Plus, 2002. - S.  76 -80. — 576 p. - ISBN 5-93286-025-1 .
  29. ↑ 1 2 Steuck, Gregory XXE (Xml eXternal Entity)  támadása . www.securityfocus.com (2002. október 29.). Letöltve: 2013. október 25. archiválva az eredetiből: 2013. október 29.
  30. ↑ Wilson, John Károsnak ítélt névtér-URI  -k hivatkozásának megszüntetése . XML-DEV levelezőlista (2001. január 1.). Letöltve: 2013. október 12.
  31. ↑ Sabin, Miles Seen on BugTraq : XXE (Xml eXternal Entity) támadás  . XML-DEV levelezőlista (2002. október 30.). Letöltve: 2013. október 12.
  32. ↑ Sebezhetőségi összefoglaló a CVE-2008-0628-hoz  (undefined) . Letöltve: 2013. november 7. Az eredetiből archiválva : 2013. június 2.
  33. ↑ 12 CVE - 2008-0628 . Letöltve: 2013. november 7. Az eredetiből archiválva : 2016. március 4.. 
  34. ↑ 68033 : Splunk XML Parser XML külső entitás (XXE) meghatározatlan távoli jogosultság eszkaláció  . Letöltve: 2013. november 7.  (elérhetetlen link)
  35. ↑ Chris Evans. A Sun JDK6 megszakítja az XXE  támadásvédelmet . http://scary.beasts.org+(2007).+ Letöltve: 2013. november 7. Az eredetiből archiválva : 2013. január 10..
  36. ↑ Dmitrij Dokucsajev. Exploit áttekintése  // Hacker . - 2009. - Kiadás. 127 , 07. sz . - S. 44-50 . Archiválva az eredetiből 2014. április 25-én.
  37. ↑ Az Apple Safari helyi fájllopás elleni  sebezhetősége . www.securityfocus.com (2009. június 9.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2016. március 4..
  38. ↑ CVE-2013-4152 XML külső entitás (XXE) injekció a Spring  Frameworkben . www.securityfocus.com (2013. augusztus 22.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2013. szeptember 7..
  39. ↑ CakePHP 2.x-2.2.0-RC2 XXE  Injekció . www.securityfocus.com (2012. július 16.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2012. október 10.
  40. ↑ Sverre H. Huseby. Adobe Reader 7 : XML külső entitás (XXE) támadás  . www.securityfocus.com (2005. június 16.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2016. március 4..
  41. ↑ SEC Consult SA-20120626-0 :: Zend Framework – Helyi fájlok közzététele XXE  injekción keresztül . www.securityfocus.com (2012. június 26.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2012. július 7.
  42. ↑ Squiz CMS többszörös biztonsági rés – Biztonsági tanács – SOS-  12-007 . www.securityfocus.com (2012. június 18.). Letöltve: 2013. november 7. Az eredetiből archiválva : 2016. március 4..
  43. ↑ Hoffman, Paul Történelmi sémavázlatok  . [email protected] levelezőlista (2004. augusztus 19.). Letöltve: 2013. szeptember 26.
  44. ↑ P. Hoffman. Az URI-  séma fájl . IETF (2004. augusztus 17.). Letöltve: 2013. október 6. Az eredetiből archiválva : 2014. szeptember 13..
  45. ↑ P. Hoffman. Az URI-  séma fájl . IETF (2004. szeptember 18.). Letöltve: 2013. október 6. Az eredetiből archiválva : 2014. szeptember 13..
  46. ↑ P. Hoffman. Az URI-  séma fájl . IETF (2004. november 30.). Letöltve: 2013. október 6. Az eredetiből archiválva : 2014. szeptember 13..
  47. ↑ P. Hoffman. Az URI-  séma fájl . IETF (2005. január). Hozzáférés dátuma: 2013. október 6. Az eredetiből archiválva : 2014. július 24.
  48. ↑ M. Kerwin. Az URI-  séma fájl . IETF (2013. június 20.). Letöltve: 2013. október 6. Az eredetiből archiválva : 2015. február 4..
  49. ↑ M. Kerwin. Az URI-  séma fájl . IETF (2013. szeptember 18.). Letöltve: 2013. október 6. Az eredetiből archiválva : 2015. február 4..

Lásd még

Linkek

 URI- sémák
Hivatalos
nem hivatalos