22 Vulnerabilități comune ale aplicațiilor web de cunoscut

Companiile „se schimbă în mod constant la stânga” și profită de experiențele inovatoare ale clienților și angajaților oferite de aplicațiile bazate pe cloud. În același timp, autorii rău-intenționați își revizuiesc continuu strategiile de atac pentru a se potrivi cu această schimbare.

Pentru a păstra confidențialitatea și securitatea datelor, este imperativ ca companiile să caute protecție împotriva acestor 22 de vulnerabilități comune ale aplicațiilor web .

1. Controlul accesului deteriorat

   Controalele de acces sunt responsabile de modul în care utilizatorii interacționează cu resursele și datele, precum și de ceea ce pot edita și/sau citi. O vulnerabilitate defectuoasă a controlului accesului este posibilă atunci când utilizatorul este capabil să angajeze datele într-un mod care este cu adevărat inutil. De exemplu, dacă utilizatorul ar trebui să fie capabil doar să citească detaliile de plată, dar are de fapt capacitatea de a le edita, o astfel de situație exemplifica un control al accesului întrerupt. Atacatorii rău intenționați profită de această vulnerabilitate pentru a obține acces neautorizat la software, rețele și sisteme. Ei pot apoi exploata situația, acorda ID-ului utilizatorului mai mult acces în cadrul infrastructurii, pentru a compromite disponibilitatea datelor, confidențialitatea sau integritatea.

2. Autentificare deteriorată

   Vulnerabilitățile aplicațiilor web asociate cu autentificarea deteriorată sau întreruptă provin și din accesul utilizatorului. În acest caz, totuși, atacatorii rău intenționați au un impact negativ asupra datelor care confirmă identitatea unui utilizator, cum ar fi prin deturnarea jetoanelor, cheilor sau parolelor de sesiune. Atacatorul rău intenționat obține acces neautorizat la software, sisteme și rețele, deoarece organizația nu a reușit să stabilească în mod corespunzător controalele adecvate de gestionare a identității și a accesului.

3. Injecție cu retur și alimentare cu linie (CRLF).

   Carriage return acţionează ca o comandă care indică începutul unei linii de cod, de obicei indicată ca /r. Line feed, pe de altă parte, este o comandă care denotă sfârșitul unei linii de cod, de obicei indicată ca /n. La fel ca multe alte programe software, fiecare sistem de operare utilizează combinații variate de întoarcere a căruciorului și avans de linie. Când atacatorii rău intenționați sunt implicați în injecțiile CRLF, codul introdus modifică modul în care aplicația web reacționează la comenzi. Aceasta poate fi folosită fie pentru a dezvălui date sensibile, fie pentru a executa cod.

4. Transformarea cifrului nesigură

   Cifrul, care este un termen standard pentru „algoritm de criptare”, este de fapt matematica din spatele unui proces de criptare sau decriptare. Transformarea se referă la schița operațiunilor efectuate la intrare pentru a furniza rezultatul așteptat. Astfel, o transformare de criptare se referă la numărul de operațiuni care ascund datele criptate ilegibile înapoi la date decriptate, care pot fi citite. O vulnerabilitate nesigură a transformării cifrului descrie faptul că algoritmul de criptare poate fi spart cu ușurință, în cele din urmă sabotând esența criptării în primă instanță.

5. Componente cu vulnerabilități evidente

   Fiecare aplicație web depinde de alte componente pentru a funcționa. De exemplu, dacă operați o aplicație pe un web sau un server de aplicații fără corecții, serverul este partea cu vulnerabilități evidente. Lista Common Vulnerabilities and Exposures (CVE) cuprinde toate vulnerabilitățile de securitate cunoscute. Deoarece atacatorii rău intenționați au cunoștințe despre listă, ei caută frecvent componente fără actualizări adecvate ale corecțiilor de securitate. În momentul în care se pot infiltra într-o componentă a aplicației web, pot obține acces și la datele aplicației.

6. Politica de partajare a resurselor între origini (CORS).

   Toate aplicațiile bazate pe web folosesc o adresă URL ca mijloc de conectare a browserului utilizatorului la serverul acestuia. Politica privind aceeași origine este o protecție comună. În conformitate cu aceasta, serverul va răspunde doar la o adresă URL cu același protocol, schemă de cale și nume de domeniu de nivel superior. Acest lucru înseamnă că puteți accesa http://organization.com/page1 și http://organization.com/page2, deoarece ambele au următoarele:

   • Protocol: HTTP
   • Domeniu: Company.com
   • Schema de cale: /pagina#

   Deși este sigură, Politica de aceeași origine este restrictivă atunci când se ocupă de aplicații bazate pe web care necesită acces la resurse care se conectează la terțe părți sau subdomenii.

   O politică CORS acordă browserului permisiunea de a vizualiza aceste resurse interconectate prin stabilirea unui număr de anteturi HTTP permise considerate a fi „de încredere”. De exemplu, o aplicație ar putea fi nevoită să extragă date din două baze de date pe servere web separate. Întocmirea unei anumite liste „permise” devine o muncă excesivă, deoarece includeți servere suplimentare. Deoarece ambele servere „partajează” aplicația, compania scrie o politică CORS care permite browserelor să se conecteze la ambele. Dacă o politică CORS nu este, totuși, definită corespunzător, atunci politica poate permite serverelor să acorde acces atunci când este solicitat de un atacator rău intenționat.

7. Gestionarea acreditărilor

   Acreditările utilizatorului includ un ID de utilizator și o cheie de acces. Utilizatorul trebuie să furnizeze ambele informații în pagina de autentificare înainte de a obține accesul la o aplicație. Cu toate acestea, bazele de date tind să utilizeze o criptare slabă sau să păstreze informațiile în text simplu. Gestionarea slabă a acreditărilor permite atacatorilor să fure cu ușurință acreditările și să le exploateze pentru a obține acces la aplicații web.

8. Falsificarea cererii pe mai multe site-uri (CSRF)

   Un atac CSRF utilizează metodologii de inginerie socială pentru a determina un utilizator să modifice informații, cum ar fi parolele sau numele de utilizator, într-o aplicație. Un CSRF, spre deosebire de atacurile de tip cross-site scripting (XXS) sau malware, necesită ca un utilizator să fie conectat la aplicația care utilizează numai cookie-uri de sesiune pentru validarea solicitărilor utilizatorilor sau a sesiunilor de urmărire. În momentul în care utilizatorul efectuează acțiunea anticipată, actorul rău intenționat folosește browserul pentru a executa partea rămasă a atacului, cum ar fi mutarea fondurilor, fără ca utilizatorul să știe ce s-a întâmplat.

9. Cross-site scripting (XXS)

   Spre deosebire de un CSRF care cere ca utilizatorul să fie conectat la o aplicație pentru a fi înșelat să schimbe anumite informații, un atac XXS necesită ca atacatorul rău intenționat să introducă cod într-o pagină web, de obicei în unele componente ale paginii, cum ar fi o imagine. Odată ce un utilizator lansează pagina web în browserul său, codul prost începe să se descarce și să ruleze în browser. De exemplu, codul rău intenționat poate redirecționa utilizatorul de la un site credibil la unul nelegitim.

10. Indexarea directoarelor

    De obicei, serverele web conturează toate fișierele salvate pe ele într-un singur director. Când un utilizator dorește să localizeze un anumit fișier într-o aplicație web, de obicei adaugă numele fișierului în cerere. În cazul în care fișierul nu este disponibil, aplicația va prezenta utilizatorului o listă cu toate fișierele indexate, astfel încât utilizatorul să aibă opțiunea de a selecta altceva.

    Cu toate acestea, fișierele sunt indexate automat de serverele web. Atunci când aplicația prezintă o listă cu toate fișierele stocate, un atacator rău intenționat care profită de vulnerabilitățile din indexul directorului poate obține acces la date care le pot oferi mai multe informații despre sistem. De exemplu, ei pot cunoaște despre conturile personale de utilizator sau despre convențiile de denumire. Aceste două puncte de date pot fi exploatate pentru a efectua atacuri de furt de acreditări sau pentru a dezvălui informații sensibile.

11. Parcurgerea directorului

    Cunoscută și ca atac de backtracking, dot-dot-slash și director climbing, vulnerabilitatea de traversare a directoarelor exploatează modul în care o aplicație primește date de la serverul web. Listele de control al accesului (ACL) restricționează, în general, accesul utilizatorilor la anumite fișiere date dintr-un director rădăcină. Atacatorii rău intenționați care folosesc modul de vulnerabilitate de traversare a directoarelor descoperă formatul URL pe care aplicația îl folosește pentru a solicita fișiere.

12. Încapsulare

    Spre deosebire de unele dintre celelalte vulnerabilități comune ale aplicațiilor web de pe listă, vulnerabilitatea de încapsulare profită de defectele modului în care un dezvoltator a codificat aplicația. Încapsularea este un termen de programare care se referă la gruparea datelor și acțiunilor care pot fi efectuate pe acele date într-o singură unitate. Încapsularea securizează datele prin ascunderea informațiilor despre cum rulează codul, ceea ce oferă o interfață de utilizator mai bună. Utilizatorii nu trebuie să știe cum le furnizează aplicația datele; tot ce au nevoie este accesul la el.

    

    De exemplu, un dezvoltator de aplicații poate include controale de acces, cum ar fi permisiunile de citire sau scriere, în capacitatea unei aplicații de a prelua date. Dacă utilizatorul solicită informații în aplicație, aceasta furnizează numai datele pe care i s-a permis să le acceseze.

    Dar dacă dezvoltatorii nu reușesc să stabilească limite clar definite între date și acțiunile efectuate în diferite aspecte ale aplicației, aplicația suferă o vulnerabilitate de încapsulare. Atacatorii profită de acest lucru trimițând o cerere către aplicație, știind că o astfel de acțiune ar duce la un mesaj de eroare. Acest mesaj de eroare oferă apoi informații cu privire la structura aplicației, ajutând mai multe strategii de atac, cum ar fi un DOS – denial of service.

13. Referințe directe la obiecte nesigure (IDOR)

    URL-urile aplicațiilor web sunt capabile să expună modelul sau formatul folosit pentru direcționarea utilizatorilor către locații de stocare back-end. De exemplu, o adresă URL poate afișa modelul/formatul pentru un identificator de înregistrare într-un sistem de stocare, cum ar fi un sistem de fișiere sau o bază de date.

    Numai IDOR ar putea fi o preocupare cu risc scăzut. Cu toate acestea, atunci când un IDOR este combinat cu o verificare a controlului accesului eșuat, atacatorii au șansa de a lovi cu succes.

    Alte vulnerabilități comune ale aplicațiilor web pe care ar trebui să le cunoașteți sunt:

14. Divizarea răspunsului HTTP

    Acesta este un fel de atac de injecție CRLF. HTTP este procesul prin care browserele trimit interogări, iar serverele trimit înapoi răspunsurile. În această vulnerabilitate a aplicației web, atacatorii rău intenționați folosesc notațiile CR și LR pentru a manipula modul în care browserele și serverele comunică între ele, ceea ce oferă o solicitare, dar îi spune serverului să „împartă” răspunsul în diferite părți. Împărțirea răspunsului în două părți diferite permite actorului rău intenționat să obțină controlul asupra informațiilor pe care serverul le oferă ca răspuns la cealaltă parte a cererii. Când astfel de date solicitate sunt date de identificare a utilizatorului sau informații sensibile, actorul rău intenționat a efectuat cu succes atacul.

15. Defect de injectare

    Un defect de injectare permite o multitudine de diferite tehnici de atac. Orice aplicație care permite utilizatorilor să actualizeze comanda shell, apelul sistemului de operare sau o bază de date poate suferi o eroare de injectare. Atacatorii rău intenționați folosesc defecte de injectare pentru a modifica comenzile care se dezvoltă în acțiuni noi și neașteptate în cadrul aplicației. Profitând de aceste vulnerabilități, actorii rău intenționați pot crea, actualiza, citi sau chiar șterge date.

16. Vulnerabilitate nesigură de rezumare a mesajelor

    Aceasta este o vulnerabilitate criptografică care limitează eficacitatea criptării. Un rezumat al mesajului ar trebui să cuprindă funcția hash criptografică. Spre deosebire de criptare, funcțiile hash nu necesită ca expeditorul și utilizatorii să folosească chei.

    Atacatorii rău intenționați profită astfel de vulnerabilitățile nesigure de digest pentru a perpetua „atac de coliziuni hash”. Obiectivul atacului este de a afla dacă trimiterea unei intrări duce la generarea unui hash duplicat. Dacă acțiunea rău intenționată generează forțat un hash partajat, atunci ei pot folosi acest hash pentru a prezenta un fișier malign pentru descărcare. Acest lucru lasă utilizatorul final cu presupunerea că fișierul este legitim.

17. Protecție insuficientă a stratului de transport

    Securitatea stratului de transport (TLS) se referă la procesul prin care aplicațiile computerizate pot „comunica” în siguranță între ele pe internet. Un număr de aplicații utilizează numai TLS în timpul procesului de autentificare, ceea ce lasă datele și informațiile despre sesiunile de identificare vulnerabile atunci când o persoană utilizează aplicația.

    Atacatorii pot profita de această vulnerabilitate pentru a devia datele pe măsură ce acestea se deplasează pe internet între dispozitivul utilizatorului și serverul de aplicații.

18. Execuție de cod de la distanță (RCE)

    Vulnerabilitățile de execuție a codului de la distanță sunt erori de codare în aplicațiile web care permit atacatorilor rău intenționați să introducă cod, indiferent de locația lor geografică. RCE se încadrează într-o categorie mai largă de vulnerabilități de injectare a aplicațiilor web, în ​​care atacatorii introduc propriul cod într-o aplicație care nu va confirma intrările utilizatorilor, ceea ce face ca serverul să îl vadă ca un cod de aplicație autentic. De obicei, atacatorii rău intenționați vor profita de vulnerabilitățile nepattchizate cunoscute și își vor introduce codul în aplicație.

19. Includerea fișierelor de la distanță (RFI)

    Pentru a lega directoare comune la o aplicație, dezvoltatorii adaugă declarații „include” în codul lor. De exemplu, o aplicație ar putea fi nevoită să extragă date dintr-o bază de date. În loc să îl codificați manual pentru a obține fiecare fișier, instrucțiunea „include” ajută la conectarea întregului director sursă, astfel încât tot ce este stocat acolo să poată fi folosit.

    Atunci când o aplicație web suferă o vulnerabilitate RFI, atunci atacatorii pot manipula aplicația pentru a încărca cod rău intenționat sau malware în baza de date, server sau site web.

20. Configurare greșită de securitate

    Probabilitatea unei configurări greșite de securitate este într-adevăr una dintre cele mai comune vulnerabilități ale aplicațiilor web de astăzi. Această vulnerabilitate va apărea în general din cauza eșecului unei organizații de a modifica setările implicite de securitate. Configurațiile greșite comune de securitate sunt:

    • Folosind parole sau conturi implicite
    • Software necorectat
    • Fără criptare
    • Politici inadecvate pentru firewall
    • Neglijând resursele, caracteristicile și alte componente neutilizate

21. injecție SQL

    SQL, care înseamnă Structured Query Language, este un limbaj de programare folosit pentru baze de date. Permite regăsirea și manipularea datelor pentru baze de date relaționale. O vulnerabilitate de injectare SQL se află sub un grup mai mare de intrări de utilizator neverificate. Când actorii rău intenționați trimit în mod deliberat solicitări false, aplicația web răspunde cu un mesaj de eroare care le oferă informații despre structura și protecția bazei de date.

22. Activare automată nevalidată a bibliotecii

    Pentru a economisi timp la codificare, dezvoltatorii tind să folosească biblioteci terțe. În cele mai multe cazuri, acest lucru le permite să utilizeze codul pre-testat care accelerează procesul de dezvoltare a aplicației. Cu toate acestea, utilizarea codului open-source disponibil publicului crește riscurile de securitate, inclusiv:

    • Absența proprietății documentate crește riscul de adăugare a codului malign
    • Proiecte neglijate care nu mai sunt actualizate

    Această vulnerabilitate particulară este din ce în ce mai răspândită, având în vedere că mai multe aplicații implică dependențe de biblioteci terță parte.

Sperăm că conținutul acestei postări pe blog v-a fost într-adevăr util și perspicace. Asigurându-vă că găsiți o soluție pentru orice vulnerabilitate a aplicației web care se aplică cazului dvs. va schimba jocul în experiențele angajaților și clienților dvs.