Politika istog izvora

(преусмерено са Polisa zajedničkog porekla)

U računarstvu, politika istog izvora (engl. same-origin policy) je bitan koncept u sigurnosnom modelu veb-aplikacije. Ona dozvoljava skriptama koje rade na stranicama poreklom sa istog sajta – kombinacija sheme (енгл. URI scheme), hostname-a i računarskog porta (енгл. Port (computer networking)) [1] – da pristupe međusobnom objektnom modelu dokumenata (DOM) bez posebnih ograničenja, ali sprečava pristup DOMu drugih sajtova.[1] Politika istog izvora se takođe primenjuje na XMLHttpRequest-ove osim u slučaju da server pruža Access-Control-Allow-Origin (CORS) zaglavlje. WebSocket-i naročito nisu podležni ovom konceptu.

Mehanizam nosi posebni značaj za moderne web-aplikacije koje veoma zavise od HTTP kolačića (енгл. cookie) da bi održali korisničke sesije, zato što se serveri ponašaju u zavisnosti od informacije HTTP kolačića kako bi otkrili osetljive informacije ili kako bi promenili stanje. Striktna razdvojenost od sadržaja koji snabdeva nepovezani sajt mora biti održana od strane klijenta kako bi se izbegao gubitak poverljivosti i integriteta podataka.

IstorijaУреди

Koncept politike istog izvora datira od veb-pregledača Netscape Navigator 2 iz 1995. godine. Svi moderni pregledači koriste neku formu poreklo-polise jer je to kamen temeljac bezbednosti pregledača[2]. Polise ne moraju da se poklapaju sa nekom preciznom specifikacijom[3] ali se često koriste kako bi definisali ugrubo kompatibilne bezbednosne granice za druge skriptne jezike kao što su Adobe Flash ili Adobe Acrobat, ili za mehanizme nevezane za direktnu DOM manipulaciju, kao na primer XMLHttpRequest.

Pravila određivanja poreklaУреди

Algoritam koji se koristi da izračuna „poreklo” URI-a je precizirano u RFC 6454, četvrti odeljak. Za apsolutne URI-je, poreklo je trodelno (protokol, host, port). Ako URI ne koristi hijerarhijski element kao nazivni autoritet (videti RFC 3986, odeljak 3.2) ili ako URI nije apsolutni URI, onda se koristi globalno jedinstven identifikator. Za dva resursa se smatra da su istog porekla samo ako su njihove vrednosti potpuno jednake.

Ilustracije radi, naredna tabela nam daje pregled tipičnih ishoda koristeci URL "http://www.example.com/dir/page.html[мртва веза]".

URL sa kojim se upoređuje Ishod Razlog
http://www.example.com/dir/page2.html Success Same protocol and host
http://www.example.com/dir2/other.html Success Isti protokol i host
http://username:password@www.example.com/dir2/other.html Success Same protocol and host
http://www.example.com:81/dir/other.html Failure Same protocol and host but different port
https://www.example.com/dir/other.html[мртва веза] Failure Different protocol
http://en.example.com/dir/other.html Failure Different host
http://example.com/dir/other.html Failure Different host (exact match required)
http://v2.www.example.com/dir/other.html Failure Different host (exact match required)
http://www.example.com:80/dir/other.html Deppends Port explicit. Depends on implementation in browser.

Za razliku od drugih pregledača, Internet Explorer ne uključuje port u računanju porekla, on koristi Security Zone umesto toga[4] .

Opuštanje politike istog izvoraУреди

U nekim okolnostima politika istog izvora je previše restriktivna, pa predstavlja problem za velike web-sajtove koji koriste više poddomena. Evo četiri načina da se polisa opusti :

document.domain odlikeУреди

Ako dva prozora (ili frejma) sadrže skriptu koja postavlja domen na istu vrednost, politika istog izvora je opuštena za ova dva prozora, i oni mogu međusobno dejstvovati. Na primer, sarađujući skripti u dokumentima očitanim iz orders.example.com i catalog.example.com mogu postaviti da njihov document.domain bude „example.com”, i tako bi dokumenti izgledali kao da su isto porekla i dozvolili bi svakom dokumentu da pročita odlike ovog drugog. Ovo možda neće svaki put raditi, jer bi port sklonjen u internu reprezentaciju mogao da bude oznacen sa null. Drugim rečima, example.com port 80 će postati example.com port null zato što se document.domain update-uje. Port null se ne može tretirati kao 80 (u zavisnosti od korišćenog pregledača) i zato može da propadne ili uspe u zavisnost od pregledača.[5]

Cross-Origin deljenje resursaУреди

Druga tehnika za opuštanje postaje standardizovana kao Cross-Origina deljenje resursa (Cross-Origin resource sharing). On produžava HTTP sa novim Origin request zaglavljem i novim CORS uzajamnim zaglavljem. To dozvoljava serverima da koristi zaglavlja da eksplicitno navodi porekla koja mogu da traže fajl ili da iskoriste „wildcard” i dozvole fajlu da bude tražen od strane bilo kog sajta. Pregledači kao što je Firefox 3.5 i Safari 4 koriste ovo novo zaglavlje da dozvole cross-origin HTTP zahteve sa XMLHttpRequest-om koji bi inače bili zabranjeni politikom istog izvora.[6]

Cross-document messagingУреди

Još jedna nova tehnika, cross-document messaging dozvoljava skriptu sa jedne strane da prosleđuje tekstualne poruke skripti na drugoj stranici nezavisno od porekla skripta. Calling the postMessage() method on a Window object asynchronously fires an "onmessage" event in that window, triggering any user-defined event handlers. Skript na jednoj strani i dalje ne može direktno pristupiti metodama ili varijablama na drugoj strani, ali oni mogu komunicirati bez opasnosti koristeći ovu metodu.

JSONPУреди

JSONP dozvoljava stranici da primi JSON podatke sa različitog domena tako što doda <script> element stranici koja očitava JSON odgovor sa drugog domena.

Corner slučajevi i izuzeciУреди

Ponašanje provera i sličnih mehanizama politike istog izvora nije dobro definisana u nekoliko corner slučajeva kao na primer za pseudo-protokole koji nemaju jasno definisano host ime ili port povezan sa svojim URLom (file:, data:, itd.). Ovo je stvaralo popriličan broj sigurnosnih problema, kao što su generalno nepoželjna mogućnost svakog lokalno sačuvanog HTML fajla da pristupi svim drugim fajlovima na disku, ili da komunicira sa bilo kojim sajtom na internetu. Takođe, mnoge cross-domain operacije koje su bile pre JavaScript-a nisu podležne proveri politike istog izvora. Jedan takav primer je mogućnost uključivanja skripta preko domena. Na kraju, određeni tipovi napada, kao što je DNS rebinding ili serverski proksiji, dozvoljavaju da se provera host name-a obori, i omogućavaju odbeglim veb stranicama interakciju sa sajtovima kroz adrese koje nisu njihovog pravog porekla. Ovi napadi su opasnost samo u posebnim situacijama, zato što pregledač i dalje veruje da interakciju vrši sa napadačkim sajtom, i zato ne deli kolačiće trećih lica ili druge osetljive podatke napadaču.

UblažavanjaУреди

Da bi omogucili projektantu da zaobiđe politiku istog izvora, nekoliko „hakova”, kao što je na primer identifikator fragmenata ili window.name odlika su korišćeni za prosleđivanje podataka između dokumenata koji su u različitim domenima. Sa HTML5 standardom, metoda je formalizovana za ovo : postMessage interfejs,[7][8] koji se jedino nalazi na novijim pregledačima.[9] JSONP takođe može da se iskoristi kako bi omogućio pozive slične Ajax-u drugim domenima.[10]

ReferenceУреди

  1. ^ а б Same Origin Policy - Web Security. W3.org. Retrieved on 2013-08-20.
  2. ^ „Browser Security Handbook, part 2”. google.com. Приступљено 31. 1. 2014. 
  3. ^ „Same Origin Policy”. W3C. Приступљено 31. 1. 2014. 
  4. ^ Lawrence, Eric. „IEInternals - Same Origin Policy Part 1”. Приступљено 22. 10. 2013. 
  5. ^ LePera, Scott. „Cross-domain security woes”. The Strange Zen Of JavaScript. Приступљено 4. 4. 2014. 
  6. ^ Cross-Origin Resource Sharing. W3.org. Retrieved on 2013-08-20.
  7. ^ HTML Living Standard. Communication: Cross-document messaging: Posting messagesWHATWG.
  8. ^ HTML5. Communication: Cross-document messaging: Posting messages Архивирано на сајту Wayback Machine (16. октобар 2012) — W3C.
  9. ^ When can I use: Support for Cross-document messaging
  10. ^ „Blog Post: Using CORS with all (modern) browsers”. 

Spoljašnje vezeУреди