Impact
Cross-Site Request Forgery (CSRF) permite unui atacator să păcălească browserul unei victime pentru a efectua acțiuni nedorite pe un alt site web pe care victima este în prezent autentificată. Deoarece browserele includ automat acreditări ambientale, cum ar fi cookie-urile în solicitări, un atacator poate falsifica operațiuni de schimbare a stării - cum ar fi schimbarea parolelor, ștergerea datelor sau inițierea tranzacțiilor - fără știrea utilizatorului.
Cauza fundamentală
Cauza fundamentală a CSRF este comportamentul implicit al browserului web de a trimite cookie-uri asociate unui domeniu ori de câte ori se face o solicitare către acel domeniu, indiferent de originea solicitării [S1]. Fără o validare specifică că o solicitare a fost declanșată intenționat din interfața de utilizator a aplicației, serverul nu poate face distincția între o acțiune legitimă a utilizatorului și una falsificată.
Mecanisme de protecție Django CSRF
Django oferă un sistem de apărare încorporat pentru a atenua aceste riscuri prin integrarea middleware și șablon [S2].
Activare Middleware
django.middleware.csrf.CsrfViewMiddleware este responsabil pentru protecția CSRF și este de obicei activat în mod implicit [S2]. Trebuie să fie poziționat înainte de orice middleware de vizualizare care presupune că atacurile CSRF au fost deja tratate [S2].
Implementarea șablonului
Pentru orice formulare POST interne, dezvoltatorii trebuie să includă eticheta {% csrf_token %} în interiorul elementului <form> [S2]. Acest lucru asigură că în cerere este inclus un token unic, secret, pe care serverul îl validează apoi în raport cu sesiunea utilizatorului.
Riscuri de scurgere a simbolurilor
Un detaliu critic al implementării este că {% csrf_token %} nu trebuie să fie niciodată inclus în formularele care vizează adrese URL externe [S2]. Procedând astfel, tokenul secret CSRF ar fi scurs către o terță parte, putând compromite securitatea sesiunii utilizatorului [S2].
Apărare la nivel de browser: cookie-uri SameSite
Browserele moderne au introdus atributul SameSite pentru antetul Set-Cookie pentru a oferi un strat de apărare în profunzime [S1].
- Strict: Modulul cookie este trimis doar într-un context primar, ceea ce înseamnă că site-ul din bara de adrese URL se potrivește cu domeniul cookie-ului [S1].
- Lax: Cookie-ul nu este trimis la subcereri între site-uri (cum ar fi imagini sau cadre), ci este trimis atunci când un utilizator navighează la site-ul de origine, cum ar fi urmărind un link standard [S1].
Cum testează FixVibe pentru aceasta
FixVibe include acum protecția CSRF ca o verificare activă. După verificarea domeniului, active.csrf-protection inspectează formularele descoperite care schimbă starea, verifică intrările în formă de token CSRF și semnalele cookie SameSite, apoi încearcă o trimitere cu un impact redus de origine falsificată și raportează numai atunci când serverul o acceptă. Verificările cookie-urilor semnalează, de asemenea, atributele SameSite slabe care reduc apărarea în profunzime CSRF.