Server-Side Request Forgery
Falsification de requête côté serveur
La falsification de requête côté serveur, ou SSRF, se produit lorsque des entrées contrôlées par un attaquant font qu'un serveur envoie une requête. La requête atteint un endroit qu'elle ne devrait pas atteindre.
Un autre exemple
Un outil de facturation accepte une URL de logo fournisseur. Il analyse une seule fois, autorise seulement les hôtes HTTPS des fournisseurs approuvés, et rejette les adresses privées résolues, de boucle locale, link-local ou de métadonnées. Il désactive également les redirections, limite les octets et le temps, utilise un proxy de sortie, et bloque `http://169.254.169.254`.
Parties principales
- 01URL influencée par un attaquant
- 02Capacité de récupération côté serveur
- 03Contrôles de destination et d'exportation
Utilisez-le lorsque
Passez en revue la menace pour chaque fonctionnalité de serveur qui récupère une URL influencée par l'utilisateur. Appliquez des listes d'autorisation de destination, des limites de sortie réseau et des vérifications après la résolution de nom.
Ne l'utilisez pas lorsque
Un préfixe de texte, une seule recherche DNS ou l'analyse d'URL seule ne suffisent pas. Les redirections et le rebinding DNS peuvent franchir la frontière vérifiée.
Nom utilisé dans le code
strict URL parser + destination allowlist + IP-range checks + redirect policy + egress proxy Avant d'expédier
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 Falsification de requête côté serveur (Server-Side Request Forgery). User context: Un outil de facturation accepte une URL de logo fournisseur. Il analyse une seule fois, autorise seulement les hôtes HTTPS des fournisseurs approuvés, et rejette les adresses privées résolues, de boucle locale, link-local ou de métadonnées. Il désactive également les redirections, limite les octets et le temps, utilise un proxy de sortie, et bloque `http://169.254.169.254`. Risk or control to address: Falsification de requête côté serveur (Server-Side Request Forgery). Why it applies: Passez en revue la menace pour chaque fonctionnalité de serveur qui récupère une URL influencée par l'utilisateur. Appliquez des listes d'autorisation de destination, des limites de sortie réseau et des vérifications après la résolution de nom. Classification boundary: Un préfixe de texte, une seule recherche DNS ou l'analyse d'URL seule ne suffisent pas. Les redirections et le rebinding DNS peuvent franchir la frontière vérifiée. 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): C'est officiel pour cette source. D'autres plateformes ou équipes peuvent utiliser le terme d'une autre manière. Unknowns to confirm: Authorized scope, affected assets, data class, threat actor, incident owner, and rollback limits.
Vérifiez cette demande
Review how Falsification de requête côté serveur (Server-Side Request Forgery) is used now. Definition: La falsification de requête côté serveur, ou SSRF, se produit lorsque des entrées contrôlées par un attaquant font qu'un serveur envoie une requête. La requête atteint un endroit qu'elle ne devrait pas atteindre. 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.