Schema URI de fișier este o schemă URI documentată în RFC 8089 , RFC 1630 , RFC 1738 și RFC 3986 , concepută pentru a adresa fișiere de pe un computer local sau rețea locală prin calea lor directă pe un disc, folder de rețea sau, în unele cazuri, pe un server ftp. Fișierul cu schemă URI este înregistrat în Registrul Schemei URI IANA [1] și este listat în secțiunea „Scheme URI permanente”.
Schema de fișiere este una dintre cele mai vechi scheme URI . A fost întruchipat în software încă de la începuturile Internetului. WorldWideWeb , primul browser web creat în 1991 de Tim Berners-Lee , inventatorul World Wide Web , a susținut schema de fișiere . Specificația RFC 1630 , în care a fost documentată pentru prima dată, a fost scrisă și de Tim Berners-Lee în iunie 1994, înainte de crearea W3C și este una dintre cele mai vechi specificații de internet.
Înainte de introducerea schemei ftp , schema de fișiere era folosită pentru a se referi la fișierele aflate pe serverele ftp. Tim Berners-Lee însuși a propus utilizarea schemei de fișiere în URL -ul pentru link-uri către fișiere accesibile prin protocolul ftp și el însuși a folosit astfel de legături în secțiunea Referințe a publicațiilor sale [2] . Browserul Lynx , unul dintre cele mai vechi browsere care au supraviețuit, a păstrat această interpretare a schemei fișierului [3] până în prezent .
Spre deosebire de majoritatea schemelor cunoscute (de ex. http, nfs, sip, telnet etc.), schema de fișiere nu este un protocol. Acest lucru este menționat în mod explicit în RFC 1738 : „O caracteristică a acestei scheme este că nu specifică un protocol de Internet sau o metodă de acces la fișiere, astfel încât utilizarea sa în protocoalele de rețea între gazde este limitată” [4] . Schema de fișiere specifică pur și simplu calea către un fișier ca URL (sau URI) pe o anumită mașină. De asemenea, se spune că „această schemă, spre deosebire de majoritatea altor scheme URL, nu definește o resursă care este disponibilă public pe Internet”.
Schema de fișiere este acceptată de toate browserele populare, pe toate sistemele de operare, deși se bazează pe un standard foarte vechi care descrie formatul URL, dar nu are încă al său. Dar datorită caracteristicilor de mai sus, utilizarea sa este limitată. Funcționează în bara de adrese, dar această schemă nu se găsește aproape niciodată în marcajul HTML al site-urilor web. O nouă schemă , aplicația , a fost dezvoltată pentru a înlocui fișierul . Schema aplicației este descrisă în recomandarea W3C din 16 mai 2013 [5]
URL-ul cu fișierul de schemă are formatul [4] :
file:// <gazdă> / <cale>unde gazdă este numele de domeniu complet calificat de pe sistemul în care calea este disponibilă , iar calea este o cale de director ierarhică în directorul de format / director /.../ nume fișier . Dacă gazda este omisă, valoarea implicită este „localhost”, gazda pe care este analizată adresa URL. Înainte de 2005, standardul avea o cerință astfel încât, dacă gazda este omisă, atunci bara oblică sau dublă oblică corespunzătoare nu poate fi omisă ("file:///foo.txt" va funcționa, dar "file://foo.txt" nu va, deși unii analizatori au reușit să gestioneze acest caz). RFC 3986 , lansat în 2005, a eliminat această cerință. Conform RFC 3986 , autoritatea de omitere (în acest caz echivalentă cu gazdă ) omite, de asemenea, bara oblică dublă (//).
Bara oblică (/) are un înțeles diferit în funcție de poziția în URI.
Componentele de conectare (nume de utilizator), parola (parolă) și portul (port) nu sunt utilizate în adresele URL cu schema de fișiere. Dar, în același timp, parametrii (șirul de interogare) și componentele ancora (identificatorul de fragment) [6] pot fi utilizate de aplicația însăși, afișând conținutul URL-ului fișierului dat. De exemplu, un script din interiorul unui document HTML poate citi parametrii, iar o ancoră poate fi utilizată într-un mod standard pentru a naviga în document.
Adresele URL ale fișierelor diferă în setul de caractere atât de adresele URL tradiționale, cât și de căile de fișiere din sistemele de fișiere. Deoarece căile din sistemele de fișiere pot conține caractere rezervate în adrese URL pentru scopuri de serviciu („#”, „%”, etc.), astfel de caractere (anterior și spațiul „ ") sunt codificate atunci când se convertesc o cale într-un URL de fișier . Dar, în același timp, spre deosebire de URL, în URL-ul fișierului este recomandat să folosiți caractere din alfabete străine (adică nu din tabelul US-ASCII) așa cum este, adică fără codificare URL [6] . Acest lucru se datorează faptului că octeții codificați în URL din URL-ul fișierului sunt tratați ca octeți în pagina de cod curentă a utilizatorului, ceea ce înseamnă că valoarea URL-ului se va schimba în funcție de localitatea în care este vizualizat documentul [6] .
4 exemple Unix care indică același fișier / etc / fstab :
file://localhost/etc/fstab file:///etc/fstab file:///etc/./fstab file:///etc/../etc/fstabUn exemplu de link către fișierul rfc959.txt, care se află pe serverul ftp nnsc.nsf.net [Notă. 1] :
file://nnsc.nsf.net/rfc/rfc959.txt Mac OS2 exemple pe Mac OS care indică același fișier /var/log/system.log :
file://localhost/var/log/system.log file:///var/log/system.log WindowsExemple de căi acceptate de aplicațiile Windows care indică fișierul 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.aviUn exemplu de cale către fișierul start.swf situat în folderul de rețea produse de pe un computer cu numele de rețea applib [7] :
file://applib/products/ab/abc_9/4148.920a/media/start.swfUn exemplu de URI de fișier cu caractere codificate % și un caracter Unicode [7] (în Internet Explorer 6 și 7, exemplul %20 poate să nu funcționeze [8] ):
file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc file:///C:/exampleㄓ.txt| Browser | Suport pentru schema de fișiere (localhost) | Gazdă goală ( file:/// ) | Gazdă de rețea | Literă de unitate în cale ( C: ) [Ex. v. 1] | Prezentare generală a folderului | Caractere codificate URL | link-uri la fișiere în html |
|---|---|---|---|---|---|---|---|
| Google Chrome | da | da | CÂȘTIGE | da | da | da | da |
| Internet Explorer | da | da | CÂȘTIGE | da | Nu | da | da |
| Konqueror | da | da | ? | - | da | da | da |
| Râsul | da | da | FTP | da | da | da | da |
| Mozilla Firefox | da | da | CÂȘTIGE [Ex. v. 2] | da | da | da | da |
| Operă | da | da | CÂȘTIGE | da | da | da | da |
| safari | da | ? | ? | - | Nu | ? | ? |
| browser Yandex | da | da | CÂȘTIGE | da | da | da | da |
Schema URI de fișier a fost acceptată inițial de Windows, adică odată cu apariția suportului URI [Notă. 2] în general, și în special cu lansarea Internet Explorer 1 [10] . Prima versiune a Internet Explorer a fost dezvoltată în 1995, când standardul URL nu exista încă, iar schema de fișiere putea fi interpretată în moduri diferite, ceea ce s-a întâmplat cu browserul. Modulele sale diferite au gestionat schema de fișiere în mod diferit. După reluare, această situație a fost eliminată. A fost creat shlwapi.dll , în care a fost plasat tot codul pentru lucrul cu URL-ul. În timpul reluării, au fost convenite două forme ale schemei de fișiere: una conform standardului URL, cealaltă o formă veche care a venit din zilele DOS. Angajații Microsoft l-au numit URL de fișier moștenit (URL de fișier învechit). Exemple de adrese URL ale fișierelor vechi:
Calea fișierului: c:\windows\Documentele mele 100%20\foo.txt Adresa URL a fișierului vechi: file://c:\windows\Documentele mele 100%20\foo.txt Adresa URL a fișierului standard: file:///c:/windows/My%20Documents%20100%2520/foo.txt Calea fișierului: \\server\share\My Documents 100%20\foo.txt Adresa URL a fișierului moștenit: file://\\server\share\My Documents 100%20\foo.txt Adresa URL a fișierului standard: file://server/share/My%20Documents%20100%2520/foo.txtNoul dll gestionează corect atât adresele URL ale fișierelor noi, cât și cele vechi, astfel încât funcțiile sale PathCreateFromUrl() și UrlCreateFromPath() sunt recomandate pentru conversia între căile Windows și URL-urile fișierelor [6] [11] .
În plus față de aceste funcții, funcția CreateURLMoniker() a fost creată în urlmon.dll (începând cu Internet Explorer 3 ) pentru a converti un URI șir într-un obiect care poate fi folosit pentru a obține datele adresate URI-ului dat ( moniker ). Dar această funcție a cauzat și unele probleme la conversia fișierului URI [11] , în urma cărora a fost adăugată și recomandată pentru utilizare o nouă funcție CreateURLMonikerEx() (începând cu Internet Explorer 5.5 ), în care toate aceste probleme au fost rezolvate. Odată cu lansarea Internet Explorer 7 , a fost adăugată o altă funcție CreateURLMonikerEx2() care acceptă căi relative.
Odată cu apariția și proliferarea suportului pentru browser pentru limbaje de scripting, cum ar fi JavaScript , au fost descoperite o serie de vulnerabilități legate de utilizarea schemei de fișiere. Drept urmare, furnizorii de browsere au introdus o serie de restricții încorporate în browser cu privire la utilizarea URL-urilor fișierelor.
Legăturile cu schema de fișiere din documentele HTML încărcate prin HTTP nu funcționează în aproape toate browserele populare: Internet Explorer (de la versiunea 6 SP1) [12] [Notă. 3] , Mozilla Firefox [14] [15] , Chromium [16] și Google Chrome [17] , Safari , Opera . Făcând clic pe astfel de legături, nici nu navighează și nici nu afișează un mesaj de eroare, deși un mesaj de eroare poate fi înregistrat în consola de erori. De asemenea, conținutul de la adresa URL a fișierului nu este încărcat în cadrele unui document HTML încărcat la o adresă URL HTTP. Această politică de securitate a fost introdusă datorită faptului că astfel de legături provoacă o serie de vulnerabilități:
Pentru a combate a doua vulnerabilitate, a fost introdusă și o politică numită „ Domain restriction rule ” ( politică aceeași origine ), similară cu politica cu același nume introdusă mai devreme pentru site-urile din zona http. Mozilla Firefox, care a introdus această politică în versiunea 3 a browserului ( motor Gecko 1.9) în 2007, a fost unul dintre primii care a făcut acest lucru (au durat 3 ani pentru ca dezvoltatorii Firefox să discute și să implementeze această politică [19] ). Conform acestei reguli, un fișier poate citi un alt fișier numai dacă directorul părinte al fișierului sursă este superdirectorul fișierului țintă [20] . Microsoft a fost anterior mai dur și a dezactivat în general execuția Javascript la deschiderea oricăror fișiere locale, începând cu Internet Explorer 6 în Windows XP SP2, adăugând posibilitatea utilizatorilor de a executa un script selectând o comandă specială dintr-un meniu pop-up. Safari 3.2 nu permite utilizatorului să deschidă adrese URL de fișiere locale din orice altă sursă decât bara de adrese. Opera 9.6 nu permite paginilor html locale să încarce conținut de la distanță (dar acest lucru nu protejează împotriva posibilității ca un atacator să acceseze datele de pe computer). Chromium (și dependentul său Google Chrome) a implementat o politică similară cu cea a Opera [21] și a luat în considerare și politica Firefox, dar ulterior a implementat o politică și mai restrictivă [22] prin interzicerea adreselor URL ale fișierelor pentru scripturile din paginile web locale la toate (ulterior s-a decis relaxarea acestei politici).
Au existat multe plângeri ca urmare a acestor restricții, deoarece acestea interferează cu site-urile locale și directoarele web, care sunt utilizate pe scară largă în multe rețele corporative și locale, în distribuțiile de CD-uri, în atașamentele de e-mail și sunt, de asemenea, utilizate de dezvoltatorii web pentru depanare. .site-uri. De exemplu, câteva zeci de erori duplicat au fost introduse în Mozilla despre acest lucru [15] . Prin urmare, capacitatea de a ocoli, dezactiva sau configura această politică a fost acceptată în browsere și au apărut articole care sugerează cum se face acest lucru. Deci, în Internet Explorer, această politică este configurată de parametrul „Site-urile din zona de conținut web mai puțin privilegiată pot naviga în această zonă” din setările zonei „Computerul meu” sau alta. De asemenea, această interdicție este ocolită prin adăugarea de site-uri web care nu cauza nicio îngrijorare zonei Internet Explorer Trusted Sites . În Mozilla Firefox, această interdicție este ocolită folosind extensiile LocalLink, Local Filesystem Links, IE Tab; sau o setare specială de politică de securitate (se creează o zonă specială pentru un grup de site-uri cu propriile setări de securitate specifice) [14] . În Google Chrome începând cu versiunea 7, această restricție poate fi ocolită pornind browserul cu steag-ul --allow-file-access-from-files sau folosind extensia LocalLinks. De asemenea, Chromium a decis să relaxeze politica „ Regulă de restricție a domeniului ” pentru adresele URL de fișiere [23] ca urmare a numeroaselor reclamații .
Principalele limitări ale politicii de securitate în browsere sunt reflectate în tabel [Nota 2. 1] .
| Descriere Test | MSIE6 [Notă v.2. 2] | MSIE7 [Notă v.2. 3] | MSIE8 [Notă v.2. patru] | FF2 [Notă v.2. 5] | FF3 [Notă v.2. 6] | Safari [Notă v.2. 7] | Opera [Notă v.2. opt] | Chrome [Notă v.2. 9] |
|---|---|---|---|---|---|---|---|---|
| HTML-urile locale au acces la fișiere locale care nu au legătură prin DOM? | da | da | da | da | Nu | Nu | da | Nu |
| HTML-urile locale au acces la fișiere locale care nu au legătură prin XMLHttpRequest? | Nu | Nu | Nu | da | Nu | Nu | da | Nu |
| HTML-urile locale au acces la site-uri de pe Internet prin XMLHttpRequest? | da | da | da | Nu | Nu | Nu | Nu | Nu |
| Funcționează document.cookie cu URL-ul fișierului? | da | da | da | da | da | da | da | Nu |
| Este permisă încărcarea etichetei <IMG> cu URI de fișier? | da | da | da | Nu | Nu | Nu | Nu | Nu |
| Este permisă încărcarea etichetei <SCRIPT> cu URI de fișier? | da | da | da | Nu | Nu | Nu | Nu | Nu |
| Este permisă încărcarea etichetei <IFRAME> cu URI de fișier? | da | da | da | Nu | Nu | Nu | Nu | Nu |
| Este permisă încărcarea etichetei <EMBED> cu un URI de fișier? | Nu | Nu | Nu | Nu | Nu | Nu | Nu | Nu |
| Este permisă încărcarea etichetei <APPLET> cu URI de fișier? | da | da | da | Nu | Nu | da | Nu | da |
| Este posibil să încărcați stiluri (foaia de stil) prin URI de fișier? | da | da | da | Nu | Nu | Nu | Nu | Nu |
| Sunt permise redirecționările locației prin URI de fișier? | Nu | Nu | Nu | Nu | Nu | Nu | Nu | Nu |
| Sunt permise redirecționările de reîmprospătare prin URI de fișier? | Nu | Nu | Nu | Nu | Nu | Nu | Nu | Nu |
Atacul XXE ( Xml eXternal Entity ) este una dintre cele mai cunoscute vulnerabilități de pe Internet. Această clasă de vulnerabilități este înregistrată în cele mai mari cataloage de vulnerabilități: Common Weakness Enumeration [26] și CAPEC [27] . Esența atacului este următoarea. Există servicii care acceptă protocoalele SOAP și XML-RPC care acceptă introducerea sub forma unui document XML . Standardul documentului XML acceptă includerea unei secțiuni DTD , iar secțiunile DTD, la rândul lor, pot conecta componente suplimentare la document, așa- numitele entități externe [ 28 ] . Entitățile externe sunt fișiere separate și sunt specificate folosind cuvântul cheie SYSTEM și URI. Dacă parserul XML nu se validează, poate pur și simplu să încarce entitatea externă și să o atașeze la conținutul documentului XML. Un atacator poate înlocui în URI-ul fișierului de entitate externă un URI care indică către un dispozitiv hardware al computerului sau către un fișier local din sistem. Serverul va încerca să citească fișierul la URI-ul specificat și să includă conținutul acestuia în XML. Când se utilizează un astfel de mecanism, sunt posibile următoarele tipuri de atacuri [29] :
Vulnerabilitatea XXE din comunitatea http://xml.org (site-ul organizației non-profit OWASP ) a fost discutată încă din 2001 [30] , dar acestea au fost doar gânduri teoretice despre posibilitatea unui astfel de atac. Prima persoană care a atras atenția publicului asupra acestei vulnerabilități a fost Gregory Steuck [31 ] . În 2002, a trimis un aviz de securitate (manual de securitate ) la www.securityfocus.com [29] , în care a descris vulnerabilitatea în detaliu și i-a dat numele XXE Attack .
Multe produse au fost afectate de atacul XXE. Toate bazele de date majore cu vulnerabilități software pot găsi produse software vulnerabile la atacurile XXE: National Vulnerability Database [32] , Common Vulnerabilities and Exposures [33] , Open Source Vulnerability Database [34] . Vulnerabilitatea la „atacuri XXE” a fost descoperită în produse cunoscute precum JDK și JRE (a șasea versiune, a treia actualizare) [33] [35] , WebKit și browserul bazat pe acesta Safari (a treia versiune) [ 36] [37] , Spring Framework [38] , CakePHP [39] , Adobe Reader (Versiunea 7) [40] , Zend Framework [41] , Squiz [42] , etc.
Schema de fișiere URI a fost descrisă pentru prima dată în iunie 1994 în RFC 1630 („Universal Resource Identifiers în WWW”). În decembrie acelui an, a fost standardizat în RFC 1738 (Uniform Resource Locators (URL)). RFC 1738 descrie formatul general de URL și este acum învechit, cu excepția a două secțiuni care descriu schemele de fișiere și ftp. Noul RFC 3986 (Uniform Resource Identifier (URI): Sintaxă generică), lansat în 2005, a încorporat RFC 1738 , a făcut modificări minore, dar nu a descris scheme individuale. Până atunci, aproape toate schemele din secțiunea permanentă primiseră propriul standard separat. Vechiul RFC 1738 a precizat doar formatul schemei, dar nu a definit regulile de aplicare a acestei scheme și de conversie a unei căi locale într-un URI și invers. A fost nevoie de standardizarea schemei de fișiere, precum și a unui număr de alte scheme nestandardizate.
În 2004, Paul Hoffman, care este membru al IETF de la începutul anilor 1990, a început procesul de standardizare a schemei de fișiere. În luna iunie, el a scris specificații separate pentru schemele fișier, ftp, gopher, news și nntp, prospero și telnet, iar pe 17 iunie 2004 au fost publicate pe site-ul ietf.org, iar pe 19 iunie a anunțat-o. pe lista de corespondență [43] . Prima revizuire a standardului schemei de fișiere a fost numită „The file URI Scheme” [44] . Pe 19 iunie, Paul Hoffman a anunțat că proiectul a început o discuție activă. Au existat multe comentarii din partea comunității IETF, iar a doua revizuire [45] urmată de a treia [46] și a patra [47] a urmat curând . Dar nu s-a ajuns niciodată la un consens. Pentru a continua lucrul la standard, Mike Brown a creat un site wiki special https://offset.skew.org/wiki/URI/File_scheme , unde s-a lucrat ceva timp pentru a colecta informații cu privire la schema fișierului. Dar curând această activitate a încetat, iar standardul nu a fost niciodată adoptat.
În 2013, Matthew Kerwin face o altă încercare de a standardiza schema fișierului. În iunie 2013 a fost publicată prima revizuire a proiectului [48] , a început o discuție a proiectului, iar în perioada iunie-septembrie 8 au fost publicate alte revizuiri. Cea mai recentă revizuire (#8, adică a noua [Nota 4] ) a proiectului a fost publicată la 18 septembrie 2013 [49]
| scheme URI | |
|---|---|
| Oficial | |
| neoficial | |