Ce este un atac CSRF?
Vă puteți familiariza cu ideea atacului CSRF asupra resurselor clasice:
Extras din răspunsul la SO:
CSRF motiv constă în faptul că browserele nu înțeleg cum de a discerne dacă efectul este făcută în mod clar de către utilizator (cum ar fi, de exemplu, apăsarea unui buton de pe formular sau urmați un link), sau un utilizator efectua în mod neintenționat această acțiune (de exemplu, atunci când vizitați bad.com. Resource o cerere a fost trimisă la good.com/some_action., în timp ce utilizatorul a fost deja conectat la good.com).
Cum de a proteja de ea?
O metodă eficientă și general acceptată de protecție împotriva CSRF-atac este un simbol. Un token se referă la un set aleatoriu de octeți pe care serverul îl trimite clientului, iar clientul revine la server.
Protecția este redusă la verificarea jetonului generat de server și a jetonului trimis de utilizator.
Și ce, de fapt, pentru a proteja?
Dacă scrieți serviciul Web în conformitate cu RFC7231. apoi metode GET. HEAD. OPTIONS și TRACE sunt sigure: sunt doar pentru informare și nu ar trebui să modifice starea serverului.
Astfel, este necesar să se protejeze metodele nesigure, care includ: POST. PUT. DELETE. PATCH.
Cerințe pentru token:
- Simbol unic pentru fiecare operație # 13;
- Fapte o dată # 13;
- Are o dimensiune care este rezistentă la selecție # 13;
- Generată de un generator de numere pseudo-aleatoare stabile, criptografic # 13;
- Are o durată de viață limitată # 13;
La primul MeetUp'e PDUG Timur Yunusov (șeful departamentului de securitate bancară # 13; sisteme pozitive Technologies) a declarat pentru. de ce exact aceste cerințe sunt impuse CSRF-Token și ce amenință să le neglijeze.
Cerințe pentru serviciul Web și mediul:
Absența vulnerabilităților XSS
Prin urmare, vulnerabilitățile XSS pot fi folosite pentru a obține tokenul curent.
Nu există programe malware pe mașina client
Dacă un atacator poate rula software pe mașina client, atunci poate obține toate datele disponibile în browser.
Metode de protecție
Există 3 metode pentru utilizarea jetoanelor pentru protejarea serviciilor web de atacurile CSRF:
Sincronizatorul de sincronizări
O abordare simplă folosită peste tot. Necesită stocarea unui jeton pe partea serverului.
La începutul sesiunii, pe server se generează un jeton.
Jetonul este plasat în memoria de stocare a sesiunilor (adică stocată pe partea de server pentru verificarea ulterioară)
Ca răspuns la o solicitare (care a început sesiunea), un token este returnat clientului.
Dacă redarea are loc pe server. atunci tokenul poate fi returnat în HTML, ca de exemplu unul dintre câmpurile de formular sau în interiorul tag-ul.
În cazul în care răspunsul este returnat pentru aplicația JS. tokenul poate fi trecut în antet (adesea utilizând X-CSRF-Token)
Pentru solicitările ulterioare, clientul trebuie să transmită token-ul la server pentru verificare.
Când conținutul este redat de server, tokenul este în mod normal returnat în interiorul datelor formularului POST.
Aplicațiile JS trimit de obicei cereri XHR cu antet (X-CSRF-Token) care conține un jeton.
Atunci când o solicitare este primită printr-o metodă nesigură (POST.PUT.DELETE.PATCH), serverul trebuie să verifice identitatea tokenului din datele sesiunii și jetonul trimis de client.
Dacă ambele tokenuri se potrivesc, atunci cererea nu a fost supusă atacului CSRF, altfel - vom înregistra evenimentul și vom respinge cererea.
La ieșire avem:
Protecția față de CSRF la un nivel bun
Jetonul este actualizat numai atunci când sesiunea este reconstruită. iar acest lucru se întâmplă la expirarea sesiunii
În timpul unei singure sesiuni, toate acțiunile vor fi verificate împotriva unui singur simbol.
Dacă apare o scurgere de jeton, atacatorul va putea să efectueze un atac CSRF asupra oricărei solicitări și pentru o perioadă lungă de timp. Și nu este bine.
Suport gratuit pentru multi-tab în browser.
Tokenul nu este invalidat după ce interogarea este executată, ceea ce permite dezvoltatorului să nu-și facă griji cu privire la sincronizarea tokenului în diferite file ale browserului, deoarece tokenul este întotdeauna unul.
Trimiteți dublu Cookie
Această abordare nu necesită stocarea datelor de pe server, ceea ce înseamnă că este fără stat. Folosit dacă doriți să puteți scala rapid și calitativ serviciul Web orizontal. # 13; Ideea este de a da token clientului în două moduri: în cookie-uri și într-unul din parametrii de răspuns (antet sau în interiorul HTML).
Când este solicitat de la client, pe server se generează un jeton. Ca răspuns, jetonul este returnat cookie-ului (de exemplu, X-CSRF-Token) și într-unul din parametrii de răspuns (în header sau în interiorul HTML).
În cererile ulterioare, clientul trebuie să furnizeze ambele jetoane primite anterior. Unul este ca un cookie, celălalt este fie un antet. fie în interiorul datelor formularului POST.
Atunci când o solicitare este primită printr-o metodă nesigură (POST.PUT.DELETE.PATCH), serverul trebuie să verifice identitatea tokenului din cookie și tokenul pe care clientul la trimis în mod explicit.
Dacă ambele tokenuri se potrivesc, atunci cererea nu a fost supusă atacului CSRF, altfel - vom înregistra evenimentul și vom respinge cererea.
La ieșire avem:
Protecția CSRF fără statură.
Astfel, în cazul în care serviciul este accesibil la nivel de domeniu 3, iar atacatorul este capabil să înregistreze resursele pe nivelul domeniului 2, apoi instalați un cookie pe domeniul dvs. explicit.
# 13;Codul criptat
La fel ca Double Submit, este o abordare apatridă. Principalul lucru este că, dacă criptați orice date cu un algoritm fiabil și le transmiteți clientului, clientul nu le poate forța fără să știe cheia. Această abordare nu necesită utilizarea cookie-urilor. Jetonul este trimis clientului numai în parametrii de răspuns.
În această abordare, simbolul este faptele criptate cu cheia. Faptele minim necesare sunt ID-ul utilizatorului și marcajul de timp al timpului generării token-ului. Cheia nu ar trebui să fie cunoscută clientului.
Când este solicitat de la client, pe server se generează un jeton.
Generarea unui jeton constă în criptarea faptelor necesare pentru validarea tokenului în viitor.
Faptele minim necesare sunt ID-ul utilizatorului și marca de timp. Ca răspuns, jetonul este returnat într-unul din parametrii de răspuns (în antet sau în interiorul HTML).
În cererile ulterioare, clientul trebuie să furnizeze tokenul primit anterior.
Atunci când o solicitare este primită printr-o metodă nesigură (POST.PUT.DELETE.PATCH), serverul este obligat să valideze tokenul primit de la client.
Validarea tokenului este de a decripta și de a compara faptele obținute după decodificare cu cele reale. (O verificare a timbru este necesară pentru a limita durata de viață a tokenului)
Dacă decriptarea a eșuat sau faptele nu se potrivesc, se consideră că cererea a fost supusă atacului CSRF.
La ieșire avem:
Cu privire la punerea în aplicare
Să generăm un nou jeton pentru fiecare solicitare, indiferent de metoda HTTP și în ce scop este făcută această solicitare.
În acest fel, obținem un simbol, care se schimbă în mod constant.
Desigur, se pune problema organizării muncii multi-tab.
Sincronizarea token-urilor dintre file poate fi implementată folosind localStorage și StorageEvent
Limităm durata de viață a cookie-ului, care conține tokenul, la o valoare rezonabilă. De exemplu, 30 de minute.
Efectuați cookie-ul indisponibil din JS (setați HTTPOnly = true)
Utilizați TLS pentru a preveni MITM
În acest caz, trimitem cookie-urile numai prin HTTPS (set Secure = true)
Dimensiunea tokenului nu este mai mică de 32 octeți.
Generăm un jeton cu un generator de numere pseudo-aleatoare stabil, criptografic.
Pentru a face acest lucru, puteți utiliza funcțiile sistemului:
Ce altceva trebuie să știți?
Token-urile reprezintă o protecție obligatorie împotriva CSRF.
Verificați, dar nu vă bazați exclusiv pe X-Requested-With: XMLHttpRequest
Verificați, dar nu vă bazați numai pe anteturi: gazdă. Origine. referer
Nu treceți jetoanele în adresa URL
Acum lucrăm la specificarea atributului "Same-Site" în cookie-uri (cea mai recentă versiune la momentul redactării articolului).
Un astfel de atribut va permite dezvoltatorilor să indice în mod explicit faptul că cookie-ul nu trebuie trimis în cazul în care solicitarea provine de la un alt site decât cel pe care a fost instalat cookie-ul. Și, prin urmare, vom avea ocazia să protejăm resursele de CSRF fără a folosi instrumente suplimentare.
Chrome suportă deja această funcție.
Mai multe informații despre cum și de ce este disponibil pe Stack Exchange.
Articole similare
Trimiteți-le prietenilor: