Google a publicat rezultatele unui agent de securitate bazat pe inteligență artificială, dezvoltat intern, care a petrecut luni de zile căutând vulnerabilități de tip cross-site scripting (XSS) în aplicațiile sale web — iar, spre deosebire de scanerele automate obișnuite, nu s-a oprit la semnalarea codului suspect. Sistemul construiește și rulează lanțuri de exploatare dovedite (proof-of-concept) înainte ca orice raport să ajungă la un inginer uman.
Ce s-a întâmplat
Agentul, construit în principal pe modelele Gemini ale Google, a pornit ca proiect intern la finalul anului 2025 și s-a extins într-un program complet la începutul lui 2026. În loc să se bazeze pe potrivirea de tipare pentru a semnala cod „cu aspect riscant" — abordarea responsabilă pentru o mare parte din zgomotul care afectează scanerele automate — sistemul combină o etapă de triaj realizată de AI cu un validator dedicat. Pentru XSS, acest validator injectează JavaScript într-un mediu de testare similar unui browser real și confirmă că payload-ul chiar se execută înainte ca descoperirea să fie raportată.
Rezultatul, potrivit Google, este o rată de fals-pozitive aproape nulă în teste care acoperă și injecții SQL, path traversal, execuție de cod la distanță și server-side request forgery. Din câteva sute de aplicații construite pe framework-urile web interne, mai riguroase, ale Google, agentul a confirmat doar două probleme XSS — ambele în instrumente interne sau endpoint-uri de debug cu protecții mai slabe decât serviciile de producție, confirmând valoarea controalelor consistente la nivel de framework.
Lanțuri de exploatare, nu doar descoperiri izolate
Cele mai grave descoperiri nu au fost input-uri problematice izolate, ci lanțuri cu mai mulți pași:
- Cache poisoning printr-un segment de URL nevalidat. Un endpoint care servea fișiere JavaScript accepta un segment din calea URL care era reflectat în răspuns, dar exclus din cheia de cache. Acest decalaj însemna că un răspuns malițios putea fi stocat în cache și livrat altor vizitatori din aceeași regiune. Google nu a găsit dovezi de exploatare reală, dar lanțul putea afecta domenii sensibile operate de Google și orice site terț care încărca scriptul respectiv.
- Ocolirea unei redirecționări semnate, pe o consolă de administrare. Un parametru de redirecționare nevalidat putea ajunge la
window.location, însă o cerință de semnătură criptografică bloca inițial exploatarea — până când agentul a identificat un alt endpoint de autorizare care genera o semnătură validă pentru un URL JavaScript controlat de atacator, transformând o redirecționare „protejată" într-un vector XSS funcțional. - O vulnerabilitate de tip nonce/postMessage într-o extensie de browser. Verificări permisive pe lista de conexiuni externe permise ale extensiei, combinate cu un nonce de unică folosință recuperabil și o redirecționare a mesajelor prea permisivă, au permis conținutului controlat de atacator să ajungă pe o pagină aflată în debugging activ. Pentru că fluxul accepta și URL-uri de tip
data:, problema a escaladat până la execuție JavaScript arbitrară — o condiție XSS universală.
De ce contează
Nu este doar o poveste despre Google care își repară propriile produse — este un semnal despre direcția în care se îndreaptă cercetarea automată de vulnerabilități. Combinarea unui strat de triaj AI cu o validare deterministă, bazată pe execuție reală, este o abordare semnificativ diferită față de scanerele care doar potrivesc tipare și livrează analiștilor o listă de „posibile" probleme. Lanțurile de cache poisoning și de ocolire a redirecționării semnate ilustrează bine cum breșe aparent minore — un segment de cale nevalidat, un parametru de redirecționare — se pot combina într-o execuție de cod cu impact ridicat, în browser.
Google precizează că propriii validatori pot rata în continuare probleme reale și că inginerii umani continuă să revizuiască fiecare remediere propusă înainte de lansare — o reamintire că descoperirea asistată de AI amplifică procesul de triaj, dar nu înlocuiește revizuirea umană.
Ce trebuie să faceți
- Auditați modul în care se construiesc cheile de cache pentru orice endpoint care reflectă segmente de cale, parametri de query sau header-e într-un răspuns cache-uit — dacă valoarea reflectată nu face parte din cheia de cache, aveți probabil un vector de poisoning.
- Reverificați validarea redirecționărilor de la un capăt la altul, inclusiv orice serviciu de semnare sau autorizare care emite token-uri pentru destinații de redirecționare — o verificare de semnătură este la fel de puternică precum cel mai slab endpoint capabil să genereze o semnătură validă.
- Revizuiți gestionarea mesajelor în extensiile de browser: validați originea expeditorului la fiecare listener de
postMessage, tratați nonce-urile de unică folosință ca fiind single-use pe server (nu doar pe client) și nu permiteți niciodată URL-uridata:acolo unde poate fi atins un context de execuție de script. - Combinați scanarea asistată de AI cu validarea bazată pe execuție în propriul pipeline — semnalarea tiparelor riscante e ieftină; demonstrarea exploatabilității este ceea ce reduce cu adevărat timpul de triaj.