Înțelegerea atacurilor CSRF și blocarea vulnerabilităților CSRF

Vulnerabilitățile web sunt rampante și în continuă creștere. Menținerea securității și confidențialității utilizatorilor dvs. este mai importantă ca niciodată. Nerezolvarea vulnerabilităților web poate duce la o reputație ruinată și la amenzi mari din partea autorităților de reglementare și, de asemenea, veți pierde încrederea utilizatorilor.

Site-urile web și aplicațiile web sunt vulnerabile la malware, spam și alte atacuri - acest articol se concentrează pe un astfel de vector de atac - atacurile Cross-Site Request Forgery (CSRF). Atacurile CSRF sunt deosebit de îngrijorătoare, deoarece pot apărea fără știrea utilizatorului. De asemenea, sunt dificil de detectat de către un dezvoltator sau un proprietar de site, deoarece solicitările rău intenționate par foarte asemănătoare cu cererile reale.

Acest articol explorează un atac CSRF, cum funcționează și pașii pe care îi puteți lua pentru a vă pregăti pentru unul.

Ce este un atac CSRF?

Un atac Cross-Site Request Forgery, cunoscut și sub numele de atac CSRF, păcălește un utilizator autentificat să efectueze acțiuni neintenționate, trimițând cereri rău intenționate fără ca acesta să-și dea seama.

De obicei, un atac CSRF implică solicitări de schimbare a stării, deoarece atacatorul nu primește un răspuns. Exemple de astfel de solicitări includ ștergerea unei înregistrări, schimbarea unei parole, achiziționarea unui produs sau trimiterea unui mesaj. Toate acestea pot apărea fără știrea utilizatorului.

Atacatorul rău intenționat folosește de obicei ingineria socială pentru a trimite unui utilizator nebănuit un link prin chat sau e-mail.

Când utilizatorul face clic pe link, acesta execută comenzile pe care le setează atacatorul.

De exemplu, un clic pe un link poate transfera fonduri din contul unui utilizator. Sau, poate schimba adresa de e-mail a unui utilizator, împiedicându-l să recâștige accesul la cont.

Cum funcționează un atac CSRF?

A face utilizatorul să inițieze o solicitare de schimbare a stării în timp ce este conectat este primul și cel mai important pas într-un atac CSRF. Cu atacurile CSRF, atacatorul urmărește să determine un utilizator autentificat să trimită, fără să știe, o solicitare web rău intenționată către un site web sau o aplicație web. Aceste solicitări pot consta în cookie-uri, parametri URL și alte tipuri de date care par normale pentru utilizator.

Pentru ca un atac CSRF să aibă succes, trebuie să apară următoarele condiții:

• Un utilizator autentificat trebuie să fie conectat la o aplicație web care utilizează cookie-uri pentru gestionarea sesiunii.
• Un atacator trebuie să creeze o cerere falsificată de schimbare a stării.
• Solicitările autentice gestionate de serverul țintă nu trebuie să conțină parametri imprevizibili. De exemplu, cererea nu ar trebui să aștepte o parolă ca parametru în scopuri de verificare înainte de a iniția cererea de schimbare a stării.

Cea mai comună metodă de finalizare a atacurilor CSRF este utilizarea cookie-urilor în aplicații cu o politică SameSite de cookie-uri slabă. Browserele web includ cookie-uri automat și adesea anonim și salvează cookie-uri utilizate de un domeniu în orice solicitare web pe care un utilizator o trimite către acel domeniu.

Politica de cookie-uri SameSite definește modul în care browserul în contexte de navigare pe mai multe site-uri tratează cookie-ul. Dacă este setat la strict, cookie-ul nu este partajat în contexte de navigare pe mai multe site-uri, prevenind atacurile CSRF. Browserul atașează cookie-ul în toate contextele între site-uri dacă este setat la niciunul. Acest lucru lasă aplicația vulnerabilă la atacurile CSRF.

Când un utilizator trimite fără să știe o solicitare rău intenționată printr-un browser web, cookie-urile salvate fac ca cererea să pară legitimă pentru server. Serverul răspunde apoi la cerere schimbând contul utilizatorului, schimbând starea sesiunii sau returnând datele solicitate.

Să aruncăm o privire mai atentă la două exemple de căi de atac CSRF, unul cu o solicitare GET și celălalt cu o cerere POST.

CSRF pentru o solicitare GET

În primul rând, luați în considerare o solicitare GET utilizată de o aplicație web de servicii bancare financiare, în care atacul exploatează o solicitare GET și livrarea unui hyperlink.

Să presupunem că cererea GET pentru transferul de bani arată cam așa:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

În cererea autentică de mai sus, utilizatorul solicită să transfere 1.000 USD într-un cont cu 547895 ca plată pentru produsele achiziționate.

Deși această solicitare este explicită, simplă și practică, expune titularul contului la un atac CSRF. Asta pentru că cererea nu necesită detalii pe care un atacator ar putea să nu le cunoască. Deci, pentru a iniția un atac, un atacator ar trebui doar să modifice parametrii acestei solicitări (suma și numărul contului) pentru a crea o cerere executabilă falsificată.

Solicitarea rău intenționată ar fi eficientă pentru oricare dintre utilizatorii băncii, atâta timp cât au sesiuni în desfășurare gestionate de cookie-uri.

Iată cum ar arăta cererea falsificată de a transfera 500 USD în contul unui hacker (aici, numărul 654585 ). Rețineți că exemplul de mai jos este o versiune foarte simplificată a pașilor implicați într-un atac CSRF pentru o explicație.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Odată ce este finalizat, atacatorul trebuie să găsească o modalitate de a păcăli utilizatorul să trimită această solicitare în timp ce este conectat la aplicația sa de servicii bancare online. Una dintre modalitățile de a face acest lucru este crearea unui hyperlink inofensiv care să atragă atenția utilizatorului. Linkul poate arăta astfel:

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Având în vedere că atacatorul a găsit adresele de e-mail corecte ale țintelor lor, poate trimite acest lucru prin e-mail către mulți clienți ai băncii. Cei care fac clic pe link în timp ce sunt autentificați ar declanșa solicitarea de a trimite atacatorului 500 USD din contul conectat.

CSRF pentru o solicitare POST

Să vedem cum ar experimenta aceeași instituție financiară un CSRF dacă ar accepta doar cereri POST. În acest caz, livrarea hyperlink utilizată în exemplul de solicitare GET nu ar funcționa. Prin urmare, un atac CSRF de succes ar necesita un atacator să creeze un formular HTML. Solicitarea autentică de a trimite 1.000 USD pentru un produs achiziționat ar arăta astfel:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

Această solicitare POST necesită un cookie pentru a determina identitatea utilizatorului, suma pe care dorește să o trimită și contul pe care dorește să-l trimită. Atacatorii pot modifica această solicitare pentru a efectua un atac CSRF.

Atacatorul trebuie să adauge doar un cookie autentic la o cerere falsificată pentru ca serverul să proceseze transferul. Ei pot face asta prin crearea unui hyperlink cu aspect inofensiv care duce utilizatorul la o pagină web de declanșare care arată astfel:

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

Am setat deja suma și parametrii contului în formularul de mai sus. Odată ce un utilizator autentificat vizitează pagina, browserul adaugă cookie-ul de sesiune înainte de a redirecționa cererea către server. Serverul trimite apoi 500 USD către contul hackerului.

3 moduri de a reduce atacurile CSRF

Există mai multe metode pentru a preveni și a atenua drastic potențialele atacuri CSRF asupra site-ului sau aplicației dvs. web, inclusiv:

• Folosind jetoane CSRF
• Folosind antetul referitor
• Alegerea unei soluții de găzduire axată pe securitate, cum ar fi Kinsta

Cum să preveniți atacurile CSRF folosind jetoane CSRF

Un site web securizat CSRF atribuie fiecărei sesiuni un simbol unic și îl partajează cu partea serverului și cu browserul client. Ori de câte ori un browser trimite o solicitare sensibilă, serverul se așteaptă ca aceasta să conțină jetonul CSRF alocat. Dacă are un simbol greșit, serverul îl renunță. Tokenul CSRF nu este stocat în module cookie de sesiune din browserul clientului din motive de securitate.

Vulnerabilități potențiale ale jetoanelor CSRF

Deși jetoanele CSRF sunt o măsură de securitate excelentă, această metodă nu este rezistentă la atacuri. Unele dintre vulnerabilitățile care însoțesc jetoanele CSRF includ:

• Ocolire validare — Unele aplicații omit pasul de verificare dacă nu găsesc un simbol. Dacă un atacator obține acces la codul care conține un token, poate elimina acel token și poate executa cu succes un atac CSRF. Deci, dacă o solicitare validă către un server arată astfel:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Un atacator trebuie doar să elimine jetonul și să îl trimită astfel pentru a executa atacul:

 POST /change_password POST body: password=pass123

• Jetoane grupate — Unele aplicații mențin un grup de simboluri pentru a valida sesiunile utilizatorilor în loc să desemneze un anumit token pentru o sesiune. Un atacator trebuie doar să obțină unul dintre jetoanele care se află deja în pool pentru a uzurpa identitatea oricăruia dintre utilizatorii site-ului.

Un atacator se poate conecta la o aplicație folosind contul său pentru a obține un token, cum ar fi:

 [application_url].com?csrf_token=93j9d8eckke20d433

Și, deoarece jetoanele sunt grupate, atacatorul poate copia și utiliza același simbol pentru a se conecta la un alt cont de utilizator, deoarece îl veți folosi din nou:

• CSRF-urile pot fi copiate cu simboluri în cookie — Unele aplicații vor copia parametrii legați de un simbol în cookie-ul utilizatorului. Dacă un atacator obține acces la un astfel de cookie, poate crea cu ușurință un alt cookie, îl poate plasa într-un browser și poate executa un atac CSRF.

Deci, un atacator se poate conecta la o aplicație folosind contul său și poate deschide fișierul cookie pentru a vedea următoarele:

 Csrf_token:93j9d8eckke20d433

Apoi pot folosi aceste informații pentru a crea un alt cookie pentru a finaliza atacul

• Indicative nevalide — Unele aplicații nu potrivesc indicativele CSRF cu o sesiune de utilizator. În astfel de cazuri, un atacator se poate autentifica cu adevărat într-o sesiune, poate obține un token CSRF similar celor de mai sus și îl poate folosi pentru a orchestra un atac CSRF asupra sesiunii unei victime.

Cum să preveniți atacurile CSRF cu antetul referitor

O altă strategie pentru prevenirea atacurilor CSRF este utilizarea antetului de referință. În HTTP, anteturile de referință indică originea cererilor. Ele sunt de obicei folosite pentru a efectua analize, optimizare și înregistrare în jurnal.

De asemenea, puteți activa verificarea antetelor de referință pe partea serverului pentru a preveni atacurile CSRF. Partea server verifică originea sursă a cererii și determină originea țintă a cererii. Dacă se potrivesc, atunci cererea este permisă. Dacă există o nepotrivire, serverul renunță la cerere.

Utilizarea antetelor de referință este mult mai ușoară decât utilizarea token-urilor, deoarece nu necesită identificarea individuală a utilizatorului.

Vulnerabilități potențiale ale antetului referitor

La fel ca tokenurile CSRF, anteturile de referință au câteva vulnerabilități semnificative.

În primul rând, anteturile de referință nu sunt obligatorii, iar unele site-uri vor trimite solicitări fără ele. Dacă CSRF nu are politica de a gestiona cererile fără antete, atacatorii pot folosi cereri fără antet pentru a executa atacuri care schimbă starea.

În plus, această metodă a devenit mai puțin eficientă odată cu introducerea recentă a politicii de referință. Această specificație previne scurgerea URL-ului către alte domenii, oferind utilizatorilor mai mult control asupra informațiilor din antetul referitor. Aceștia pot alege să expună o parte din informațiile antetului de referință sau să o dezactiveze adăugând o etichetă de metadate pe pagina HTML, după cum se arată mai jos:

 <meta name="referrer" content="no-referrer">

Codul de mai sus elimină antetul referitor pentru toate solicitările din această pagină. Procedând astfel, este dificil pentru aplicațiile care se bazează pe antetele de referință să prevină atacurile CSRF de la o astfel de pagină.

Cum protejează Kinsta împotriva atacurilor CSRF

Pe lângă utilizarea antetului de referință și a jetoanelor CSRF, există o a treia opțiune și mult mai ușoară: alegerea unui serviciu de găzduire sigur, cum ar fi Kinsta, pentru site-urile și aplicațiile web, oferă o barieră mult mai puternică și mai sigură între atacatori și utilizatori.

Pe lângă caracteristicile critice de securitate, cum ar fi backup-urile automate, autentificarea cu doi factori și SFTP prin protocoale SSH, integrarea Kinsta Cloudflare oferă protecție la nivel de întreprindere cu protecție bazată pe IP și firewall.

Mai exact, Kinsta are în prezent aproximativ 60 de reguli de firewall personalizate pentru a ajuta la prevenirea atacurilor rău intenționate și pentru a face față vulnerabilităților grave neautentificate în pluginuri și teme, inclusiv unele specifice care caută vulnerabilități CSRF.

rezumat

Falsificarea cererilor între site-uri (CSRF) este un atac care păcălește utilizatorii autentificați să inițieze cereri de schimbare a stării în mod neintenționat. Acestea vizează aplicațiile care nu pot face diferența între cererile de schimbare a stării valide și falsificate.

CSRF poate avea succes numai în aplicațiile care se bazează pe cookie-uri de sesiune pentru a identifica utilizatorii înregistrați și au o politică de cookie-uri SameSite slabă. De asemenea, au nevoie de un server care acceptă cereri care nu conțin parametri necunoscuți, cum ar fi parolele. Hackerii pot trimite atacuri rău intenționate folosind fie GET, fie POST.

Deși utilizarea jetoanelor CSRF sau impunerea verificării antetului referitor poate preveni unele atacuri CSRF, ambele măsuri au potențiale vulnerabilități care pot face măsurile preventive inutile dacă nu ești atent.

Migrarea la o platformă de găzduire sigură precum Kinsta vă protejează site-urile web sau aplicațiile web de atacurile CSRF. În plus, integrarea Kinsta cu Cloudflare previne atacurile specifice CSRF.