Ce este falsificarea cererilor între site-uri (CSRF)?

Vulnerabilitățile de falsificare a cererilor între site-uri (CSRF sau XSRF) sunt rareori ridicate sau critice în evaluările lor de severitate. Totuși, ei încă pot face mult rău. Au fost a doua cea mai comună vulnerabilitate WordPress în ultimii ani, după vulnerabilitățile Cross-Site Scripting (XSS). Veți înțelege cum să vă protejați mai bine site-ul dacă știți ce este o vulnerabilitate CSRF și cum le exploatează de obicei atacatorii.

Ocolirea politicii privind aceeași origine

O vulnerabilitate CSRF face posibil ca un atacator să evite o caracteristică standard a browserului numită politică de aceeași origine. Toate browserele web urmează această regulă pentru a preveni tipul de interferență activat de CSRF. În mod normal, atunci când încărcați o pagină web, browserul dvs. interacționează doar cu un domeniu sau subdomeniu, în afară de orice excepții permise. Și va accepta conținut doar printr-un singur protocol, HTTP sau HTTPS (nu ambele), fără a vă avertiza că există o problemă. Dacă persoanele rău intenționate ocolesc politica de aceeași origine, vă pot păcăli și să faceți clic pe linkuri care efectuează acțiuni nedorite, interacționând în mod neașteptat cu un alt site.

Din punct de vedere vizual, veți avea puține sau deloc indicii că interacționați cu un alt site într-un mod nedorit. Clickjacking funcționează așa. Dacă site-ul tău WordPress a fost exploatat printr-o vulnerabilitate CSRF, tu și vizitatorii tăi ai putea fi supuși la phishing, clickjacking și mai rău.

În acest ghid, vom cerceta detaliile falsurilor de cereri pe mai multe site-uri. Vom analiza un exemplu specific de vulnerabilitate CSRF, astfel încât să înțelegeți cum funcționează. Apoi vă vom arăta ce puteți face pentru a preveni apariția vulnerabilităților CSRF pe site-ul dvs. Vă vom sugera, de asemenea, câteva modalități de a anula sau de a limita daunele pe care o exploatare CSRF de succes pe care o poate face prin întărirea site-ului dvs. împotriva acestor și altor tipuri de atacuri.

Hai să aruncăm o privire.

Cum influențează un atac de falsificare a cererilor între site-uri (CSRF) site-ul dvs. WordPress?

Când un atac CSRF are succes, victimele acestuia autorizează neintenționat o acțiune dăunătoare, cum ar fi o actualizare a acreditărilor lor de conectare. Ei ar putea fi păcăliți pentru a permite unui atacator să preia contul de utilizator. Mai rău, o victimă a unui exploit CSRF ar putea lăsa atacatorii să inițieze transferuri financiare în numele lor.

Dacă un plugin de pe site-ul dvs. WordPress conține o vulnerabilitate CSRF, un atacator ar putea fi capabil să deturneze unele conturi de utilizator. Acesta ar fi unul dintre cele mai rele scenarii. Dacă un cont furat are un rol administrativ în WordPress sau utilizatorul își reutiliza parola pe alte site-uri, daunele ar putea fi mari.

Cum funcționează un atac CSRF?

Trebuie să existe trei condiții diferite pentru ca un hacker să facă un atac CSRF să funcționeze. Dacă le înțelegeți la nivel general, veți avea o bună înțelegere a unor elemente fundamentale ale securității web.

1. Gestionarea sesiunilor pe bază de cookie-uri

Ca și alte aplicații fără stat, WordPress se bazează pe module cookie de sesiune pentru a identifica utilizatorii. În condiții de securitate scăzute sau compromise, un atacator ar putea fi capabil să creeze module cookie de sesiune false sau să manipuleze un utilizator conectat pentru a întreprinde acțiuni nedorite. WordPress va accepta cereri falsificate și manipulate care sunt sau par a fi de la un utilizator conectat.

În timp ce exploatările CSRF vizează adesea gestionarea sesiunilor bazată pe cookie-uri, aceasta nu este singura lor țintă. Atacurile CSRF pot fi eficiente împotriva oricărei aplicații care adaugă automat acreditările de utilizator la solicitări. Din acest motiv, autentificarea bazată pe certificat și autentificarea de bază HTTP sunt de asemenea susceptibile la vulnerabilități CSRF.

2. O acțiune relevantă poate fi vizată

Trebuie să existe anumite acțiuni în cadrul aplicației vizate pe care victimele pot fi păcălite să le ia. Aceasta ar putea fi o acțiune privilegiată, cum ar fi modificarea permisiunilor utilizatorului. Poate fi legat de date specifice utilizatorului, cum ar fi actualizarea parolei unui utilizator. Acestea sunt acțiuni comune în toate aplicațiile web, inclusiv WordPress. Ei au valoare ca ținte pentru hackeri, deoarece le-ar putea deschide o cale de a fura conturi de utilizator și de a căuta mai profund modalități de a se implica în furturi, fraude sau alte activități rău intenționate.

3. Fără parametri de solicitare imprevizibili

Solicitările care efectuează acțiunea vizată trebuie să fie cunoscute sau previzibile. Dacă cererile vizate nu trebuie să conțină parametri ale căror valori atacatorul nu le poate determina sau ghici, acestea sunt mai vulnerabile la manipulare.

De exemplu, dacă o cerere validă de schimbare a parolei trebuie să includă parola existentă, aceasta este sigură – atâta timp cât un atacator nu cunoaște parola. Tokenurile CSRF și cookie-urile SameSite adaugă obstacole suplimentare atacatorilor atunci când dezvoltatorii le folosesc pentru a-și securiza codul. Dar uneori dezvoltatorii nu implementează aceste metode de securitate corect sau deloc. (De aceea este valoroasă autentificarea utilizatorului puternică, fără parolă.)

Exploatarea unei vulnerabilități CSRF de a schimba e-mailurile contului de utilizator — Un exemplu

Iată un exemplu mai aprofundat. De fapt, nu va funcționa, dar ilustrează principalele concepte în joc pentru un exploit CSRF eficient.

Luați în considerare o solicitare de modificare a e-mailului. Când un utilizator efectuează această acțiune, el face o solicitare HTTP care arată cam așa pentru serverul web care o primește:

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

De ce funcționează

Aceasta îndeplinește condițiile cerute pentru CSRF dacă/pentru că:

• Site-ul/aplicația vizată utilizează un cookie de sesiune pentru a identifica utilizatorul care a emis cererea și nu există alte simboluri sau mecanisme pentru a urmări sesiunile utilizatorilor. Acesta este motivul pentru care dezvoltatorii ar trebui să utilizeze jetoane CSRF și/sau cookie-uri SameSite.
• Schimbarea adresei de e-mail a unui utilizator este o acțiune relevantă în interesul unui atacator. Cu siguranță e! Dacă puteți schimba adresa de e-mail a unui utilizator cu una pe care o controlați, puteți prelua controlul complet asupra contului acestuia.
• Atacatorul cunoaște parametrii de solicitare de care au nevoie pentru a schimba adresa de e-mail a unui utilizator și poate genera valori valide pentru el. Acești parametri nu sunt secreti și nu este dificil să se determine ce adrese de e-mail folosesc multe persoane pentru conturile lor online. Modulul cookie de sesiune este mai complicat.

Cum ar putea un atacator să fure cookie-uri de sesiune

Principalul obstacol al atacatorului este determinarea valorilor reale pentru parametrii care vor accesa contul unui anumit utilizator. Ei ar putea face asta prin construirea unei pagini web destinate utilizatorilor site-ului vizat. Acest site înșelător ar putea avea link-uri sau butoane care par a avea un scop legitim, cum ar fi solicitarea de cadouri gratuite. În realitate, dacă faceți clic pe acele linkuri sau butoane, singura persoană care primește niște bunătăți dulci gratis este atacatorul.

Când faceți clic pe aceste linkuri frauduloase, acestea vor face o cerere de schimbare a adresei site-ului vizat și vulnerabil CSRF. Dacă sunteți autentificat pe acel site, cererea va fi valabilă. Contul dvs. a fost furat - v-ați predat cheile.

Utilizatorii unui site WordPress care rămân conectați la acesta au un cookie de sesiune activ în browser care persistă chiar și atunci când se află pe un alt site. Browserul lor va include automat acel cookie de sesiune într-o solicitare falsificată. WordPress poate vedea aceasta ca o solicitare de schimbare a adresei perfect validă - chiar dacă vine de pe alt site și utilizatorul nu are idee că o face.

Presupunând că nu există alte măsuri de securitate, cum ar fi atributul cookie SameSite, site-ul țintă vulnerabil va procesa o solicitare falsificată la fel ca una validă. Dacă site-ul web vizat nu impune un pas de confirmare a schimbării adresei sau dacă atacatorul are o modalitate de a o ocoli, atacatorul va schimba cu succes adresa utilizatorului cu orice o alege atacatorul.

Cum este livrat un atac CSRF către un site web vulnerabil

Mecanismele de livrare pentru atacurile CSRF și pentru atacurile Reflected Cross-Site Scripting (Reflected XSS) sunt similare.

În cele mai multe cazuri, atacatorii își vor plasa codul rău intenționat pe un site înșelător pe care îl controlează. Acesta ar putea fi un site legitim pe care l-au compromis deja, motiv pentru care Google menține o listă de site-uri înșelătoare. Toate browserele își vor avertiza utilizatorii dacă vă aflați pe această listă! Acesta este motivul pentru care iThemes Security verifică în fiecare zi pentru a vă asigura că site-ul dvs. nu a devenit un instrument pentru hacker.

A determina potențialele victime să viziteze un site web înșelător este pur și simplu o chestiune de bază de social media și marketing prin e-mail. Uneori, codul rău intenționat este pur și simplu plasat pe un site popular într-o zonă activă.

Un atacator poate să nu aibă nevoie nici măcar de un site web pentru a-și atrage victimele. Unele exploit-uri simple CSRF folosesc metoda GET. Acesta este ceea ce face browserul dvs. când faceți clic pe un link sau introduceți o adresă URL în bara de adrese. Face o solicitare GET folosind adresa URL din link sau pe care o furnizați. Uneori, un atac CSRF poate fi executat complet cu o singură solicitare GET către un site web vulnerabil. În astfel de situații, atacatorul ar putea să nu fie nevoie să folosească un site web înșelător. Ei pot pur și simplu să hrănească victimelor lor direct o adresă URL rău intenționată.

Protejarea site-ului dvs. de atacurile de falsificare a cererilor între site-uri (CSRF).

Vulnerabilitățile CSRF apar frecvent în pluginuri și uneori în teme. Când hackerii îi vizează, nu este greu să te protejezi. Folosiți pluginuri și teme de calitate în care aveți încredere, eliminați-le pe cele pe care nu le utilizați și mențineți tot software-ul actualizat . De asemenea, ar trebui să implementați o politică de securitate a utilizatorului bine gândită și să vă gândiți să treceți fără parolă. Dacă o vulnerabilitate CSRF (sau orice alta) este exploatată pe site-ul dvs. pentru a obține acces la conturile de utilizator, nu va face prea mult bine atacatorului dacă utilizați chei de acces. Nimeni nu poate fura ceea ce nu există.

Pe lângă gestionarea actualizărilor și avertizarea cu privire la pluginurile și temele vulnerabile, iThemes Security Pro facilitează configurarea și gestionarea regulilor de securitate bazate pe rol și utilizatori. Delegați privilegii pe baza principiului celui mai mic privilegiu. Asigurați-vă autentificarea, recuperarea parolei și formularele de contact cu CAPTCHA. Nu oferiți utilizatorilor dvs. capacități mai mari decât au nevoie. Solicitați utilizatorilor cu privilegii mai mari să utilizeze metode de autentificare mai puternice. Și adoptă cu siguranță cea mai convenabilă și simplă modalitate de a te conecta la WordPress fără parolă: cheile de acces!

Cel mai bun plugin de securitate WordPress pentru a securiza și proteja WordPress

WordPress alimentează în prezent peste 40% din toate site-urile web, așa că a devenit o țintă ușoară pentru hackerii cu intenții rău intenționate. Pluginul iThemes Security Pro elimină presupunerile din securitatea WordPress pentru a facilita securizarea și protejarea site-ului dvs. WordPress. Este ca și cum ai avea în personal un expert în securitate cu normă întreagă care monitorizează și protejează constant site-ul tău WordPress pentru tine.

Obțineți iThemes Security Pro

Dan Knauss

Dan Knauss este generalist de conținut tehnic al StellarWP. El a fost scriitor, profesor și freelancer care lucrează în sursă deschisă de la sfârșitul anilor 1990 și cu WordPress din 2004.