În ultimul articol am încercat să descriu exact ce este această vulnerabilitate și, indiferent cât de important este, îndeplinirea condițiilor necesare pentru efectuarea unui atac precum CSRF.
În acest articol voi încerca să vorbesc despre protecția împotriva atacurilor de acest tip de la părți:
- Din partea clientului - principalele modalități de a vă proteja
- Din partea serverului - proiectarea corectă a aplicației
Dacă sunteți interesat de modul în care vă protejați de CSRF atunci sunteți bineveniți la pisică.
Informații generale
În general, vreau să reamintesc, CSRF - nu este vulnerabil, acest tip de atac. Și acest atac se realizează pe aplicația web utilizatorului final folosind vulnerabilitatea în această aplicație, care poate fi numit ca „lipsa de due diligence cu privire la sursa de anchetă“ (numele meu, nu judeca strict, dar este adevărat). Dar, în continuare mă voi referi la vulnerabilități CSRF și atacuri într-un fel este mai ușor, și asta e ceea ce a făcut =)
Și odată ce atacul este efectuat asupra utilizatorului, iar utilizatorul să fie protejat ... glumă =) Ideea este că orice utilizator poate reduce posibilitatea de a efectua acest atac pe orice site, pe care le folosește (chiar dacă aceste site-uri nu au construit în protecția împotriva CSRF). Dar, în plus față de utilizatori, dezvoltatorii de site-uri pot proiecta cererea, astfel încât această posibilitate nedopustit acestui atac asupra utilizatorilor săi.
Luați în considerare protecția de ambele părți.
Protecție de către utilizator
În general, totul este foarte ciudat:
Asta e tot. Acum hai să trecem la chestia principală.
Protecția de la dezvoltatori
După cum sa menționat deja, vulnerabilitatea constă în lipsa unei verificări corespunzătoare a sursei cererii. Adică atunci când dezvoltăm o aplicație, trebuie să integrăm funcționalitatea de verificare a acestei surse. Și chtozhe primul lucru vine în minte? Așa este! Verificarea Refererului.
Verificați Referer
O dată voi spune, pentru cei care citesc articole pe o diagonală. Pentru a-ți baza apărarea numai la verificarea acestui antet este rău (!). De ce - vezi mai jos.
În primul rând, ne vom da seama ce este această metodă.
Dar călăria. Iar punctul de aici nu este acela că puteți crea un referrer (care craniu sănătos va cere victimei să înlocuiască referitorul și să facă clic pe link). Și în acest fel, conform statisticilor mele, aproximativ 5% dintre utilizatorii Refererului sunt dezactivați. Adică, aceste cinci procente nu vor putea să lucreze cu site-ul deloc sau vor fi vulnerabile la acest atac (depinde de politica aplicației).
Voobshchem ca mod independent această metodă nu are sens.
Confirmați acțiunea
Ei bine, acum singura modalitate corectă și fiabilă.
Semnificația acestei metode este de a adăuga un parametru care conține câteva "jetoane" pentru fiecare legătură, o formă de trimitere și așa mai departe. Iar când cererea este primită, serverul ar trebui să verifice disponibilitatea acestui token în parametrii primiți. Firește, fiecare jeton pentru fiecare utilizator trebuie să fie unic sau chiar mai bun dacă fiecare jeton este unic.
Unul dintre exemplele de implementare cele mai simple și cele mai fiabile este că tokenul este generat cu fiecare cerere și este setat în cookie-urile utilizatorilor și este adăugat de asemenea la parametrii formularului și legăturilor de pe pagină:
Apoi, atunci când fiecare cerere este primită, se compară jetonul din cookie și jetonul specificat în parametrii formularului. Și dacă sunt aceleași, sursa cererii este legală. Apoi, tokenul este generat din nou, și din nou instalat în cookie, și așa mai departe. într-un cerc.
În general, punerea în aplicare pot fi diferite, dar problema este că trecerea la token-uri este destul de dificil, deoarece trebuie să ia în considerare orice referință, orice formă, fiecare pagină ... Puteți proteja numai pagini importante / forme / de referință, dar există o șansă de a avea unele dor de ei.
Personal protejez doar formularele POST și legăturile foarte importante. Adică, POST în aplicațiile mele nu funcționează fără a avea jetonul corect. Acest lucru te salvează de șansa de a uita să protejezi o formă, pentru că pur și simplu nu va funcționa și o voi observa imediat.
Sper că din acest articol înțelegeți cum să apărați împotriva atacurilor CSRF.
PS: Pentru a continua :)
Vezi de asemenea
- Vulnerabilitatea față de CSRF. Ascunde Referer când redirecționează
Implementarea practică a exemplului de dezactivare a transferului referrer într-o redirecționare. Redirecționare fără referință. Descrierea atacului Csrf când referitorul este dezactivat.
Alo Astăzi voi adăuga o serie de articole despre CSRF. Dar acum voi merge fără probleme la "partea baricadei". După cum se spune.
Descrierea generală a tipului de atac CSRF. Un exemplu simplu de exploatare practică a vulnerabilității cererilor falsificate de site-uri. O ilustrare vizuală a vulnerabilității CSRF.
Da, îmi amintesc că am promis în mesajul precedent să scriu despre captcha, dar, sincer vorbind, scrie despre aceste captcha.
Descrierea vulnerabilității critice în NetCat CMS. Executarea codului. NetCat search_query Executarea codului.
Literalmente astăzi unul dintre clienții mei mi-a scris că site-ul lui a fost hacked. Vorbind sincer, am fost foarte surprins. Atât de puternică.
Exemplu de protecție de la PHP include. O modalitate de a preveni detectarea și conducerea unui atac de către un cracar.
Să gândim cu voi cine este un hacker? Un hacker nu este un hoț! Oamenii confundă adesea aceste concepte. Un hacker este acesta.
Să încercăm să discutăm cu dvs. despre acest subiect. Să presupunem că știu cum funcționează captcha (rețineți că am aproape o secțiune în blogul meu, este amânată).
Punerea în aplicare a CAPTCHA pot fi diferite, și, probabil, mai corect să spunem că cele mai multe dintre implementarile sale să fie încă în măsură să protejeze împotriva CSRF (cu unele excepții). Ei bine, din nou, dacă te uiți următoarea propoziție care vine sub titlul de „indicativele“: Deci, acum singurul mod corect și în condiții de siguranță .. cred că această propunere ar trebui să atingă pe ideea că toate aceeași idee cu captcha nu este destul de rezonabil) - în contextul articolului, acesta este doar un exemplu de gândire laterală.
Să spun că unele implementări ale CAPTCHA nu pot fi protejate de CSRF ... Îmi pare rău. Aceasta este eroarea programatorului care a implementat captcha-ul scurs. Și cu siguranță nu problema celor din urmă. Cu același succes, puteți vorbi despre jetoane, spun că acestea sunt inutile "dacă cunoașteți mecanismul muncii de jetoane și gândiți-vă puțin".
un token este generat la fiecare cerere și este setat în cookie-urile utilizatorului
Și dacă cookie-ul utilizatorului este dezactivat? Astfel, probabil,> 5% ..
Sesiuni fără utilizarea cookie-urilor? Dacă vorbești despre mecanismul standard al sesiunilor php, atunci ID-ul acestei sesiuni este stocat și în cookie. Nu există cookie-uri - fără sesiuni.
Eh ... ajută-mă cu un fragment al interogării etext = decrypt, care rămâne în REFERER după ce utilizatorul vine de la căutare Yandex.
Sunteți foarte disponibil pentru a prezenta materialul, vă mulțumesc
Unul dintre exemplele de implementare cele mai simple și cele mai fiabile este că tokenul este generat cu fiecare cerere și este setat în cookie-urile utilizatorilor și este adăugat de asemenea la parametrii formularului și legăturilor de pe pagină:
Bine, trebuie doar să protejezi tokenul, dar de ce de fiecare dată să generezi un nou jeton și să îl pui în cookie?
Doar nu înțeleg de ce în magazin pentru a stoca lucruri care nu sunt necesare?
Păstrarea tokenului în cookie nu este un lucru fundamental. Este mai ușor decât stocarea în baza de date. Fiți atenți pe care l-am scris:
Una dintre cele mai simple și mai fiabile ...
Puteți să-l stocați în baza de date. În principiu, nu vă pasă cu adevărat ... Nu îl puteți stoca în altă parte și nu puteți genera pe baza datelor unice ale utilizatorilor și a unui fel de sare de server secret.
Există o mulțime de opțiuni, articolul spune doar unul dintre ei :)
Bună ziua. Spuneți-mi cum sunt scripturile scrise în codul paginii protejate de csrf? De ce utilizatorul răuvoitor nu poate să spargă tokenul însuși și să îl transmită într-o solicitare de postare?
Parsim una dintre paginile de pe site trage token și pasul următor este de a trimite comanda necesară deja cu token.
Ce este protecția?
Și atunci mă gândesc de ce unele servicii cere uneori o parolă atunci când efectuează operațiuni importante, asta e protecția.
Se pare că ai citit inactivă despre atacul în sine. Atacatorul nu are capacitatea de a distruge un jeton. Tokenul pentru fiecare utilizator este unic.
Reintroducerea parolei este o protecție împotriva altor probleme.
Sunt un obișnuit web-ra-bot-chik. Pi-shu aici, care mi-în cele-res, dar cu ceea ce am den te-nuzh a devenit-ki-TVA-Xia în sfera re-WEB, sa-Cape dacă rasa-suzh de-TION , Îmi pot schimba propriile articole.
Nu uitați să vă abonați:
Și foarte pro-shu, nu pentru-ar-wai-care lasă kom-men-tari la pro-chi-tan-ny-for-pi-syam.
Articole similare
Trimiteți-le prietenilor: