Google: PageBreak ha trovato oltre 500 XSS verificati

Oltre 500 falle XSS verificate nelle app web di Google. Le ha trovate PageBreak, un agente di sicurezza che usa i modelli Gemini e che opera a pieno regime da gennaio. Ogni segnalazione nasce solo dopo un exploit riuscito su un’applicazione in esecuzione, con falsi positivi vicini allo zero¹.

Il paper spiega la catena di verifica. Il modello genera ipotesi di vulnerabilità. Validatori deterministici provano l’exploit contro un ambiente reale. Se l’exploit funziona, parte il report. Altrimenti la traccia si chiude. La novità non è l’uso del modello, ma la prova obbligatoria in runtime prima della segnalazione¹.

Michał Bentkowski, information security engineer di Google, riassume la scelta: “Abbiamo deciso di dare priorità alla validazione deterministica. Invece di limitarci a ipotizzare bug da pattern di codice, il sistema chiude il loop verificando i potenziali difetti su ambienti in esecuzione. Questo porta a un tasso di falsi positivi vicino allo zero, evitando di sovraccaricare i team di prodotto con segnalazioni non verificate”¹.

Gli oracoli di successo sono concreti e specifici. Per XSS, il validatore considera confermata la falla se esegue JavaScript nella pagina. Per path traversal, il test cerca di scrivere in una posizione leggibile da chiunque. Per scenari di esecuzione di codice remoto, l’indizio è l’attivazione di una richiesta DNS in uscita. In tutti i casi, il risultato non si basa su pattern di codice, ma su effetti osservabili nel sistema che gira davvero¹.

La cifra, oltre 500 XSS, riguarda le applicazioni web interne a Google e copre il periodo successivo all’avvio in piena operatività da gennaio. Il dato arriva dopo la messa a punto del circuito di verifica, che separa in modo netto la fase esplorativa dalla prova. Il modello propone, il validatore dimostra, il sistema segnala. La soglia di qualità dipende dall’exploit riuscito, non dal grado di fiducia del modello¹.

Il flusso ha un effetto operativo chiaro: riduce il rumore per i team di prodotto. Arrivano meno ticket, ma più solidi, perché ogni report contiene un caso riproducibile. La replica avviene nello stesso tipo di ambiente in cui gira il software, non in condizioni artificiali. La scelta mira a tagliare il carico di analisi su segnalazioni non ripetibili e a concentrare l’attenzione su problemi con impatto verificato¹.

Gli esempi per XSS, path traversal e tentativi di RCE indicano un approccio trasferibile a più classi di bug, purché esista un oracolo osservabile nell’ambiente di esecuzione. La condizione è stringente, ma dà un output misurabile: o l’azione avviene, o non avviene. Questo vincolo, spiega il paper, tiene bassa la frequenza di falsi positivi e permette di scalare la ricerca in modo controllato all’interno dell’azienda¹.