Un reverse proxy ou un CDN/WAF placé devant l'origin ajoute un second analyseur de requêtes et une table de routage, de sorte que la sécurité dépend désormais de l'accord entre le proxy et l'origin sur ce qu'est la requête et où elle va. Ces problèmes relèvent du rôle de proxy plutôt que d'un produit serveur précis, ce qui explique qu'ils figurent ici et non sous Apache/nginx/IIS (un bug de proxy propre à un produit, comme la variable proxy_pass de nginx, est traité sous son produit).
Ce qu'il faut vérifier#
- Désaccord de normalisation : l'edge et l'origin canonicalisent les chemins différemment, de sorte qu'un chemin forgé passe une règle d'autorisation/refus de l'edge mais se résout en une ressource protégée au niveau de l'origin.
- Exposition de l'origin : le backend est joignable directement, ce qui contourne entièrement le filtrage, les limites de débit et le contrôle d'accès du proxy.
- Confiance dans les en-têtes de l'edge : le proxy injecte ou transmet des en-têtes
X-Forwarded-*/Hostque l'origin considère ensuite comme faisant autorité.
Sujets liés, traités ailleurs#
- Le HTTP request smuggling (désynchronisation front/back sur les limites de requête) est traité dans Code > Injection > HTTP.
- Les conséquences côté application de la confiance accordée aux en-têtes transmis sont traitées dans Code > Access Control > confiance dans les en-têtes de proxy et Identification ; ici, l'accent porte sur le câblage de l'edge qui crée cette confiance.
Pages#
- Désaccord de normalisation : l'edge et l'origin ne s'accordent pas sur le chemin canonique, ce qui contourne le contrôle d'accès basé sur le chemin.
- Exposition de l'origin : atteindre le backend directement, au-delà du proxy, du WAF ou du CDN.
- Confiance dans les en-têtes de l'edge : comment le câblage du proxy rend des en-têtes
X-Forwarded-*/Hostforgés faisant autorité.
Références#
- PortSwigger Web Security Academy: Access control, SSRF, Web cache
- Orange Tsai: reverse-proxy path confusion research