Curs de pregatire Testarea Securității Aplicațiilor: OWASP Top 10, SAST, DAST și SCA

A01:2025 – Broken Access Control

Controlul accesului aplică politici astfel încât utilizatorii să nu poată acționa dincolo de permisiunile lor intenționate. Eșecurile conduc de obicei la divulgarea neautorizată, modificarea sau distrugerea datelor, sau la executarea unor funcții de business în afara limitelor utilizatorului.

Aspecte Practice

• Exemple practice de control al accesului defect

• Controale de acces securizate și bune practici

A02:2025 – Security Misconfiguration

Configurația incorectă de securitate apare când un sistem, o aplicație sau un serviciu în cloud este configurat greșit din punct de vedere al securității, creând vulnerabilități.

Aspecte Practice

• Exemple din realitate ale configurărilor incorecte

• Pași pentru prevenirea configurațiilor incorecte, inclusiv managementul configurațiilor și instrumente de automatizare

A03:2025 – Software Supply Chain Failures

Eșecurile în lanțul de livrare software sunt defecțiuni sau alte compromiteri în procesul de construire, distribuție sau actualizare a software-ului. Ele sunt adesea cauzate de vulnerabilități sau modificări malițioase în codul terț, instrumente sau alte dependențe de care se bazează sistemul.

A04:2025 – Cryptographic Failures

În general, toate datele în tranzit ar trebui criptate la nivelul stratului de transport (stratul 4 OSI). Barele anterioare, precum performanța CPU și gestionarea cheilor private/certificatelor, sunt acum gestionate de CPU-uri care au instrucțiuni proiectate pentru accelerarea criptării (de ex. suport AES) și de simplificarea gestionării cheilor private și a certificatelor prin servicii precum LetsEncrypt.org, cu majoritatea vendorilor de cloud oferind servicii de gestionare a certificatelor încă mai bine integrate pentru platformele lor specifice.

Dincolo de securizarea stratului de transport, este important să determinăm ce date necesită criptare la stocare și ce date necesită criptare suplimentară în tranzit (la nivelul stratului de aplicație, stratul 7 OSI).

De exemplu, parolele, numerele de carduri de credit, înregistrările de sănătate, informațiile personale și secretele de afaceri necesită protecție suplimentară, mai ales dacă aceste date intră sub incidența legilor de confidențialitate, de exemplu Regulamentul General al Uniunii Europene privind Protecția Datelor (GDPR) sau reglementări precum PCI Data Security Standard (PCI DSS).

Aspecte Practice

• Analiză detaliată a eșecurilor criptografice, cum ar fi algoritmi de criptare slabi sau gestionare incorectă a cheilor

• Importanța mecanismelor criptografice robuste, protocoale securizate (SSL/TLS) și exemple de criptografie modernă în securitatea web

A05:2025 – Injection

O vulnerabilitate de injecție este o deficiență a sistemului care permite unui atacator să insereze cod sau comenzi malițioase (cum ar fi cod SQL sau shell) în câmpurile de intrare ale unui program, înșelând sistemul să execute codul sau comenzile ca și cum ar face parte din sistem. Acest lucru poate duce la consecințe cu adevărat grave.

Aspecte Practice

• Decompunere detaliată a injecțiilor SQL, NoSQL, OS și LDAP

• Tehnici de mitigare folosind declarații pregătite, interogări parametrizate și escaparea intrărilor

A06:2025 – Insecure Design

Designul insecur este o categorie largă care reprezintă diferite slăbiciuni, exprimate ca „lipsa sau ineficiența design-ului de control”.

Designul insecur nu este sursa tuturor celorlalte categorii de riscuri din Top 10. Reține că există o diferență între design insecur și implementare insecură. Diferențiem între defecțiuni de design și defecte de implementare dintr-un motiv anume: ele au cauze rădăcină diferite, au loc în momente diferite ale procesului de dezvoltare și necesită remedieri diferite.

Un design securizant poate avea totuși defecte de implementare care conduc la vulnerabilități care pot fi exploatare. Un design insecur nu poate fi remediat printr-o implementare perfectă, deoarece controalele de securitate necesare nu au fost niciodată create pentru a se apără împotriva atacurilor specifice.

Unul dintre factorii care contribuie la designul insecur este lipsa profilării riscurilor de business inerente software-ului sau sistemului dezvoltat, ducând la eșecul de a determina ce nivel de design de securitate este necesar.

Aspecte Practice

• Vom explora defecțiuni de design care pot duce la vulnerabilități, cum ar fi validarea incorectă a intrărilor

• Vom studia strategii pentru arhitectură securizantă și principii de design securizant

A07:2025 – Authentication Failures

Când un atacator reușește să înșele un sistem să recunoască un utilizator invalid sau incorect ca legitim, această vulnerabilitate este prezentă.

Aspecte Practice

• Probleme comune de autentificare

• Strategii de autentificare securizantă, cum ar fi autentificarea multifactor și gestionarea corespunzătoare a sesiunilor

A08:2025 – Software or Data Integrity Failures

Eșecurile de integritate a software-ului și a datelor se referă la codul și infrastructura care nu protejează împotriva codului sau datelor invalide sau nefiabile, tratate ca fiind încredute și valide.

Un exemplu al acestui lucru este când o aplicație se bazează pe plugin-uri, biblioteci sau module din surse nefiabile, repozytoare sau rețele de distribuție a conținutului (CDN-uri).

O pipeline CI/CD insecur, care nu consumă și nu oferă verificări de integritate ale software-ului, poate introduce potențialul pentru acces neautorizat, cod insecur sau malițios, sau compromiterea sistemului.

Un alt exemplu pentru aceasta este o CI/CD care preia cod sau artefacte din locuri nefiabile și/sau nu le verifică înainte de utilizare (prin verificarea semnăturii sau mecanism similar).

Aspecte Practice

• Focus pe probleme precum actualizări de software nefiabile și manipularea datelor

• Mecanisme de actualizare securizantă și verificări de integritate a datelor

A09:2025 – Security Logging and Alerting Failures

Fără jurnalizare și monitorizare, atacurile și breșele nu pot fi detectate, iar fără avertizare este foarte dificil să se răspundă rapid și eficient în timpul unui incident de securitate.

Jurnalizarea insuficientă, monitorizarea continuă, detectarea și avertizarea pentru a iniția răspunsuri active apar oricând.

Aspecte Practice

• Importanța jurnalizării informațiilor relevante pentru securitate și monitorizării activităților suspecte

• Instrumente și practici pentru jurnalizare corespunzătoare și monitorizare în timp real pentru a detecta breșele devreme

A10:2025 – Mishandling of Exceptional Conditions

Gestionarea necorespunzătoare a condițiilor excepționale în software apare când programele eșuează să prevină, să detecteze și să răspundă la situații neobișnuite și neprevăzute, ducând la crăpări, comportament neașteptat și uneori vulnerabilități.

Acesta poate implica una sau mai multe dintre următoarele 3 deficiențe:

• Aplicația nu previne apariția unei situații neobișnuite

• Nu identifică situația pe măsură ce se întâmplă

• Răspunde slab sau deloc la situația ulterior

SAST – Static Application Security Testing

1. Ce este analiza statică și când să o rulezi în SDLC (shift left)

2. Tipuri de vulnerabilități detectabile prin SAST, cod vulnerabil vs cod securizant

3. Prezentare de ansamblu a instrumentelor SAST (de ex. Semgrep, SonarQube, Checkmarx, în funcție de stack-ul clientului)

4. Exercițiu practic: rulează o scanare SAST pe un repozytoriu cu vulnerabilități introduse deliberat, interpretează rezultatele, triajează falsele pozitive vs vulnerabilitățile reale

DAST – Dynamic Application Security Testing

1. Diferența dintre SAST și DAST, testare black box pe aplicația în funcțiune

2. Fluxul scanării DAST, crawling, fuzzing, analiza răspunsului

3. Prezentare de ansamblu a instrumentelor DAST (de ex. OWASP ZAP, Burp Suite)

4. Exercițiu practic: rulează o scanare DAST pe o aplicație de testare vulnerabilă (de ex. OWASP Juice Shop), identifică și validează constatărilor

SCA – Software Composition Analysis

1. Riscul dependențelor și bibliotecilor terțe, vulnerabilități moștenite

2. SBOM, Software Bill of Materials, ce este și de ce contează

3. Prezentare de ansamblu a instrumentelor SCA (de ex. Dependency Check, Snyk, GitHub Dependabot)

4. Exercițiu practic: rulează o scanare SCA pe un proiect real, identifică dependențele vulnerabile și construiește un plan de remediere (actualizare, patch, mitigare)