Tiedosto (URI-malli)

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 24. tammikuuta 2021 tarkistetusta versiosta . tarkastukset vaativat 10 muokkausta .

Tiedoston URI-malli  on RFC 8089 , RFC 1630 , RFC 1738 ja RFC 3986 dokumentoitu URI-malli , joka on suunniteltu osoittamaan paikallisen tietokoneen tai paikallisen verkon tiedostot niiden suoran polun kautta levyllä, verkkokansiossa tai joissakin tapauksissa ftp-palvelimella. URI - skeematiedosto on rekisteröity IANA URI Scheme Registry -rekisteriin [1] ja se on lueteltu "Pysyvät URI-järjestelmät" -osiossa.

Tietoja järjestelmästä

Tiedostomalli on yksi vanhimmista URI - järjestelmistä . Se on sisältynyt ohjelmistoihin Internetin kynnyksellä. WorldWideWeb , ensimmäinen web-selain , jonka World Wide Webin keksijä Tim Berners-Lee loi vuonna 1991, tuki tiedostojärjestelmää . RFC 1630 -spesifikaatio , jossa se ensimmäisen kerran dokumentoitiin, on myös Tim Berners-Leen kirjoittama kesäkuussa 1994, ennen W3C :n luomista , ja se on yksi vanhimmista Internet-spesifikaatioista.

Ennen ftp -mallin käyttöönottoa tiedostomallia käytettiin viittaamaan ftp-palvelimilla sijaitseviin tiedostoihin. Tim Berners-Lee itse ehdotti tiedostomallin käyttöä URL -osoitteessa linkeissä tiedostoihin, joihin pääsee ftp-protokollan kautta , ja hän itse käytti tällaisia ​​linkkejä julkaisujensa Viitteet-osiossa [2] . Lynx - selain , yksi vanhimmista säilyneistä selaimista, on säilyttänyt tämän tulkinnan tiedostoskeemasta [3] tähän päivään asti .

Toisin kuin useimmat tunnetut mallit (esim. http, nfs, sip, telnet jne.), tiedostomalli ei ole protokolla. Tämä on nimenomaisesti todettu RFC 1738 :ssa: "Tämän mallin ominaisuus on, että se ei määritä Internet-protokollaa tai tiedostojen käyttötapaa, joten sen käyttö verkkoprotokollassa isäntien välillä on rajoitettua" [4] . Tiedostomalli yksinkertaisesti määrittää tiedoston polun URL -osoitteena (tai URI-osoitteena) tietyssä koneessa. Siinä sanotaan myös, että "tämä malli, toisin kuin useimmat muut URL-mallit, ei määrittele resurssia, joka on julkisesti saatavilla Internetin kautta."

Tiedostojärjestelmää tukevat kaikki suositut selaimet kaikissa käyttöjärjestelmissä, vaikka se perustuukin hyvin vanhaan URL-muotoa kuvaavaan standardiin, mutta sillä ei vielä ole omaa . Mutta yllä olevien ominaisuuksien vuoksi sen käyttö on rajoitettua. Se toimii osoitepalkissa, mutta tätä mallia ei juuri koskaan löydy verkkosivustojen HTML -merkinnöistä. Uusi malli , sovellus , on kehitetty korvaamaan tiedosto . Sovellusmalli on kuvattu 16. toukokuuta 2013 annetussa W3C - suosituksessa [5]

Muoto

Kaavatiedoston URL-osoite on muotoa [4] :

file:// <isäntä> / <polku>

jossa isäntä on täysin pätevä toimialueen nimi järjestelmässä, jossa polku on käytettävissä , ja polku on hierarkkinen hakemistopolku muodossa hakemisto / hakemisto /.../ tiedostonimi . Jos isäntä jätetään pois, oletusarvo on "localhost", isäntä, jolla URL-osoite jäsennetään. Ennen vuotta 2005 standardissa oli vaatimus, että jos isäntä jätetään pois, niin vastaavaa kauttaviivaa tai kaksoisviivaa ei voi jättää pois ("file:///foo.txt" toimii, mutta "file://foo.txt" ei, vaikka jotkut jäsentimet pystyivät käsittelemään tämän tapauksen). Vuonna 2005 julkaistu RFC 3986 poisti tämän vaatimuksen. RFC 3986 :n mukaan auktoriteetin jättäminen pois (tässä tapauksessa isäntä vastaa ) jättää pois myös kaksoisviivan (//).

Vinoviivan merkitys

Kenoviivalla (/) on eri merkitys riippuen sijainnista URI:ssa.

  1. Kaksoisviiva (//) file: -mallin jälkeen on osa URL -syntaksia ja vaaditaan määritettäessä valtuuksia ( isäntäkenttä toimii auktoriteettina).
  2. Isännän ja polun välinen vinoviiva on myös osa URL-syntaksia, vaikka se voi olla osa polkua Unix-järjestelmissä tai jättää pois, jos määritetty polku on suhteellinen, eli alkaa "." tai "...".
  3. Loput vinoviivat erottavat hakemistojen nimet polkukentässä paikallisen tietokoneen hakemistohierarkiassa. Tässä tapauksessa vinoviiva on järjestelmästä riippumaton tapa erottaa polun osia.

Muut URL-osat

Kirjautumistunnus ( käyttäjänimi), salasana (salasana) ja portti (portti) -komponentteja ei käytetä URL-osoitteissa, joissa on tiedostomalli. Mutta samaan aikaan sovellus itse voi käyttää parametreja (kyselymerkkijono) ja ankkuri (fragmenttitunniste) -komponentteja [6] näyttäen tietyn tiedoston URL-osoitteen sisällön. Esimerkiksi HTML - dokumentin sisällä oleva komentosarja voi lukea parametrit, ja ankkuria voidaan käyttää tavallisella tavalla asiakirjassa navigoimiseen.

Kelvolliset merkit ja niiden koodaukset

Tiedostojen URL-osoitteet eroavat merkistöltä sekä perinteisistä URL-osoitteista että tiedostojärjestelmien tiedostopoluista. Koska tiedostojärjestelmien polut voivat sisältää merkkejä, jotka on varattu URL-osoitteisiin palvelutarkoituksiin ("#", "%" jne.), tällaiset merkit (aiemmin myös välilyönti "") koodataan , kun polku muunnetaan tiedoston URL-osoitteeksi . Mutta samaan aikaan, toisin kuin URL-osoitteessa, tiedoston URL-osoitteessa on suositeltavaa käyttää vieraiden aakkosten merkkejä (eli ei US-ASCII-taulukosta) sellaisenaan, eli ilman URL-koodausta [6] . Tämä johtuu siitä, että tiedoston URL-osoitteessa olevia URL-koodattuja oktetteja käsitellään tavuina käyttäjän nykyisellä koodisivulla, mikä tarkoittaa, että URL-osoitteen arvo muuttuu riippuen siitä, missä maassa asiakirjaa tarkastellaan [6] .

Esimerkkejä

UNIX ja UNIXin kaltaiset käyttöjärjestelmät

4 Unix - esimerkkiä , jotka osoittavat samaan / etc / fstab - tiedostoon :

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

Esimerkki linkistä rfc959.txt-tiedostoon, joka sijaitsee nnsc.nsf.net ftp-palvelimella [Huom. 1] :

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

2 esimerkkiä Mac OS : stä , jotka osoittavat samaan /var/log/system.log-tiedostoon :

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

Esimerkkejä Windows -sovellusten tukemista poluista, jotka osoittavat c: \ WINDOWS \ clock.avi -tiedostoon :

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

Esimerkkipolku start.swf- tiedostoon , joka sijaitsee verkkokansiotuotteissa tietokoneessa verkkonimellä applib [ 7] :

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

Esimerkkitiedoston URI, jossa on %-koodattuja merkkejä ja Unicode-merkki [7] (Internet Explorer 6:ssa ja 7:ssä %20 -esimerkki ei ehkä toimi [8] ):

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

Tiedostokaavio ja selaimet

Selain Tiedostoskeeman tuki (localhost) Tyhjä isäntä ( file:/// ) Verkkoisäntä _ Asemakirjain polussa ( C: ) [Esi. v. 1] Kansion yleiskatsaus URL-koodatut merkit tiedostolinkit html -muodossa
Google Chrome Joo Joo VOITTAA Joo Joo Joo Joo
Internet Explorer Joo Joo VOITTAA Joo Ei Joo Joo
Konqueror Joo Joo ? - Joo Joo Joo
Ilves Joo Joo FTP Joo Joo Joo Joo
Mozilla Firefox Joo Joo VOITOT [Ex. v. 2] Joo Joo Joo Joo
Ooppera Joo Joo VOITTAA Joo Joo Joo Joo
safari Joo ? ? - Ei ? ?
Yandex selain Joo Joo VOITTAA Joo Joo Joo Joo
Taulukon muistiinpanot
  1. ↑ Vain Windowsia tukeville selaimille
  2. ↑ Yleisesti annettu polku muodossa file://hostname/share/path/to/a/file ei toimi Mozilla Firefoxissa, mutta voit asettaa sen muotoon file://///hostname/share/path/to/a /tiedosto . Vuonna 2001 Mozilla esitteli virheen tästä, keskusteli siitä useita vuosia, mutta he eivät korjanneet sitä (he eivät löytäneet järkevää ratkaisua) [9]

Windowsin tiedostokaavio

Tiedoston URI-mallia tuki alun perin Windows, ts. URI-tuen myötä [Huom. 2] yleisesti ja erityisesti Internet Explorer 1:n julkaisun yhteydessä [10] . Internet Explorerin ensimmäinen versio kehitettiin vuonna 1995, jolloin URL-standardia ei vielä ollut olemassa ja tiedostomallia voitiin tulkita eri tavoin, mikä tapahtui selaimen kanssa. Sen eri moduulit käsittelivät tiedostokaaviota eri tavalla. Uudelleentyöskentelyn jälkeen tämä tilanne poistettiin. shlwapi.dll luotiin , johon sijoitettiin kaikki URL-osoitteen kanssa työskentelemistä varten tarvittava koodi. Uudelleentyöskentelyn aikana sovittiin kaksi tiedostoskeemaa: yksi URL-standardin mukainen, toinen vanha muoto, joka tuli DOS-ajoilta. Microsoftin työntekijät kutsuivat sitä vanhan tiedoston URL-osoitteeksi (vanhentuneen tiedoston URL-osoite). Esimerkkejä vanhan tiedoston URL-osoitteesta:

Tiedostopolku: c:\windows\Omat asiakirjat 100%20\foo.txt Vanhan tiedoston URL-osoite: file://c:\windows\Omat asiakirjat 100%20\foo.txt Vakiotiedoston URL-osoite: file:///c:/windows/My%20Documents%20100%2520/foo.txt Tiedostopolku: \\palvelin\jako\Omat asiakirjat 100%20\foo.txt Vanhan tiedoston URL-osoite: file://\\server\share\My Documents 100%20\foo.txt Vakiotiedoston URL-osoite: file://server/share/My%20Documents%20100%2520/foo.txt

Uusi dll käsittelee sekä uusia että vanhoja tiedostojen URL-osoitteita oikein, joten sen PathCreateFromUrl()- ja UrlCreateFromPath()-funktioita suositellaan Windows-polkujen ja tiedostojen URL-osoitteiden muuntamiseen [6] [11] .

Näiden toimintojen lisäksi CreateURLMoniker()-funktio luotiin urlmon.dll-tiedostoon (alkaen Internet Explorer 3 :sta), joka muuntaa merkkijonon URI:n objektiksi, jota voidaan käyttää antamaan tiedot osoitettuna annettuun URI:hen ( moniker ). Mutta tämä toiminto aiheutti myös ongelmia tiedoston URI: n [11] muuntamisessa , minkä seurauksena uusi CreateURLMonikerEx()-toiminto lisättiin ja suositeltiin käytettäväksi ( Internet Explorer 5.5 :stä alkaen ), jossa kaikki nämä ongelmat korjattiin. Internet Explorer 7 : n julkaisun myötä lisättiin toinen CreateURLMonikerEx2()-funktio, joka tukee suhteellisia polkuja.

Tietoturvaongelmat

Selaintuen tullessa ja yleistyessä komentosarjakielille , kuten JavaScriptille , on löydetty useita tiedostojärjestelmän käyttöön liittyviä haavoittuvuuksia. Tämän seurauksena selaintoimittajat ovat ottaneet käyttöön useita sisäänrakennettuja selaimen rajoituksia tiedostojen URL-osoitteiden käytölle.

Tärkeimmät tiedostojen URI-selaimen haavoittuvuudet

Linkit tiedostomalliin HTTP:n kautta ladatuissa HTML-dokumenteissa eivät toimi lähes kaikissa suosituissa selaimissa: Internet Explorer (versiosta 6 SP1) [12] [Huom. 3] , Mozilla Firefox [14] [15] , Chromium [16] ja Google Chrome [17] , Safari , Opera . Tällaisten linkkien napsauttaminen ei navigoi eikä näytä virheilmoitusta, vaikka virheilmoitus saattaa olla kirjautunut virhekonsoliin. Tiedoston URL-osoitteen sisältöä ei myöskään ladata HTTP-URL-osoitteella ladatun HTML-dokumentin kehyksiin. Tämä suojauskäytäntö otettiin käyttöön, koska tällaiset linkit aiheuttavat useita haavoittuvuuksia:

  • Hyökkääjän sivustolla isännöity HTML-dokumentti voi ladata tiedostoja käyttäjän tietokoneelle URL-osoitteiden avulla ja lähettää ne sitten hyökkääjän hallitsemaan palvelimeen. Hyökkääjä pääsee käsiksi käyttäjän luottamuksellisiin tietoihin;
  • Monet selaimet ja selainlaajennukset säilyttävät väliaikaiset tiedostonsa ja välimuistinsa ennustettavissa olevissa paikoissa levyllä. Hyökkääjä voi ensin sijoittaa HTML-tiedoston johonkin näistä paikoista selaimen normaalin toiminnan aikana (hallitun sivuston hyökkääjä voi pyytää tallentamaan verkkosivun levylle tai lähettämään sen arkistossa sähköpostiin) ja yrittää sitten avata kutsumalla se erityisesti valmistetun tiedoston URL-osoitteen kautta. Paikallisesti (tiedoston URL-osoitteen kautta) avatulla HTML-dokumentilla on enemmän oikeuksia kuin etädokumentilla, ja se voi sekä käyttää käyttäjän arkaluonteisia tietoja että suorittaa muita ei-toivottuja toimia. Tätä hyökkäysmenetelmää kutsutaan myös "tiedosto-URL-osoite-tiedosto-URL-komentosarjaksi" [18] . Lisäksi käyttäjä voi avata haitallisen html-asiakirjan paikallisesti tietokoneellaan.
  • Paikallisesti avattu html-tiedosto voi ladata etäverkkosivun iframe-kehykseen (koska tietokoneen paikalliset tiedostot eivät ole vain sivuston verkkotunnuksen rajoitussäännön alaisia ), kuten sähköpostisivusto, jolle käyttäjä on jo kirjautunut sisään, ja siten käyttää Internetissä olevat luottamukselliset käyttäjätiedot.

Toisen haavoittuvuuden torjumiseksi otettiin käyttöön myös " Domainin rajoitussääntö " ( sama alkuperäkäytäntö ) -niminen käytäntö, joka on samanlainen kuin samanniminen käytäntö, joka otettiin käyttöön aiemmin http-vyöhykkeen sivustoille. Mozilla Firefox, joka esitteli tämän käytännön selaimen versiossa 3 ( Gecko 1.9 -moottori) vuonna 2007, oli yksi ensimmäisistä, jotka tekivät niin (Firefox-kehittäjiltä kesti 3 vuotta keskustella tästä käytännöstä ja ottaa sen käyttöön [19] ). Tämän säännön mukaan tiedosto voi lukea toista tiedostoa vain, jos lähdetiedoston emohakemisto on kohdetiedoston superhakemisto [20] . Microsoft on aiemmin ollut tiukempi ja yleensä poistanut Javascriptin suorittamisen käytöstä avattaessa paikallisia tiedostoja, alkaen Internet Explorer 6 :sta Windows XP SP2:ssa ja lisännyt käyttäjille mahdollisuuden suorittaa komentosarja valitsemalla erityisen komennon ponnahdusvalikosta. Safari 3.2 ei salli käyttäjän avata paikallisten tiedostojen URL-osoitteita mistään muusta lähteestä kuin osoitepalkista. Opera 9.6 ei salli paikallisten html-sivujen ladata etäsisältöä (mutta tämä ei suojaa mahdolliselta hyökkääjän pääsyltä tietokoneen tietoihin). Chromium (ja siitä riippuvainen Google Chrome) otti käyttöön samanlaisen käytännön kuin Opera [21] ja otti myös Firefoxin käytännön huomioon, mutta otti myöhemmin käyttöön vieläkin rajoittavamman käytännön [22] kieltämällä tiedostojen URL-osoitteet komentosarjoilta paikallisilla verkkosivuilla osoitteessa kaikki (myöhemmin päätettiin lieventää tätä käytäntöä).

Näistä rajoituksista on tullut monia valituksia, koska ne häiritsevät paikallisia sivustoja ja verkkohakemistoja, joita käytetään laajasti monissa yritys- ja paikallisverkoissa, CD-jakeluissa, sähköpostin liitteissä ja joita verkkokehittäjät käyttävät myös virheenkorjaukseen. sivustoja. Esimerkiksi Mozillassa otettiin käyttöön useita kymmeniä päällekkäisiä bugeja tästä syystä [15] . Tästä syystä kykyä ohittaa, poistaa käytöstä tai määrittää tämä käytäntö on tuettu selaimissa, ja on ilmestynyt artikkeleita, jotka ehdottavat, miten tämä tehdään. Joten Internet Explorerissa tämä käytäntö määritetään "Oma tietokone" -vyöhykkeen tai muun asetusten "Web-sivustot vähemmän etuoikeutetulla verkkosisältövyöhykkeellä voivat navigoida tälle vyöhykkeelle" -parametrilla. Tämä kielto ohitetaan myös lisäämällä verkkosivustoja, jotka Älä aiheuta huolta Internet Explorerin luotettujen sivustojen vyöhykkeelle . Mozilla Firefoxissa tämä kielto ohitetaan käyttämällä laajennuksia LocalLink, Local Filesystem Links, IE Tab; tai erityinen suojauskäytäntöasetus (erityinen vyöhyke luodaan sivustoryhmälle, jolla on omat suojausasetukset) [14] . Google Chromessa versiosta 7 alkaen tämä rajoitus voidaan ohittaa käynnistämällä selain --allow-file-access-from-files -lipulla tai käyttämällä LocalLinks-laajennusta. Chromium on myös päättänyt lieventää " Domain Restriction Rule " -käytäntöä tiedostojen URL-osoitteisiin [23] lukuisten valitusten seurauksena .

Suojauskäytäntöjen rajoitukset selaimissa

Selainten suojauspolitiikan tärkeimmät rajoitukset näkyvät taulukossa [Huom. 2. 1] .

Testin kuvaus MSIE6 [Huomautus v.2. 2] MSIE7 [Huomautus v.2. 3] MSIE8 [Huomautus v.2. neljä] FF2 [Huomautus v.2. 5] FF3 [Huomautus v.2. 6] Safari [Huomautus v.2. 7] Opera [Huomautus v.2. kahdeksan] Chrome [Huomautus v.2. 9]
Onko paikallisilla HTML-koodeilla pääsy asiaankuulumattomiin paikallisiin tiedostoihin DOM:n kautta? Joo Joo Joo Joo Ei Ei Joo Ei
Onko paikallisilla HTML-koodeilla pääsy asiaankuulumattomiin paikallisiin tiedostoihin XMLHttpRequestin kautta? Ei Ei Ei Joo Ei Ei Joo Ei
Pääsevätkö paikalliset HTML-koodit Internetin sivustoille XMLHttpRequestin kautta? Joo Joo Joo Ei Ei Ei Ei Ei
Toimiiko document.cookie tiedoston URL-osoitteen kanssa? Joo Joo Joo Joo Joo Joo Joo Ei
Saako <IMG>-tunnisteen ladata tiedostolla URI? Joo Joo Joo Ei Ei Ei Ei Ei
Saako <SCRIPT>-tunnisteen ladata tiedostolla URI? Joo Joo Joo Ei Ei Ei Ei Ei
Saako <IFRAME>-tunnisteen ladata tiedostolla URI? Joo Joo Joo Ei Ei Ei Ei Ei
Saako <EMBED>-tunnisteen ladata tiedoston URI:n kanssa? Ei Ei Ei Ei Ei Ei Ei Ei
Saako <APPLET>-tunnisteen ladata tiedostolla URI? Joo Joo Joo Ei Ei Joo Ei Joo
Onko mahdollista ladata tyylejä (tyylitaulukkoa) tiedoston URI:n kautta? Joo Joo Joo Ei Ei Ei Ei Ei
Ovatko sijainnin uudelleenohjaukset sallittuja URI-tiedoston kautta? Ei Ei Ei Ei Ei Ei Ei Ei
Ovatko Refresh-uudelleenohjaukset sallittuja tiedoston URI:n kautta? Ei Ei Ei Ei Ei Ei Ei Ei
Taulukon muistiinpanot
  1. ↑ Taulukon tiedot kaikista selaimista, ellei toisin mainita, on otettu Michal Zalewskin "Browser Security Handbookista" [24] , jonka päämateriaali on kirjoitettu jo vuonna 2008 [25] eivätkä välttämättä ole merkityksellisiä uudemmille. selainten versiot
  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 ) -hyökkäys on yksi Internetin tunnetuimmista haavoittuvuuksista. Tämä haavoittuvuuksien luokka on rekisteröity suurimpiin haavoittuvuuksien luetteloihin: Common Weakness Enumeration [26] ja CAPEC [27] . Hyökkäyksen olemus on seuraava. On palveluita, jotka tukevat SOAP- ja XML-RPC-protokollia , jotka hyväksyvät syötteen XML - dokumentin muodossa. XML-dokumenttistandardi tukee DTD -osion sisällyttämistä , ja DTD-osiot puolestaan ​​voivat liittää dokumenttiin lisäkomponentteja, niin sanottuja ulkoisia entiteettejä [ 28 ] .  Ulkoiset entiteetit ovat erillisiä tiedostoja, ja ne määritetään SYSTEM-avainsanalla ja URI:lla. Jos XML-jäsennin ei ole vahvistava, se voi yksinkertaisesti ladata ulkoisen entiteetin ja liittää sen XML-asiakirjan sisältöön. Hyökkääjä voi korvata ulkoisen entiteettitiedoston URI:n URI:lla, joka osoittaa tietokoneen laitteistoon tai järjestelmän paikalliseen tiedostoon. Palvelin yrittää lukea määritetyn URI:n tiedoston ja sisällyttää sen sisällön XML-tiedostoon. Tällaista mekanismia käytettäessä seuraavan tyyppiset hyökkäykset ovat mahdollisia [29] :

  • Palvelunesto-hyökkäys palvelimeen käyttämällä järjestelmälaitetta, kuten /dev/urandom tai ;
  • luvaton pääsy yksityisiin palvelintiedostoihin, kuten /etc/passwd tai c:/winnt/win.ini ;
  • TCP-porttien skannaus (jopa palomuurin ohittaminen);
  • DoS-hyökkäys muihin järjestelmiin (jos jäsentäjä sallii TCP-yhteydet muihin järjestelmiin)
  • NTLM-todennusmateriaalin varkaus, joka on aloitettu UNC -kutsulla hyökkääjän hallinnassa olevaan järjestelmään;
  • Tuomiopäivän skenaario: Tämän haavoittuvuuden vaikutuspiiriin kuuluvaa laajasti käytössä olevaa, pitkälle kytkettyä palvelinsovellusta voidaan käyttää DDoS -hyökkäykseen (Distributed Denial of Service).

XXE-haavoittuvuudesta http://xml.org-yhteisössä ( voittoa tavoittelemattoman OWASP -järjestön verkkosivusto ) on keskusteltu vuodesta 2001 [30] , mutta nämä olivat vain teoreettisia ajatuksia tällaisen hyökkäyksen mahdollisuudesta. Ensimmäinen henkilö, joka kiinnitti yleisön huomion tähän haavoittuvuuteen, oli Gregory Steuck [31 ] .  Vuonna 2002 hän lähetti tietoturvaohjeen (turvakäsikirjan ) osoitteeseen www.securityfocus.com [29] , jossa hän kuvaili haavoittuvuutta yksityiskohtaisesti ja antoi sille nimen XXE Attack . 

XXE-hyökkäys vaikutti moniin tuotteisiin. Kaikista tärkeimmistä ohjelmistohaavoittuvuuksia koskevista tietokannoista löytyy ohjelmistotuotteita, jotka ovat alttiina XXE-hyökkäyksille: kansallinen haavoittuvuustietokanta [32] , yleiset haavoittuvuudet ja altistukset [33] , avoimen lähdekoodin haavoittuvuustietokanta [34] . Haavoittuvuus "XXE-hyökkäyksille" löydettiin sellaisista tunnetuista tuotteista kuin JDK ja JRE (6. versio, 3. päivitys) [33] [35] , WebKit ja siihen perustuva selain Safari (3. versio) [ 36] [37] , Spring Framework [38] , CakePHP [39] , Adobe Reader (versio 7) [40] , Zend Framework [41] , Squiz [42] jne.

Standardointi ja tekniset tiedot

URI-tiedostojärjestelmä kuvattiin ensimmäisen kerran kesäkuussa 1994 tiedottavassa RFC 1630 :ssa ("Universal Resource Identifiers in WWW"). Saman vuoden joulukuussa se standardoitiin RFC 1738 :ssa (Uniform Resource Locators (URL)). RFC 1738 kuvaa yleistä URL-muotoa ja on nyt vanhentunut, lukuun ottamatta kahta osiota, jotka kuvaavat tiedosto- ja ftp-malleja. Uusi RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), julkaistiin vuonna 2005, sisälsi RFC 1738 :n , teki pieniä muutoksia, mutta se ei kuvaillut yksittäisiä skeemoja. Siihen mennessä lähes kaikki pysyvän osan järjestelmät olivat saaneet oman erillisen standardin. Vanha RFC 1738 ilmoitti vain mallin muodon, mutta ei määritellyt sääntöjä tämän mallin soveltamisesta ja paikallisen polun muuntamisesta URI:ksi ja päinvastoin. Oli tarpeen standardoida tiedostoskeema, samoin kuin useita muita standardoimattomia skeemoja.

Vuonna 2004 Paul Hoffman, joka on ollut IETF:n jäsen 1990-luvun alusta lähtien, aloitti tiedostoskeeman standardointiprosessin. Kesäkuun aikana hän kirjoitti erilliset määritykset tiedosto-, ftp-, gopher-, news- ja nntp-, prospero- ja telnet-järjestelmille, ja 17. kesäkuuta 2004 ne julkaistiin ietf.org-verkkosivustolla ja 19. kesäkuuta hän ilmoitti siitä. postituslistalla [43] . Tiedostoskeemastandardin ensimmäinen versio oli nimeltään "File URI Scheme" [44] . Paul Hoffman ilmoitti 19. kesäkuuta, että luonnoksesta on aloitettu aktiivinen keskustelu. IETF-yhteisöltä tuli monia kommentteja, ja pian seurasi toinen versio [45] , jota seurasi kolmas [46] ja neljäs [47] . Mutta yksimielisyyteen ei koskaan päästy. Jatkakseen työskentelyä standardin parissa Mike Brown loi erityisen wikisivuston https://offset.skew.org/wiki/URI/File_scheme , jossa työskenneltiin jonkin aikaa tiedon keräämiseksi tiedostojärjestelmästä. Mutta pian tämä toiminta hiipui, eikä standardia koskaan hyväksytty.

Vuonna 2013 Matthew Kerwin tekee toisen yrityksen standardoida tiedostoskeema. Kesäkuussa 2013 luonnoksen ensimmäinen versio julkaistiin [48] , luonnoksesta aloitettiin keskustelu ja kesä-syyskuun aikana julkaistiin vielä 8 versiota. Viimeisin (nro 8, eli yhdeksäs [Note 4] ) versio luonnoksesta julkaistiin 18. syyskuuta 2013 [49]

Muistiinpanot

Kommentit
  1. ↑ Tämä esimerkki toimii vain Lynx -selaimessa
  2. ↑ Termi URI ilmestyi myöhemmin, tuolloin sen prototyyppi oli URL, tästä eteenpäin artikkelissa URI voi tarkoittaa URL-osoitetta
  3. ↑ Linkit tiedostomalliin, jossa on ei-paikallinen isäntä (eli URL-osoitteet, jotka osoittavat UNC - polkuun, esim. file://dmitryt/public/readme.txt ) toimivat Internet Explorerissa versioon 9 asti, mutta päivityksessä versioon 9.02 asti , julkaistiin elokuussa 2011, tämä ominaisuus poistettiin käytöstä [13]
  4. ↑ IETF-standardiluonnokset on numeroitu 0:sta alkaen
Lähteet
  1. ↑ Uniform Resource Identifier (URI) -järjestelmät arkistoitu 11. lokakuuta 2016 Wayback Machinessa ( iana.org ) 
  2. ↑ Tim Berners-Lee, et. al. "World-Wide: an Information Infrastructure for High-Energy Physics", Proceedings of the Second Workshop on Artificial Intelligence and Software Engineering for High Energy Physics, La Londe, Ranska, tammikuu 1992  //  New Computing Techniques in Physics Research. Singapore: World Scientific. - s. 157-164 . Arkistoitu alkuperäisestä 24. syyskuuta 2015.
  3. ↑ Lynxissä tuetut URL-mallit Tiedoston URL-osoite.  (englanniksi) . Lynxin käyttöopas . http://lynx.isc.org+ (5. heinäkuuta 2009). Haettu: 9. lokakuuta 2013.  (linkki ei saatavilla)
  4. ↑ 1 2 T. Berners-Lee, L. Masinter, M. McCahill. 3.10 Tiedostot / Uniform Resource Locators (URL-osoitteet  ) . Kommenttipyyntö: 1738 14. IETF (joulukuu 1994). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 15. lokakuuta 2013.
  5. ↑ Marcos Caceres. Sovellus : URI-malli  . W3C (16. toukokuuta 2013). Haettu 8. lokakuuta 2013. Arkistoitu alkuperäisestä 6. lokakuuta 2013.
  6. ↑ 1 2 3 4 Dave Risney. Tiedostojen URI : t Windowsissa  . MSDN (6. joulukuuta 2006). Haettu 16. lokakuuta 2013. Arkistoitu alkuperäisestä 4. elokuuta 2013.
  7. ↑ 1 2 Risney, Dave tiedosto-URI:  t Windowsissa . IEBlog . Microsoft Corporation (2013). Haettu 7. elokuuta 2013. Arkistoitu alkuperäisestä 4. elokuuta 2013.
  8. ↑ Saatat saada virheilmoituksen, kun napsautat Internet Explorerissa  hyperlinkkiä, joka viittaa paikallisessa tietokoneessa tai paikallisessa verkossa olevaan tiedostoon . Microsoft (26. lokakuuta 2007). Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 16. tammikuuta 2006.
  9. ↑ Virhe 70871 - file://hostname/dir/dir/filename - isäntänimi ei ole käytössä . Arkistoitu 21. lokakuuta 2013 Wayback Machinessa . (2001-03-04). Mozilla
  10. ↑ Zeke Odins-Lucas. Outo ja onneton tarina "file : " URL-osoitteista  . MSDN (19. toukokuuta 2005). Käyttöpäivä: 15. lokakuuta 2013. Arkistoitu alkuperäisestä 16. tammikuuta 2013.
  11. ↑ 1 2 Dave Risney. CreateURLMoniker pidetään  haitallisena . MSDN (14. syyskuuta 2006). Haettu 16. lokakuuta 2013. Arkistoitu alkuperäisestä 17. lokakuuta 2013.
  12. ↑ tiedostoprotokolla  . _ MSDN . Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 4. toukokuuta 2016.
  13. ↑ Eric Law. Internet Explorer 9.0.2 -päivitys  (englanniksi) . MSDN (12. elokuuta 2011). Haettu 19. lokakuuta 2013. Arkistoitu alkuperäisestä 20. lokakuuta 2013.
  14. ↑ 1 2 Linkit paikallisille sivuille eivät  toimi . MozillaZine Knowledge Base . Mozilla . Haettu 19. lokakuuta 2013. Arkistoitu alkuperäisestä 20. lokakuuta 2013.
  15. ↑ 1 2 Virhe 122022 - (file://) [ISSUE] file:// URL-osoitteet http | https-sivu ei toimi (napsauttaminen ei tee mitään, ei lataudu automaattisesti jne.) . Bugzilla@Mozilla . Mozilla (26. tammikuuta 2002). Käyttöpäivä: 20. lokakuuta 2013. Arkistoitu alkuperäisestä 24. lokakuuta 2013.
  16. ↑ A. Barth, C. Jackson, C. Reis ja Google Chrome -tiimi. Chromium-selaimen suojausarkkitehtuuri  :  tekninen raportti. — Stanfordin yliopisto, 2008. — s. 6 . Arkistoitu alkuperäisestä 7. syyskuuta 2011.
  17. ↑ Šilić, M.; Krolo, J.; Delac, G. Tietoturvahaavoittuvuudet modernissa verkkoselainarkkitehtuurissa  //  MIPRO, 2010 Proceedings of the 33rd International Convention. - Opatija, Kroatia, 2010. - P. 1240-1245 . — ISBN 978-1-4244-7763-0 . Arkistoitu alkuperäisestä 24. lokakuuta 2022.
  18. ↑ CVE -2009-1839  . Yleiset haavoittuvuudet ja altistukset (29. toukokuuta 2009). Käyttöpäivä: 19. lokakuuta 2013. Arkistoitu alkuperäisestä 2. huhtikuuta 2015.
  19. ↑ Virhe 230606 - Kiristä paikallisten tiedostojen saman alkuperän käytäntöä (tiedosto: URL-osoitteet, luotettu, suojaus) . Bugzilla@Mozilla . Mozilla (10. tammikuuta 2004). Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 25. huhtikuuta 2014.
  20. ↑ Saman alkuperän käytäntö tiedostolle: URI:t  (englanniksi)  (downlink) . Mozilla Developer Network . Käyttöpäivä: 20. lokakuuta 2013. Arkistoitu alkuperäisestä 16. elokuuta 2013.
  21. ↑ Adam Barth. Tietoturva perusteellisesti: Paikalliset Web-  sivut . Chromium (4. joulukuuta 2008). Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 27. lokakuuta 2013.
  22. ↑ Ongelma 4197: Rajoita edelleen tiedoston  URL -osoitteen käyttöä . Google . Käyttöpäivä: 20. lokakuuta 2013. Arkistoitu alkuperäisestä 24. lokakuuta 2013.
  23. ↑ Ongelma 47416: Salli hakemistopuun käsitteleminen yhtenä alkuperänä (löysää tiedostoa: URL-rajoitukset  ) . Google . Käyttöpäivä: 20. lokakuuta 2013. Arkistoitu alkuperäisestä 24. lokakuuta 2013.
  24. ↑ Michal Zalewski. Selaimen suojauskäsikirja, osa  2 . Google (10. joulukuuta 2008). Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 19. elokuuta 2016.
  25. ↑ Michal Zalewski. Julkaisemme "Selainturvallisuuskäsikirjan  " . Google Online Security -blogi (10. joulukuuta 2008). Haettu 20. lokakuuta 2013. Arkistoitu alkuperäisestä 25. huhtikuuta 2014.
  26. ↑ CWE-611: XML External Entity Reference ('XXE'  ) virheellinen rajoitus . Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 30. maaliskuuta 2020.
  27. ↑ CAPEC-201: Ulkoisen yksikön  hyökkäys . Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 5. joulukuuta 2013.
  28. ↑ Elliot Rusty Harold, W. Scott Means. xml. Viite = XML pähkinänkuoressa, toinen painos / Per. Englannista - Pietari. : Symbol-Plus, 2002. - S.  76 -80. — 576 s. - ISBN 5-93286-025-1 .
  29. ↑ 1 2 Steuck, Gregory XXE (Xml eXternal Entity)  -hyökkäys . www.securityfocus.com (29. lokakuuta 2002). Haettu 25. lokakuuta 2013. Arkistoitu alkuperäisestä 29. lokakuuta 2013.
  30. ↑ Wilson, John Haitallisina pidettyjen nimitilan URI  -viittausten poistaminen . XML-DEV-postituslista (01.1.2001). Haettu: 12. lokakuuta 2013.
  31. ↑ Sabin, Miles Seen on BugTraq : XXE (Xml eXternal Entity) -hyökkäys  . XML-DEV-postituslista (30. lokakuuta 2002). Haettu: 12. lokakuuta 2013.
  32. ↑ Haavoittuvuuden yhteenveto CVE-2008-0628  (määrittämätön) . Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 2. kesäkuuta 2013.
  33. ↑ 12 CVE - 2008-0628 . Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 4. maaliskuuta 2016. 
  34. ↑ 68033 : Splunk XML Parser XML External Entity (XXE) Unspecified Remote Privilege Escalation  . Haettu: 7. marraskuuta 2013.  (linkki, jota ei voi käyttää)
  35. ↑ Chris Evans. Sun JDK6 rikkoo XXE-  hyökkäyssuojauksen . http://scary.beasts.org+(2007).+ Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 10. tammikuuta 2013.
  36. ↑ Dmitri Dokuchaev. Exploit Overview  // Hakkeri . - 2009. - Ongelma. 127 , nro 07 . - S. 44-50 . Arkistoitu alkuperäisestä 25. huhtikuuta 2014.
  37. ↑ Apple Safarin paikallisen tiedostovarkauden  haavoittuvuus . www.securityfocus.com (9. kesäkuuta 2009). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 4. maaliskuuta 2016.
  38. ↑ CVE-2013-4152 XML External Entity (XXE) -injektio Spring  Frameworkissa . www.securityfocus.com (22. elokuuta 2013). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 7. syyskuuta 2013.
  39. ↑ CakePHP 2.x-2.2.0-RC2 XXE  Injection . www.securityfocus.com (16. heinäkuuta 2012). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 10. lokakuuta 2012.
  40. ↑ Sverre H. Huseby. Adobe Reader 7 : XML External Entity (XXE) -hyökkäys  . www.securityfocus.com (16. kesäkuuta 2005). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 4. maaliskuuta 2016.
  41. ↑ SEC Consult SA-20120626-0 :: Zend Framework - Paikallinen tiedostojen paljastaminen XXE-  injektion kautta . www.securityfocus.com (26. kesäkuuta 2012). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 7. heinäkuuta 2012.
  42. ↑ Squiz CMS:n useat haavoittuvuudet - Tietoturvatiedote - SOS  -12-007 . www.securityfocus.com (18. kesäkuuta 2012). Haettu 7. marraskuuta 2013. Arkistoitu alkuperäisestä 4. maaliskuuta 2016.
  43. ↑ Hoffman, Paul Historialliset kaavioluonnokset  . [email protected] postituslista (19. elokuuta 2004). Haettu: 26. syyskuuta 2013.
  44. ↑ P. Hoffman. Tiedosto URI  Scheme . IETF (17. elokuuta 2004). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 13. syyskuuta 2014.
  45. ↑ P. Hoffman. Tiedosto URI  Scheme . IETF (18. syyskuuta 2004). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 13. syyskuuta 2014.
  46. ↑ P. Hoffman. Tiedosto URI  Scheme . IETF (30. marraskuuta 2004). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 13. syyskuuta 2014.
  47. ↑ P. Hoffman. Tiedosto URI  Scheme . IETF (tammikuu 2005). Käyttöpäivä: 6. lokakuuta 2013. Arkistoitu alkuperäisestä 24. heinäkuuta 2014.
  48. ↑ M. Kerwin. Tiedosto URI  Scheme . IETF (20. kesäkuuta 2013). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 4. helmikuuta 2015.
  49. ↑ M. Kerwin. Tiedosto URI  Scheme . IETF (18. syyskuuta 2013). Haettu 6. lokakuuta 2013. Arkistoitu alkuperäisestä 4. helmikuuta 2015.

Katso myös

Linkit

 URI- järjestelmät
Virallinen
epävirallinen