Pagina 1 di 1
Ho trovato un SSRF in un sistema di webhook di un SaaS Laravel durante un assessment. Il client HTTP, senza validazione dell'URL di destinazione, permetteva di raggiungere il metadata endpoint AWS (`169.254.169.254`) e quindi le credenziali instance. Da `POST /webhook?url=...` a full account takeover in 4 ore.
In questa categoria scrivo di webhook security applicata: SSRF in client HTTP Laravel (caso reale), validazione URL con allow-list di domini, blocco degli IP privati e link-local, firma HMAC del payload per autenticazione mutua, rate limiting per destinatario, idempotenza per ridurre replay attack.
Se hai un sistema webhook con destinazioni dinamiche e mai auditato, parliamone. Oppure scopri il mio percorso in offensive security.
Ho trovato un SSRF in un sistema di webhook di un SaaS Laravel durante un assessment. Il client HTTP di Laravel, senza validazione dell'URL di destinazione, permetteva di raggiungere i metadata AWS e l'intranet del cliente. Vi spiego il percorso di exploitation completo e le tre righe di codice che lo avrebbero impedito. Continua a leggere
