OWASP sau Open Web Security Project este o organizație caritabilă non-profit axată pe îmbunătățirea securității software-ului și aplicațiilor web.
Organizația publică o listă cu cele mai importante vulnerabilități de securitate web pe baza datelor de la diferite organizații de securitate.
Vulnerabilitățile de securitate web sunt prioritare în funcție de exploatabilitate, detectabilitate și impact asupra software-ului.
- Exploatabilitate -
De ce este nevoie pentru a exploata vulnerabilitatea de securitate? Cea mai mare exploatabilitate atunci când atacul are nevoie doar de browser web și cea mai mică este programarea și instrumentele avansate.
- Detectabilitate -
Cât de ușor este de detectat amenințarea? Cea mai mare este informația afișată pe adresa URL, formularul sau mesajul de eroare și cea mai mică fiind codul sursă.
- Impact sau daune -
Cât de mult se va face dacă vulnerabilitatea de securitate este expusă sau atacată? Cea mai mare fiind completă a sistemului și cea mai mică fiind nimic deloc.
Scopul principal al OWASP Top 10 este de a educa dezvoltatorii, proiectanții, managerii, arhitecții și organizațiile despre cele mai importante vulnerabilități de securitate.
Cele mai importante 10 vulnerabilități de securitate conform OWASP Top 10 sunt:
- Injecție SQL
- Cross Site Scripting
- Autentificare defectă și gestionarea sesiunii
- Referințe nesigure ale obiectelor directe
- Solicitare de falsificare a site-urilor încrucișate
- Configurare greșită a securității
- Stocare criptografică nesigură
- Eșecul restricționării accesului URL
- Protecție insuficientă a stratului de transport
- Redirecționări și redirecționări nevalidate
Injecție SQL
Descriere
Injecția este o vulnerabilitate de securitate care permite unui atacator să modifice instrucțiunile SQL backend manipulând datele furnizate de utilizator.
Injecția are loc atunci când intrarea utilizatorului este trimisă unui interpret ca parte a comenzii sau a interogării și îl păcălește pe interpret să execute comenzi neintenționate și oferă acces la date neautorizate.
Comanda SQL care, atunci când este executată de aplicația web, poate expune și baza de date back-end.
Implicare
- Un atacator poate injecta conținut rău intenționat în câmpurile vulnerabile.
- Datele sensibile precum numele utilizatorilor, parolele etc. pot fi citite din baza de date.
- Datele bazei de date pot fi modificate (Insert / Update / Delete).
- Operațiunile de administrare pot fi executate pe baza de date
Obiecte vulnerabile
- Câmpuri de intrare
- Adrese URL care interacționează cu baza de date.
Exemple:
- Injecție SQL pe pagina de autentificare
Conectarea la o aplicație fără a avea acreditări valide.
Numele de utilizator valid este disponibil, iar parola nu este disponibilă.
Adresa URL a testului: http://demo.testfire.net/default.aspx
Nume utilizator: sjones
Parolă: 1 = 1 'sau pass123
Interogare SQL creată și trimisă la interpret ca mai jos
SELECTAȚI * DE LA UTILIZATORII UNDE User_Name = sjones ȘI Parola = 1 = 1 'sau pass123;
Recomandări
- Listă albă a câmpurilor de intrare
- Evitați afișarea mesajelor de eroare detaliate, care sunt utile unui atacator.
Cross Site Scripting
Descriere
Cross Site Scripting este, de asemenea, cunoscut în scurt timp sub numele de XSS.
Vulnerabilitățile XSS vizează scripturile încorporate într-o pagină care sunt executate pe partea client, adică pe browserul utilizatorului, mai degrabă decât pe partea serverului. Aceste defecte pot apărea atunci când aplicația preia date de încredere și le trimite către browserul web fără validarea corespunzătoare.
Atacatorii pot folosi XSS pentru a executa scripturi rău intenționate asupra utilizatorilor, în acest caz browsere victime. Deoarece browserul nu poate ști dacă scriptul este sau nu de încredere, scriptul va fi executat, iar atacatorul poate să deturneze cookie-urile de sesiune, să elimine site-urile web sau să redirecționeze utilizatorul către un site web nedorit și rău intenționat.
XSS este un atac care permite atacatorului să execute scripturile de pe browserul victimei.
Implicare:
- Folosind această vulnerabilitate de securitate, un atacator poate injecta scripturi în aplicație, poate fura cookie-uri de sesiune, șterge site-uri web și poate rula malware pe mașinile victimei.
Obiecte vulnerabile
- Câmpuri de intrare
- URL-uri
Exemple
1. http://www.vulnerablesite.com/home?" < script > alert (" xss" ) script >
Scriptul de mai sus, atunci când este rulat pe un browser, va fi afișată o casetă de mesaj dacă site-ul este vulnerabil la XSS.
Atacul mai grav poate fi făcut dacă atacatorul dorește să afișeze sau să stocheze cookie-ul de sesiune.
2. http://demo.testfire.net/search.aspx?txtSearch
Scriptul de mai sus, când este rulat, browserul va încărca un cadru invizibil care indică spre http://google.com .
Atacul se poate agrava prin rularea unui script rău intenționat pe browser.
Recomandări
- Câmpuri de introducere Listă albă
- Codare ieșire intrare
Autentificare defectă și gestionarea sesiunii
Descriere
Site-urile web creează de obicei un cookie de sesiune și un ID de sesiune pentru fiecare sesiune validă, iar aceste cookie-uri conțin date sensibile cum ar fi numele de utilizator, parola etc. Când sesiunea este încheiată fie prin deconectare, fie prin închiderea bruscă a browserului, aceste cookie-uri ar trebui invalidate, adică pentru fiecare sesiune ar trebui să existe un cookie nou.
Dacă cookie-urile nu sunt invalidate, datele sensibile vor exista în sistem. De exemplu, un utilizator care folosește un computer public (Cyber Cafe), cookie-urile site-ului vulnerabil se află pe sistem și sunt expuse unui atacator. Un atacator folosește același computer public după ceva timp, datele sensibile fiind compromise.
În același mod, un utilizator care folosește un computer public, în loc să se deconecteze, închide brusc browserul. Un atacator folosește același sistem, când navighează pe același site vulnerabil, se va deschide sesiunea anterioară a victimei. Atacatorul poate face orice dorește să fure informații de profil, informații despre cardul de credit etc.
Ar trebui făcută o verificare pentru a găsi puterea autentificării și gestionării sesiunii. Cheile, jetoanele de sesiune, cookie-urile trebuie implementate corect, fără a compromite parolele.
Obiecte vulnerabile
- ID-urile de sesiune expuse pe URL pot duce la atacuri de fixare a sesiunii.
- ID-uri de sesiune la fel înainte și după deconectare și autentificare.
- Expirările sesiunii nu sunt implementate corect.
- Aplicația atribuie același ID de sesiune pentru fiecare nouă sesiune.
- Părțile autentificate ale aplicației sunt protejate folosind SSL, iar parolele sunt stocate în format hash sau criptat.
- Sesiunea poate fi refolosită de un utilizator cu privilegii reduse.
Implicare
- Folosind această vulnerabilitate, un atacator poate deturna o sesiune, obține acces neautorizat la sistem, ceea ce permite divulgarea și modificarea informațiilor neautorizate.
- Sesiunile pot fi ridicate cu ajutorul cookie-urilor furate sau sesiuni folosind XSS.
Exemple
- Aplicația de rezervare a companiei aeriene acceptă rescrierea adreselor URL, introducând ID-urile sesiunii în adresa URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Vânzare de bilete în Maldive)
Un utilizator autentificat al site-ului dorește să-și anunțe prietenii despre vânzare și trimite un e-mail. Prietenii primesc ID-ul sesiunii și pot fi folosiți pentru a face modificări neautorizate sau pentru a utiliza în mod greșit detaliile cardului de credit salvat.
- O aplicație este vulnerabilă la XSS, prin care un atacator poate accesa ID-ul sesiunii și poate fi folosit pentru deturnarea sesiunii.
- Expirările aplicațiilor nu sunt setate corect. Utilizatorul folosește un computer public și închide browserul în loc să se deconecteze și se îndepărtează. Atacatorul folosește același browser ceva timp mai târziu, iar sesiunea este autentificată.
Recomandări
- Toate cerințele de autentificare și de gestionare a sesiunii ar trebui definite conform standardului de verificare a securității aplicației OWASP.
- Nu expuneți niciodată acreditări în URL-uri sau jurnale.
- Ar trebui depuse eforturi puternice pentru a evita defectele XSS care pot fi folosite pentru a fura ID-urile de sesiune.
Referințe nesigure ale obiectelor directe
Descriere
Apare atunci când un dezvoltator expune o referință la un obiect de implementare intern, cum ar fi un fișier, un director sau o cheie de bază de date ca în URL sau ca parametru FORM. Atacatorul poate folosi aceste informații pentru a accesa alte obiecte și poate crea un atac viitor pentru a accesa datele neautorizate.
Implicare
- Folosind această vulnerabilitate, un atacator poate avea acces la obiecte interne neautorizate, poate modifica datele sau compromite aplicația.
Obiecte vulnerabile
- În adresa URL.
Exemple:
Schimbarea „userid” în următoarea adresă URL poate face ca un atacator să vadă informațiile altor utilizatori.
http://www.vulnerablesite.com/userid=123 Modificat la http://www.vulnerablesite.com/userid=124
Un atacator poate vizualiza alte informații schimbând valoarea de identificare a utilizatorului.
Recomandări:
- Implementați controale de control al accesului.
- Evitați expunerea referințelor obiectelor în adresele URL.
- Verificați autorizarea tuturor obiectelor de referință.
Solicitare de falsificare a site-urilor încrucișate
Descriere
Cross Site Request Forgery este o cerere falsificată provenită de la site-ul încrucișat.
Atacul CSRF este un atac care apare atunci când un site web, e-mail sau program rău intenționat determină browserul unui utilizator să efectueze o acțiune nedorită pe un site de încredere pentru care utilizatorul este autentificat în prezent.
Un atac CSRF forțează browserul unei victime conectate să trimită o cerere HTTP falsificată, inclusiv cookie-ul de sesiune al victimei și orice alte informații de autentificare incluse automat, către o aplicație web vulnerabilă.
Un atacator va fi trimis de către atacator victimei atunci când utilizatorul face clic pe adresa URL când este conectat la site-ul original, datele vor fi furate de pe site.
Implicare
- Utilizarea acestei vulnerabilități ca atacator poate schimba informațiile profilului utilizatorului, poate schimba starea, poate crea un utilizator nou în numele administratorului etc.
Obiecte vulnerabile
- Pagina profilului utilizatorului
- Formulare de cont de utilizator
- Pagina tranzacțiilor comerciale
Exemple
Victima este conectată la un site web al băncii folosind acreditări valide. El primește e-mail de la un atacator spunând „Vă rugăm să faceți clic aici pentru a dona 1 $ pentru a provoca”.
Atunci când victima face clic pe acesta, va fi creată o solicitare validă pentru a dona 1 USD unui anumit cont.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Atacatorul captează această solicitare și creează cererea de mai jos și încorporează într-un buton care spune „Susțin cauza”.
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Întrucât sesiunea este autentificată și solicitarea vine prin intermediul site-ului web al băncii, serverul ar transfera atacatorului 1000 de dolari.
Recomandare
- Mandați prezența utilizatorului în timp ce efectuați acțiuni sensibile.
- Implementați mecanisme precum CAPTCHA, re-autentificare și jetoane de solicitare unice.
Configurare greșită a securității
Descriere
Configurarea securității trebuie definită și implementată pentru aplicație, cadre, server de aplicații, server web, server de baze de date și platformă. Dacă acestea sunt configurate corect, un atacator poate avea acces neautorizat la date sau funcționalități sensibile.
Uneori, astfel de defecte duc la un compromis complet al sistemului. Păstrarea software-ului la zi este, de asemenea, o bună securitate.
Implicare
- Folosind această vulnerabilitate, atacatorul poate enumera tehnologia subiacentă și informații despre versiunea serverului de aplicații, informații despre baze de date și poate obține informații despre aplicație pentru a mai lansa câteva atacuri.
Obiecte vulnerabile
- URL
- Câmpuri formular
- Câmpuri de introducere
Exemple
- Consola de administrare a serverului de aplicații este instalată automat și nu este eliminată. Conturile implicite nu sunt modificate. Atacatorul se poate conecta cu parole implicite și poate obține acces neautorizat.
- Listarea directorului nu este dezactivată pe serverul dvs. Atacatorul descoperă și poate pur și simplu să listeze directoare pentru a găsi orice fișier.
Recomandări
- O arhitectură puternică a aplicațiilor care asigură o bună separare și securitate între componente.
- Schimbați numele de utilizator și parolele implicite.
- Dezactivați listele de directoare și implementați verificări de control al accesului.
Stocare criptografică nesigură
Descriere
Stocarea criptografică nesigură este o vulnerabilitate comună care există atunci când datele sensibile nu sunt stocate în siguranță.
Acreditările utilizatorului, informațiile profilului, detaliile de sănătate, informațiile cardului de credit etc. aparțin informațiilor sensibile ale datelor de pe un site web.
Aceste date vor fi stocate în baza de date a aplicației. Atunci când aceste date sunt stocate în mod necorespunzător prin utilizarea criptării sau hash *, acestea vor fi vulnerabile la atacatori.
(* Hashing este transformarea caracterelor șirului în șiruri mai scurte de lungime fixă sau cheie. Pentru a decripta șirul, algoritmul folosit pentru a forma cheia ar trebui să fie disponibil)
Implicare
- Utilizând această vulnerabilitate, un atacator poate fura, modifica astfel de date slab protejate pentru a efectua furt de identitate, fraudă pe cardul de credit sau alte infracțiuni.
Obiecte vulnerabile
- Baza de date a aplicațiilor.
Exemple
Într-una dintre aplicațiile bancare, baza de date cu parole utilizează hash-uri nesărate * pentru a stoca parolele tuturor. O eroare de injecție SQL permite atacatorului să recupereze fișierul de parolă. Toate hashurile nesărate pot fi forțate brute în cel mai scurt timp, în timp ce parolele sărate ar dura mii de ani.
(* Hashs nesărate - Sarea este o informație aleatorie adăugată la datele originale. Sarea este atașată la parolă înainte de hashing)
Recomandări
- Asigurați-vă algoritmi standard puternici. Nu creați algoritmi criptografici proprii. Folosiți numai algoritmi publici aprobați, cum ar fi AES, criptografie cu cheie publică RSA și SHA-256 etc.
- Asigurați-vă că backup-urile offsite sunt criptate, dar cheile sunt gestionate și realizate separat.
Eșecul restricționării accesului URL
Descriere
Aplicațiile web verifică drepturile de acces URL înainte de a reda linkuri și butoane protejate. Aplicațiile trebuie să efectueze verificări similare de control al accesului de fiecare dată când aceste pagini sunt accesate.
În majoritatea aplicațiilor, paginile, locațiile și resursele privilegiate nu sunt prezentate utilizatorilor privilegiați.
După o presupunere inteligentă, un atacator poate accesa paginile cu privilegii. Un atacator poate accesa pagini sensibile, invoca funcții și vizualiza informații confidențiale.
Implicare
- Folosirea acestui atacator de vulnerabilitate poate avea acces la adresele URL neautorizate, fără să se conecteze la aplicație și să exploateze vulnerabilitatea. Un atacator poate accesa pagini sensibile, invoca funcții și vizualiza informații confidențiale.
Obiecte vulnerabile:
- URL-uri
Exemple
- Atacatorul observă că adresa URL indică rolul ca „/ user / getaccounts”. El se modifică ca „/ admin / getaccounts”.
- Un atacator poate adăuga rolul la adresa URL.
http://www.vulnerablsite.com poate fi modificat ca http://www.vulnerablesite.com/admin
Recomandări
- Implementați controale puternice de control al accesului.
- Politicile de autentificare și autorizare ar trebui să fie bazate pe roluri.
- Limitați accesul la adresele URL nedorite.
Protecție insuficientă a stratului de transport
Descriere
Se ocupă de schimbul de informații între utilizator (client) și server (aplicație). Aplicațiile transmit frecvent informații sensibile precum detalii de autentificare, informații despre cardul de credit și jetoane de sesiune pe o rețea.
Folosind algoritmi slabi sau folosind certificate expirate sau invalide sau nu folosind SSL poate permite comunicarea să fie expusă utilizatorilor care nu au încredere, ceea ce poate compromite o aplicație web sau poate fura informații sensibile.
Implicare
- Folosind această vulnerabilitate de securitate web, un atacator poate adulmina acreditările legitime ale utilizatorului și obține acces la aplicație.
- Poate fura informații despre cardul de credit.
Obiecte vulnerabile
- Date trimise prin rețea.
Recomandări
- Activați HTTP securizat și aplicați transferul de acreditări numai prin HTTPS.
- Asigurați-vă că certificatul dvs. este valid și nu a expirat.
Exemple:
1. O aplicație care nu folosește SSL, un atacator va monitoriza pur și simplu traficul din rețea și va observa un cookie autentificat de sesiune a victimei. Un atacator poate fura acel cookie și poate efectua un atac Man-in-the-Middle.
Redirecționări și redirecționări nevalidate
Descriere
Aplicația web folosește câteva metode pentru a redirecționa și redirecționa utilizatorii către alte pagini în scopul dorit.
Dacă nu există o validare adecvată în timp ce redirecționează către alte pagini, atacatorii pot folosi acest lucru și pot redirecționa victimele către site-uri de phishing sau malware sau pot folosi redirecționări pentru a accesa pagini neautorizate.
Implicare
- Un atacator poate trimite o adresă URL utilizatorului care conține o adresă URL autentică atașată cu o adresă URL codificată rău intenționată. Un utilizator, doar văzând partea autentică a URL-ului trimis de atacator, îl poate naviga și poate deveni o victimă.
Exemple
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modificat în
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Recomandări
- Pur și simplu evitați redirecționarea și redirecționarea în aplicație. Dacă este utilizat, nu implicați utilizarea parametrilor utilizatorului în calculul destinației.
- Dacă parametrii de destinație nu pot fi evitați, asigurați-vă că valoarea furnizată este validă și autorizată pentru utilizator.
Acest articol este contribuit de Prasanthi Eati