Italiano: această pagină nu e încă tradusă. Textul de mai jos e în Română.
Într-o aplicație matură, vulnerabilitatea care te costă rar e un XSS reflectat pe care ți-l găsește orice scaner. E lanțul: un acces direct la obiecte care pare inofensiv, plus un flux de resetare a parolei prost gândit, plus un endpoint de API rămas nedocumentat — trei lucruri „medii” care, împreună, îți dau conturile clienților. Scanerele nu văd lanțuri, pentru că nu înțeleg ce face aplicația ta. Aici lucrează experiența unui tester, nu o listă de verificare.
Cum gândim testarea
Nu pornim de la o listă de payload-uri, ci de la aplicație. Cine sunt utilizatorii, ce roluri există, ce date sunt valoroase, ce fluxuri mișcă bani sau identități. Din asta construim un model de amenințare, apoi testăm fiecare rol — autentificat și neautentificat — încercând să facem exact ce n-ar trebui să se poată: să vedem datele altui client, să sărim un pas de plată, să escaladăm de la utilizator la administrator.
Automatizăm ce e repetitiv (descoperire, fuzzing, verificări de configurare), dar validarea și înlănțuirea rămân manuale. Un scaner îți spune că un parametru „pare” injectabil; noi confirmăm, exploatăm controlat și îți arătăm ce ajunge un atacator să citească sau să modifice.
Ce testăm
Metodologia tehnică urmează OWASP Web Security Testing Guide (WSTG), completată pentru API cu OWASP API Security Top 10 și verificată față de ASVS:
- Autorizare — cazul care sperie cel mai des: acces direct la obiecte (IDOR / BOLA), autorizare lipsă la nivel de funcție (BFLA), traversare de căi, escaladare orizontală și verticală. Le testăm sistematic, obiect cu obiect, rol cu rol.
- Autentificare și sesiune — credențiale în transport, resetări de parolă previzibile, blocare la forță brută, fixare și expirare de sesiune, gestionarea și semnătura token-urilor JWT, ocolirea MFA.
- Logica de business — ocolirea fluxurilor, condiții de cursă (de exemplu, dublarea unei tranzacții), abuz de funcționalitate legitimă, manipularea prețurilor sau a cantităților.
- Injecții — SQL și NoSQL, comenzi, template (SSTI), XXE, SSRF, request smuggling, deserializare nesigură — nu doar detecția, ci impactul real.
- Expunerea datelor, configurare și deployment, criptografie slabă, partea de client (CORS, clickjacking, DOM, WebSocket).
La API insistăm pe ce e specific: la GraphQL, introspection și interogări imbricate care obosesc serverul; la REST, mass assignment și expunerea excesivă de proprietăți; peste tot, lipsa limitării de rată și endpoint-urile „fantomă” — versiuni vechi sau nedocumentate, rămase în producție, care nu apar în nicio schemă.
Cum decurge
Lucrăm după PTES și NIST 800-115: scop și model de amenințare → cartografiere și înțelegerea rolurilor → testare autentificată și neautentificată → exploatare și înlănțuire → raport. Alegem Black-Box, Grey-Box sau White-Box în funcție de câtă informație ne pui la dispoziție — cu cât mai multă, cu atât acoperim mai adânc logica, nu doar suprafața.
Ce primești
- Un rezumat executiv care traduce riscul în limbaj de business, pentru management
- Fiecare constatare cu scor CVSS, dovezi (perechi cerere/răspuns, capturi, PoC), impactul concret și pașii de remediere
- Severitate pusă în contextul tău, nu un scor rupt din realitate
- O ordine de prioritate a remedierii, după exploatabilitate
- Retestare după ce repari și o sesiune de prezentare, tehnică și executivă