Falsificarea solicitărilor între site-uri (CSRF/XSRF), cunoscută și sub numele de Sea Surf sau Session Riding, este o vulnerabilitate de securitate web care păcălește un browser să execute o acțiune nedorită. În consecință, atacatorul abuzează încrederea pe care o are pentru o aplicație web, ocolind parțial politica ce impune solicitărilor să aibă aceeași sursă, politică menită să împiedice diferite site-uri web să interfereze între ele.

 

Care este impactul atacurilor CSRF?

 

Atunci când un site web trimite o solicitare de date către un alt site web în numele unui utilizator împreună cu cookie-urile sesiunii utilizatorului, un atacator poate lansa un atac de falsificare a solicitărilor încrucișate.

În unele cazuri, în funcție de tipul de acțiune, atacatorul poate obține controlul deplin asupra contului utilizatorului. Dacă utilizatorul compromis are un rol privilegiat în cadrul aplicației, atacatorul ar putea fi capabil să preia controlul total asupra tuturor funcționalităților și datelor aplicației, ceea ce este devastator atât pentru companie, cât și pentru utilizator. De la furt de date, la transferuri neautorizate de fonduri, cu impact negativ în relațiile cu clienții, parole schimbate și multe altele.

 

Cum functionează un atac CSRF?

 

Când un utilizator încearcă să acceseze un site, browserul include adesea automat acreditările în cerere, pentru a face procesul de conectare mai rapid. Aceste acreditări pot include cookie-uri de sesiune, acreditări de autentificare, adresa IP și acreditările de domeniu Windows. 

Riscul acestui mecanism este că atacatorii pot folosi identitatea utilizatorului. Odată ce un utilizator trece de verificarea identității, site-ul nu poate face diferența între o cerere falsificată și o cerere legitimă ale unui utilizator.

Într-un atac CSRF, un atacator își asumă identitatea victimei și o folosește pentru a efectua acțiuni în numele utilizatorului, fără consimțământul acestuia. Metodele folosite pot fi:

• prin tehnici de inginerie socială pentru a convinge victima să facă clic pe un link prin e-mail, mesaj prin chat sau o formă similară de comunicare
• prin link-uri atacatoare, fie o pagină web pe care utilizatorul o vizitează și declanșează o solicitare către site-ul vizat

 

Atacurile CSRF încearcă de obicei să schimbe statusul pe server, dar pot fi folosite și pentru a obține acces la date sensibile. Dacă un atacator efectuează cu succes un atac CSRF împotriva contului victimei, acesta poate transfera fonduri, cumpăra un produs, poate modifica informații despre cont, cum ar fi adresa de expediere, poate modifica parola sau orice altă acțiune disponibilă atunci când utilizatorul este conectat.

 

Ce reprezintă un token CSRF?

Un token CSRF este o valoare secretă unică, imprevizibilă, generată de o aplicație pe server și care este trimisă clientului pentru a fi inclusă în cererile HTTP ulterioare emise de client. După emiterea token-ului, atunci când clientul face o cerere, serverul verifică dacă cererea conține tokenul așteptat și execută comenzile doar dacă este validat.

Tokenurile CSRF pot preveni atacurile CSRF, deoarece împiedică atacatorii să formeze cereri HTTP complet valide, pe care le pot transmite unei victime. Atacatorul nu poate determina sau prezice valoarea token-ului CSRF al utilizatorului, așa că orice cerere pe care o generează nu ar trebui să fie acceptată de aplicație.

 

Vulnerabilități comune CSRF

Unele dintre cele mai comune vulnerabilități CSRF sunt cauzate de erori în procesul de verificare a token-ului CSRF. Asigurați-vă că procesul dvs. CSRF nu are niciuna dintre următoarele punct:

Validarea depinde de prezența token-ului

În unele aplicații, procesul de verificare este omis dacă token-ul nu există. Aceasta înseamnă că atacatorul trebuie doar să găsească codul care conține informații despre jeton și să îl elimine, iar validarea sa nu este efectuată de aplicație.

Indicatorul CSRF nu este asociat cu sesiunea utilizatorului

Unele aplicații mențin un pool de token-uri și, atâta timp cât se folosește un token din pool, acesta este acceptat. Cu toate acestea, aplicația nu leagă anumite token-uri de anumiți utilizatori. Un atacator trebuie doar să obțină cel puțin un token din grup și îl poate folosi pentru a uzurpa identitatea oricărui utilizator.

Se modifică validarea token-ului cu metoda HTTP

În unele aplicații, utilizarea metodei GET în loc de metoda POST va face ca validarea CSRF să nu funcționeze corect. Atacatorul trebuie pur și simplu să treacă de la POST la GET și să ocolească cu ușurință procesul de verificare.

 

Indicatorul CSRF este copiat în cookie

Unele aplicații nu păstrează o evidență a token-urilor deja utilizate. În schimb, ei copiază parametrii de solicitare asociați fiecărui token în cookie-ul utilizatorului. În această configurare, atacatorul poate crea un cookie care conține un token folosind formatul așteptat al aplicației, îl poate plasa în browserul utilizatorului și apoi poate executa un atac CSRF. Solicitarea trimisă de browserul utilizatorului va fi validată, deoarece se va potrivi cu cookie-ul rău intenționat furnizat de atacator.

 

Prevenirea CSRF: dincolo de jetoanele CSRF

Modul de bază de a preveni CSRF este implementarea token-urilor CSRF, evitând în același timp punctele slabe descrise în secțiunea anterioară. Iată modalități suplimentare în care puteți preveni atacurile CSRF.

Utilizați tehnici avansate de validare CSRF

Un atacator poate iniția un atac CSRF atunci când toți parametrii utilizați în formular sunt identificați. Prin urmare, pentru a preveni un atac CSRF, puteți adăuga un parametru suplimentar cu o valoare suplimentară de care atacatorul nu este conștient, dar serverul necesită validare.  Se poate introduce de exemplu un id de articol criptat, care poate fi validat pe server prin decriptare folosind cheia setată.

Atunci când un utilizator face o cerere autentificată prin trimiterea unui formular, un simbol aleator ar trebui să fie inclus în cererea respectivă. Apoi site-ul web va verifica apariția acestui token înainte de a procesa cererea trimisă și dacă tokenul lipsește sau valoarea este incorectă, cererea va fi respinsă și atacatorul nu va putea lansa un atac CSRF.

Atribut SameSite 

Atributul cokie SameSite, definit în RFC 6265 bis , încearcă să prevină atacurile CSRF. Atributul îi spune browserului când este în regulă să trimită module cookie cu solicitări între site-uri. Atributul SameSite vine cu trei valori posibile – Strict, Lax, sau None. Majoritatea browserelor mobile și toate browserele desktop acceptă acest atribut.

Valoarea Strict spune browserului să nu trimită un cookie către site în timpul unei sesiuni de navigare între site-uri. Aceasta include o sesiune care urmează un link obișnuit. De exemplu, atunci când un utilizator se conectează la GitHub și navighează într-un proiect GitHub privat găzduit de o corporație, browserul nu trimite un cookie de sesiune la GitHub, limitând accesul la proiect. 

Dacă nu este necesar să permiteți site-urilor externe să trimită către pagini tranzacționale, puteți utiliza valoarea Strict. Cu toate acestea, dacă trebuie să creați un echilibru între utilizare și securitate, permițând utilizatorilor direcționați prin linkuri externe să mențină sesiunile conectate - ar trebui să utilizați valoarea implicită Lax. În general, solicitările pe mai multe site-uri acordate în timpul modului Lax sunt considerate metode HTTP sigure .

Apărare CSRF bazată pe interacțiunea utilizatorului

Deseori, mecanismele de apărare care necesită intervenția utilizatorului pot avea un impact negativ asupra experienței utilizatorului. Cu toate acestea, în unele cazuri, cum ar fi tranzacțiile financiare, este adecvată și necesară implementarea acestui tip de tehnică. De exemplu, puteți adăuga un CAPTCHA, care ajută la validarea faptului că este într-adevăr un utilizator uman, mai degrabă decât un robot.

Poate chiar securizare în doi sau  mai mulți pași. Un token unic/solicitare ne poate asigura că este utilizatorul și nu un atacator care utilizează o sesiune conectată. Tokenul este de obicei trimis la adresa de e-mail sau numărul de telefon al utilizatorului, validând cu informațiile furnizate anterior de utilizator. În plus, puteți introduce re-autentificarea, care poate ajuta la diferențierea între o sesiune CSRF și un utilizator real.

Autentificare securizată cu token CSRF

Mulți dezvoltatori ignoră vulnerabilitățile CSRF în formularul de conectare al unei aplicații. Acest lucru se datorează faptului că utilizatorul nu este încă autentificat în această etapă, astfel încât dezvoltatorii presupun că nu există niciun risc de CSRF. Însă atacatorii pot efectua atacuri CSRF de conectare, care pot avea impacturi diferite în funcție de aplicație.

Atacurile CSRF de conectare pot fi atenuate prin crearea unei pre-sesiuni (începerea unei sesiuni înainte de autentificarea utilizatorului) și prin solicitarea token-ului în formularul de conectare. 

Este dificil să preveniți atacuri CSRF de conectare dacă nu aveți încredere în subdomenii (de exemplu, dacă permiteți utilizatorilor să-și definească propriile subdomenii). În aceste cazuri, puteți utiliza verificarea strictă a antetului de referință la nivel de subdomeniu și de cale pentru a reduce riscul CSRF pe formularele de conectare.

Efectuați periodic teste de securitate a aplicațiilor web

Chiar dacă vulnerabilitățile din aplicațiile web cu atacuri CSRF sunt abordate cu succes, actualizările aplicației și modificările codului vă pot expune aplicația la CSRF în viitor. Testarea de securitate a aplicațiilor web vă ajută să scanați și să testați în mod continuu eventualele deficiențe de securitate ale aplicațiilor web, inclusiv vulnerabilitățile CSRF.

Pentru a lansa o nouă soluție, puteți achiziționa domeniile preferate la cele mai convenabile prețuri folosind soluția rapidă de înregistrare domenii  și să  investiți într-un plan de găzduire securizat și optim - alegând o soluție de hosting NSHOST web shared, VPS sau Cloud. Recomandă atenție deosebită strategiei de caching potrivite afacerii dvs pentru a asigura timpi optimi de încărcare a fiecărei pagini web.