CSRF ( în engleză cross-site request forgery - „cross-site request forgery”, cunoscut și sub numele de XSRF) este un tip de atac asupra vizitatorilor site- ului web care utilizează deficiențele protocolului HTTP . Dacă o victimă vizitează un site creat de un atacator, o solicitare este trimisă în secret în numele victimei către un alt server (de exemplu, către un server de sistem de plată) care efectuează un fel de operațiune rău intenționată (de exemplu, transferul de bani către un atacator). cont). Pentru a realiza acest atac, victima trebuie să fie autentificată pe serverul către care este trimisă cererea, iar această solicitare nu trebuie să necesite nicio confirmare din partea utilizatorului., care nu poate fi ignorat sau falsificat de un script atacator .
Acest tip de atac, contrar concepției greșite populare, a apărut cu destul de mult timp în urmă: primele considerații teoretice au apărut în 1988 [1] , iar primele vulnerabilități au fost descoperite în 2000 . Iar termenul în sine a fost introdus de Peter Watkins în 2001 .
Principala utilizare a CSRF este de a forța efectuarea oricărei acțiuni pe un site vulnerabil în numele victimei ( schimbarea parolei , întrebare secretă pentru recuperarea parolei, e-mail, adăugarea unui administrator etc.). De asemenea, este posibil să se exploateze XSS reflectat detectat pe un alt server folosind CSRF .
Atacul este realizat prin plasarea unui link sau a unui script pe o pagină web care încearcă să acceseze un site pe care utilizatorul atacat este cunoscut (sau probabil) deja autentificat. De exemplu, utilizatorul Alice ar putea naviga pe un forum unde un alt utilizator, Bob , a postat un mesaj. Lăsați Bob să creeze o etichetă <img> , în care a specificat URL-ul ca sursă a imaginii , când faceți clic pe ea, se efectuează o acțiune pe site-ul băncii lui Alice, de exemplu:
Bob: Bună Alice! Uite ce drăguță este această pisică: <img src="http://bank.example.com/?account=Alice&amount=1000000&for=Bob">Dacă banca lui Alice stochează informațiile de autentificare ale lui Alice într-un cookie și dacă cookie-ul nu a expirat încă, atunci când încearcă să descarce imaginea , browserul lui Alice va trimite un cookie în solicitarea de a transfera bani în contul lui Bob, care va confirma autentificarea lui Alice. Astfel, tranzacția va fi finalizată cu succes, deși confirmarea acesteia va avea loc fără știrea Alicei.
Toate cererile care modifică datele de pe server, precum și solicitările care returnează date personale sau alte date sensibile, trebuie protejate.
Cel mai simplu mod de a vă proteja împotriva acestui tip de atac este să solicitați site-urilor web să solicite confirmarea majorității acțiunilor utilizatorului și să verificați câmpul HTTP_REFERER dacă este specificat în cerere. Cu toate acestea, această metodă poate fi nesigură și nu este recomandată [2] .
O altă metodă comună de protecție este un mecanism în care o cheie unică secretă suplimentară este asociată fiecărei sesiuni de utilizator, concepută pentru a îndeplini cererile. Cheia secretă nu trebuie transmisă în clar, de exemplu, pentru solicitările POST , cheia ar trebui să fie transmisă în corpul cererii, nu în adresa paginii. Browserul utilizatorului trimite această cheie ca parte a parametrilor fiecărei solicitări, iar serverul verifică această cheie înainte de a lua orice acțiune. Avantajul acestui mecanism, în comparație cu verificarea Referer, este protecția garantată împotriva atacurilor CSRF. Dezavantajele sunt cerința posibilității de organizare a sesiunilor utilizatorilor, cerința generării dinamice a codului HTML pentru paginile site-ului, precum și nevoia de protecție împotriva XSS și a altor atacuri care permit unui atacator să obțină o cheie unică.
Specificația protocolului HTTP/1.1 [3] definește metode de solicitare sigure, cum ar fi GET, HEAD, care nu ar trebui să modifice datele de pe server. Pentru astfel de solicitări, atâta timp cât serverul respectă specificațiile, nu este nevoie să se aplice protecție CSRF.
Poate doriți să jucați în siguranță și să adăugați o cheie la fiecare cerere, dar rețineți că specificația HTTP/1.1 [3] permite prezența unui corp pentru orice solicitare, dar pentru unele metode de solicitare (GET, HEAD, DELETE) semantica corpului cererii nu este definită și ar trebui ignorată. Prin urmare, cheia poate fi transmisă numai în URL-ul propriu-zis sau în antetul solicitării HTTP. Trebuie să protejați utilizatorul de distribuirea din greșeală a cheii ca parte a unui URL, cum ar fi într-un forum în care cheia ar putea fi pusă la dispoziție unui atacator. Prin urmare, cererile cu o cheie în URL nu trebuie folosite ca adresă la care să mergeți, adică să evitați să mergeți la o astfel de adresă prin script client, redirecționare server, acțiune de formular, hyperlink pe pagină etc. pentru a ascunde cheia inclusă în URL. Ele pot fi folosite doar ca solicitări interne de către un script care utilizează XMLHttpRequest sau un wrapper precum AJAX .
Este esențial ca cheia (tokenul CSRF) să nu fie destinată unei cereri sau unui formular specific, ci pentru toate solicitările utilizatorilor în general. Prin urmare, este suficient să scurgi un token CSRF dintr-un URL care efectuează o acțiune simplă sau deloc, astfel încât orice acțiune, nu doar cea cu care este asociată URL-ul acum cunoscut, să piardă protecția împotriva falsificării cererii.
Există o versiune mai rigidă a mecanismului anterior, în care o cheie unică este asociată cu fiecare acțiune. Această metodă este mai dificil de implementat și necesită resurse. Metoda este folosită de unele site-uri și portaluri, precum Livejournal , Rambler etc. Pentru anul 2016 nu au existat informații despre avantajul unei opțiuni mai rigide față de opțiunea care folosește o singură cheie secretă pentru fiecare sesiune [4] .