Cele mai frecvente 10 vulnerabilități de securitate web

OWASP sau Open Web Security Project este o organizație caritabilă non-profit axată pe îmbunătățirea securității software-ului și a 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 prioritizate în funcție de exploatare, detectabilitate și impact asupra software-ului.

• Exploatabilitate -Ce este necesar pentru a exploata vulnerabilitatea de securitate? Cea mai mare exploatare atunci când atacul are nevoie doar de browser web, iar cea mai mică este programarea și instrumentele avansate.
• Detectabilitate - Cât de ușor este să detectezi amenințarea? Cea mai mare este informațiile afișate pe URL, formular sau mesaj de eroare și cea mai mică fiind codul sursă.
• Impact sau daune -Cât de mult daune se vor produce dacă vulnerabilitatea de securitate este expusă sau atacată? Cel mai mare este blocarea completă a sistemului și cel mai scăzut nu este absolut nimic.

Scopul principal al OWASP Top 10 este de a educa dezvoltatorii, designerii, managerii, arhitecții și organizațiile despre cele mai importante vulnerabilități de securitate.

Top 10 vulnerabilități de securitate conform Top 10 OWASP sunt:

Injecție SQL

Description

Injectarea este o vulnerabilitate de securitate care permite unui atacator să modifice backend-ul SQL declarații prin manipularea datelor furnizate de utilizator.

Injectarea are loc atunci când intrarea utilizatorului este trimisă unui interpret ca parte a unei comenzi sau a unei interogări ș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, cum ar fi numele de utilizator, parolele etc. pot fi citite din baza de date.
• Datele bazei de date pot fi modificate (Inserare/Actualizare/Ștergere).
• Administrare Operase pot executa pe baza de date

Obiecte Vulnerabile

• Câmpuri de intrare
• URL-uri care interacționează cu baza de date.

Exemple:

• injecție SQL pe pagina de conectare

Conectarea la o aplicație fără a avea acreditări valide.

Nume de utilizator valid este disponibil, iar parola nu este disponibilă.

Adresa URL de testare: http://demo.testfire.net/default.aspx

Nume utilizator: sjones

Parola: 1=1′ sau pass123

Interogare SQL creată și trimisă la Interpret, după cum urmează

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ or pass123;

Recomandări

1. Lista albă a câmpurilor de intrare
2. Evitați afișarea unor mesaje de eroare detaliate care sunt utile unui atacator.

Cross Site Scripting

Description

Cross Site Scripting este, de asemenea, cunoscut sub numele de XSS.

Vulnerabilitățile XSS vizează scripturi încorporate într-o pagină care sunt executate pe partea clientului, adică browserul utilizatorului, mai degrabă decât pe partea serverului. Aceste defecte pot apărea atunci când aplicația preia date nesigure și le trimite către browserul web fără o validare adecvată.

Atacatorii pot folosi XSS pentru a executa scripturi rău intenționate asupra utilizatorilor, în acest caz, browserele victime. Deoarece browserul nu poate ști dacă scriptul este de încredere sau nu, script-ul va fi executat, iar atacatorul poate deturna cookie-uri de sesiune, denatura site-uri web sau redirecționează utilizatorul către site-uri web nedorite și rău intenționate.

XSS este un atac care permite atacatorului să execute scripturile în browserul victimei.

Implicare:

• Folosind această vulnerabilitate de securitate, un atacator poate injecta scripturi în aplicație, poate fura cookie-uri de sesiune, poate denatura 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.

Cu atât mai grav poate fi făcut un atac dacă atacatorul dorește să afișeze sau să stocheze cookie de sesiune.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com latime = 500 inaltime 500>

Scriptul de mai sus atunci când este rulat, browserul va încărca un cadru invizibil care indică http://google.com.

Atacul poate fi grav prin rularea unui script rău intenționat în browser.

Recomandări

1. Câmpurile de introducere din Lista albă
2. Intrare Ieșire codificare

Autentificare ruptă și gestionarea sesiunii

Description

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 se încheie fie prin deconectare, fie prin închiderea bruscă a browserului, aceste cookie-uri ar trebui să fie 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 stau în sistem și sunt expuse unui atacator. Un atacator folosește același computer public după un timp, datele sensibile sunt compromise.

În același mod, un utilizator care folosește un computer public, în loc să se deconecteze, închide browserul brusc. Un atacator folosește același sistem, atunci când navighează pe același site vulnerabil, se va deschide sesiunea anterioară a victimei. Atacatorul poate face tot ce dorește, de la furt de informații de profil, informații despre cardul de credit etc.

Ar trebui efectuată o verificare pentru a găsi puterea autentificării și a gestionării sesiunii. Cheile, jetoanele de sesiune, cookie-urile ar trebui să fie implementate corect, fără a compromite parolele.

Obiecte Vulnerabile

• ID-urile de sesiune expuse pe URL pot duce la un atac de fixare a sesiunii.
• ID-urile sesiunii la fel înainte și după deconectare și conectare.
• Timpurile sesiunii nu sunt implementate corect.
• Aplicația atribuie același ID de sesiune pentru fiecare sesiune nouă.
• Părțile autentificate ale aplicației sunt protejate folosind SSL, iar parolele sunt stocate în format hashed sau criptat.
• Sesiunea poate fi reutilizată de un utilizator cu privilegii reduse.

Implicare

• Folosind această vulnerabilitate, un atacator poate deturna o sesiune, obține acces neautorizat la sistem care permite dezvăluirea și modificarea informațiilor neautorizate.
• Sesiunile pot fi high jack folosind cookie-uri furate sau sesiuni folosind XSS.

Exemple

1. Aplicația de rezervare a companiilor aeriene acceptă rescrierea adreselor URL, punând ID-uri de sesiune în URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Vânzarea biletelor către Maldive) Un utilizator autentificat al site-ului dorește să-și informeze 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 greșit detaliile cardului de credit salvate.
2. O aplicație este vulnerabilă la XSS, prin care un atacator poate accesa ID-ul sesiunii și poate fi folosită pentru a deturna sesiunea.
3. Timeout-urile aplicațiilor nu sunt setate corect. Utilizatorul folosește un computer public și închide browserul în loc să se deconecteze și pleacă. Atacatorul folosește același browser ceva timp mai târziu, iar sesiunea este autentificată.

Recomandări

1. Toate cerințele de autentificare și de gestionare a sesiunii ar trebui definite conform standardului de verificare a securității aplicațiilor OWASP.
2. Nu expuneți niciodată acreditările în URL-uri sau jurnale.
3. De asemenea, ar trebui depuse eforturi mari pentru a evita defecte XSS care pot fi folosite pentru a fura ID-urile de sesiune.

Referințe nesigure la obiecte directe

Description

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 obține acces la obiecte interne neautorizate, poate modifica datele sau poate compromite aplicația.

Obiecte Vulnerabile

• În adresa URL.

Exemple:

Schimbarea „userid” în următorul URL poate determina atacatorul să vadă informațiile altor utilizatori.

http://www.vulnerablesite.com/userid=123 Modificat la http://www.vulnerablesite.com/userid=124

Un atacator poate vedea informațiile altora schimbând valoarea ID-ului utilizatorului.

Recomandări:

1. Implementarea controalelor de control al accesului.
2. Evitați expunerea referințelor la obiect în URL-uri.
3. Verificați autorizarea pentru toate obiectele de referință.

Falsificare Cerere site-ul

Description

Falsificarea cererii încrucișate este o solicitare falsificată venită de la site-ul încrucișat.

Atacul CSRF este un atac care are loc atunci când un site web, un e-mail sau un program rău intenționat determină browserul unui utilizator să efectueze o acțiune nedorită pe un site de încredere pentru care utilizatorul este în prezent autentificat.

Un atac CSRF obligă browserul unei victime conectate să trimită o solicitare 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 link va fi trimis de către atacator către victimă atunci când utilizatorul face clic pe URL atunci când este conectat la site-ul original, datele vor fi furate de pe site.

Implicare

• Utilizarea acestei vulnerabilități ca atacator poate modifica informațiile despre profilul utilizatorului, poate schimba starea, poate crea un utilizator nou în numele administratorului etc.

Obiecte Vulnerabile

• Pagina de profil utilizator
• Formulare de cont de utilizator
• Pagina de tranzacții comerciale

Exemple

Victima este conectată la un site web al unei bănci folosind acreditări valide. El primește e-mail de la un atacator care spune „Vă rugăm să dați clic aici pentru a dona 1 USD pentru a provoca”.

Când victima face clic pe el, 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ă un buton care spune „Suport cauza”.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Deoarece sesiunea este autentificată și cererea vine prin site-ul băncii, serverul ar transfera 1000 de dolari atacatorului.

Recomandare

1. Obligați prezența utilizatorului în timp ce efectuați acțiuni sensibile.
2. Implementați mecanisme precum CAPTCHA, re-autentificare și jetoane de solicitare unice.

Configurare greșită a securității

Description

Configurația de securitate trebuie să fie 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. Menținerea la zi a software-ului este, de asemenea, o bună securitate.

Implicare

• Folosind această vulnerabilitate, atacatorul poate enumera tehnologia de bază și informațiile despre versiunea serverului de aplicații, informațiile bazei de date și poate obține informații despre aplicație pentru a mai realiza câteva atacuri.

Obiecte vulnerabile

• URL-ul
• Câmpuri formular
• Câmpuri de intrare

Exemple

1. 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.
2. Listarea directorului nu este dezactivată pe serverul dvs. Atacatorul descoperă și poate lista directoare pentru a găsi orice fișier.

Recomandări

1. O arhitectură de aplicație puternică, care oferă o bună separare și securitate între componente.
2. Schimbați numele de utilizator și parolele implicite.
3. Dezactivați listele de directoare și implementați verificări de control al accesului.

Stocare criptografică nesigură

Description

Stocarea criptografică nesigură este o vulnerabilitate comună care există atunci când datele sensibile nu sunt stocate în siguranță.

Datele de conectare ale utilizatorului, informațiile de profil, detaliile de sănătate, informațiile despre cardul de credit etc. fac parte din informațiile 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 necorespunzător prin neutilizarea criptării sau hashingului*, vor fi vulnerabile în fața atacatorilor.

(*Hashingul este transformarea caracterelor șirului în șiruri mai scurte de lungime fixă ​​sau într-o cheie. Pentru a decripta șirul, algoritmul folosit pentru a forma cheia ar trebui să fie disponibil)

Implicare

• Folosind această vulnerabilitate, un atacator poate fura, modifica astfel de date slab protejate pentru a efectua furt de identitate, fraudă cu 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 folosește hashuri nesărate * pentru a stoca parolele tuturor. Un defect de injectare SQL permite atacatorului să recupereze fișierul cu parole. Toate hashe-urile nesărate pot fi forțate în cel mai scurt timp, în timp ce parolele sărate ar dura mii de ani.

(*Hashuri nesărate – Sarea este o dată aleatorie atașată la datele originale. Sarea este atașată la parolă înainte de hashing)

Recomandări

1. Asigurați algoritmi standard puternici corespunzători. Nu creați proprii algoritmi criptografici. Utilizați numai algoritmi publici aprobați, cum ar fi AES, criptografia cu cheie publică RSA și SHA-256 etc.
2. Asigurați-vă că backupurile offsite sunt criptate, dar cheile sunt gestionate și copiate separat.

Nu se restricționează accesul URL

Description

Aplicațiile web verifică drepturile de acces la URL înainte de a reda link-uri ș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 de privilegii. Un atacator poate accesa pagini sensibile, poate invoca funcții și poate vizualiza informații confidențiale.

Implicare

• Folosind această vulnerabilitate, atacatorul poate obține acces la adresele URL neautorizate, fără a vă conecta la aplicație și a exploata vulnerabilitatea. Un atacator poate accesa pagini sensibile, poate invoca funcții și poate vizualiza informații confidențiale.

Obiecte vulnerabile:

• URL-uri

Exemple

1. Atacatorul observă că adresa URL indică rolul ca „/user/getaccounts”. El modifică ca „/admin/getaccounts”.
2. Un atacator poate adăuga un rol la adresa URL.

http://www.vulnerablsite.com poate fi modificat ca http://www.vulnerablesite.com/admin

Recomandări

1. Implementați controale puternice de control al accesului.
2. Politicile de autentificare și autorizare ar trebui să fie bazate pe roluri.
3. Restricționați accesul la adrese URL nedorite.

Protecție insuficientă a stratului de transport

Description

Se ocupă de schimbul de informații între utilizator (client) și server (aplicație). Aplicațiile transmit frecvent informații sensibile, cum ar fi detalii de autentificare, informații despre cardul de credit și jetoane de sesiune printr-o rețea.

Folosind algoritmi slabi sau utilizarea certificatelor expirate sau invalide sau neutilizarea SSL poate permite ca comunicarea să fie expusă unor utilizatori neîncrezători, ceea ce poate compromite o aplicație web și sau poate fura informații sensibile.

Implicare

• Folosind această vulnerabilitate de securitate web, un atacator poate adulmeca acreditările legitime ale utilizatorului și poate obține acces la aplicație.
• Poate fura informații despre cardul de credit.

Obiecte vulnerabile

• Date trimise prin rețea.

Recomandări

1. Activați HTTP securizat și impuneți transferul de acreditări numai prin HTTPS.
2. Asigurați-vă că certificatul este valabil și nu a expirat.

Exemple:

1. O aplicație care nu utilizează SSL, un atacator va monitoriza pur și simplu traficul de rețea și va observa un cookie de sesiune a victimei autentificat. Un atacator poate fura acel cookie și poate efectua un atac Man-in-the-Middle.

Redirecționări și redirecționări nevalidate

Description

Aplicația web folosește puține metode pentru a redirecționa și a redirecționa utilizatorii către alte pagini într-un scop destinat.

Dacă nu există o validare adecvată în timpul redirecționării 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 utilizatorului o adresă URL care conține o adresă URL autentică atașată cu o adresă URL rău intenționată codificată. Un utilizator, văzând doar partea autentică a adresei URL trimise de atacator, o poate răsfoi și poate deveni o victimă.

Exemple

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modificat la

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Recomandări

1. Pur și simplu evitați utilizarea redirecționărilor și redirecționărilor în aplicație. Dacă este utilizat, nu implicați utilizarea parametrilor utilizatorului în calcularea destinației.
2. Dacă parametrii destinației nu pot fi evitați, asigurați-vă că valoarea furnizată este validă și autorizată pentru utilizator.