Când login-ul îl lasă pe solicitant să aleagă unde ajunge codul OTP
Un cod unic (OTP) dovedește identitatea doar dacă ajunge într-un loc pe care contul îl cunoaște deja. Un studiu de caz publicat recent arată ce se întâmplă când nu e așa. Un agent de testare automat, într-o evaluare autorizată, a descoperit că login-ul de producție al unui mare asigurător trimitea codul de autentificare la orice adresă de email specificată în cerere. Al doilea factor devenea astfel o simplă formalitate.
Ce s-a întâmplat
Potrivit Reflectiz, furnizorul de securitate care semnează studiul, agentul său de testare bazat pe AI cartografia fluxul de autentificare al site-ului de clienți al unui asigurător important. Asigurătorul are milioane de utilizatori și nu este numit. Analizând codul JavaScript și apelurile API din spatele paginilor, agentul a observat două câmpuri în cererea OTP: unul stabilea canalul de livrare, iar celălalt adresa de destinație.
În mod normal, codul pleca prin SMS la numărul de telefon din cont. Când agentul a schimbat canalul în email și a indicat o căsuță pe care o controla, serverul a trimis codul acolo. Nu a verificat niciodată dacă adresa aparține contului. Codul a funcționat, autentificarea a reușit, iar mecanismele de siguranță ale agentului au oprit testul în acel punct. Furnizorul spune că a clasificat problema drept critică și a raportat-o asigurătorului.
Câteva nuanțe importante:
- Detaliile provin din relatarea furnizorului, într-un conținut sponsorizat, iar asigurătorul este anonimizat.
- Pentru a abuza de vulnerabilitate, un atacator ar avea nevoie de identificatorii clientului ceruți în cerere, cum ar fi un număr de identificare și numărul de telefon.
- Asigurătorul ar fi făcut un pentest cu aproximativ șase luni înainte. Nu este clar când a apărut slăbiciunea, deci nu se poate spune că testul anterior a ratat-o.
- Studiul nu precizează dacă sau când a fost remediată problema.
De ce contează
Este o eroare clasică de autentificare defectuoasă, nu ceva exotic. Ghidul de testare OWASP întreabă explicit dacă OTP-urile sunt legate de contul corect. Când câmpuri trimise de client decid unde e livrat un secret, MFA se reduce practic la „cunoaște ID-ul și telefonul clientului”. Astfel de date apar frecvent în breșe.
Există și o lecție de proces. Astfel de erori apar de obicei când se adaugă o funcție nouă, de tipul „trimite-mi codul pe email”. Testarea punctuală surprinde doar un instantaneu al unei aplicații care se schimbă la fiecare lansare.
Ce e de făcut
- Legați livrarea OTP pe server. Destinația trebuie stabilită doar din datele de contact deja verificate în cont. Nu acceptați niciodată o adresă sau un telefon din cererea de login.
- Tratați schimbarea canalului ca operațiune sensibilă. Dacă utilizatorii pot alege între SMS și email, oferiți doar canale deja înregistrate și verificate, referite printr-un ID opac, nu prin adresa propriu-zisă.
- Revizuiți structura cererilor. Verificați fiecare endpoint de autentificare, recuperare și step-up pentru câmpuri precum
channel,sendTo,emailsauphone. Respingeți-le sau ignorați-le acolo unde clientul nu ar trebui să le controleze. - Testați logica de business, nu doar lista scannerului. Adăugați în CI teste negative (un OTP către o destinație neînregistrată trebuie să eșueze) și includeți fluxurile de autentificare în evaluările recurente.
- Monitorizați abuzurile. Generați alerte pentru OTP-uri trimise la destinații care nu corespund profilului contului și limitați numărul de cereri OTP per cont și per identificator.
- Retestați după modificări ale fluxurilor de login, recuperare sau MFA, în loc să așteptați următorul pentest anual.
Credit: acest articol rezumă un studiu de caz sponsorizat al Reflectiz, publicat de The Hacker News pe 14 octombrie 2026.