Server-Side Request Forgery
Server-Side Request Forgery
Il Server-Side Request Forgery, o SSRF, avviene quando un input controllato dall'attaccante spinge un server a inviare una richiesta. La richiesta raggiunge un luogo dove non dovrebbe arrivare.
Un altro esempio
Uno strumento per le fatture accetta un URL del logo del fornitore. Lo analizza una sola volta, consente solo host HTTPS di fornitori approvati e rifiuta indirizzi privati risolti, loopback, link-local o di metadata. Inoltre disattiva i reindirizzamenti, limita byte e tempo, utilizza un proxy in uscita e blocca `http://169.254.169.254`.
Parti principali
- 01URL influenzato dall'attaccante
- 02Capacità di fetch lato server
- 03Controlli di destinazione e di uscita
Usalo quando
Esamina la minaccia per ogni funzione del server che recupera un URL influenzato dall'utente. Applica liste di destinazione consentite, limiti di uscita dalla rete e controlli dopo la risoluzione del nome.
Non usarlo quando
Un prefisso di testo, una sola ricerca DNS o il parsing di URL da soli non sono sufficienti. I reindirizzamenti e il DNS rebinding possono superare il confine controllato.
Nome usato nel codice
strict URL parser + destination allowlist + IP-range checks + redirect policy + egress proxy Prima di spedire
Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target.
Outcome: Complete the task with Server-Side Request Forgery (Server-Side Request Forgery). User context: Uno strumento per le fatture accetta un URL del logo del fornitore. Lo analizza una sola volta, consente solo host HTTPS di fornitori approvati e rifiuta indirizzi privati risolti, loopback, link-local o di metadata. Inoltre disattiva i reindirizzamenti, limita byte e tempo, utilizza un proxy in uscita e blocca `http://169.254.169.254`. Risk or control to address: Server-Side Request Forgery (Server-Side Request Forgery). Why it applies: Esamina la minaccia per ogni funzione del server che recupera un URL influenzato dall'utente. Applica liste di destinazione consentite, limiti di uscita dalla rete e controlli dopo la risoluzione del nome. Classification boundary: Un prefisso di testo, una sola ricerca DNS o il parsing di URL da soli non sono sufficienti. I reindirizzamenti e il DNS rebinding possono superare il confine controllato. Safety requirements: Test only in an isolated space with explicit permission. Use inert, harmless inputs. Protect secrets and personal data. Name the trust boundary and record the mitigation. Operational safeguards: Set up detection and logs that hide sensitive data. Name the incident owner. Define a safe failure mode and rollback before release. Acceptance criteria: A defensive regression test fails before the mitigation and passes after it. No real target, secret, or personal data is used. Monitoring and rollback are verified. Evidence and limits (evidence boundary): È ufficiale per quella fonte. Altre piattaforme o team potrebbero usare il termine in modo diverso. Unknowns to confirm: Authorized scope, affected assets, data class, threat actor, incident owner, and rollback limits.
Controlla questa richiesta
Review how Server-Side Request Forgery (Server-Side Request Forgery) is used now. Definition: Il Server-Side Request Forgery, o SSRF, avviene quando un input controllato dall'attaccante spinge un server a inviare una richiesta. La richiesta raggiunge un luogo dove non dovrebbe arrivare. Release checks: Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.