La plateforme est le serveur web et la manière dont le service est hébergé et exposé : Apache, nginx, IIS ou un serveur d'application Java ; reverse proxies et CDN ; hôtes virtuels ; les règles qui mappent une URL vers un fichier ou un backend ; et les handlers qui décident si un fichier est servi, divulgué ou exécuté. Cette couche possède une classe de vulnérabilités distincte de la logique applicative (Code) et du moteur de langage (Runtime). Le test pour savoir si un bug appartient ici : existerait-il encore si le code source de l'application et le runtime du langage étaient inoffensifs, parce que la faiblesse réside dans la configuration du serveur, la topologie de déploiement, ou la façon dont le serveur résout et route les requêtes ?
Comment ce domaine est organisé#
La règle d'organisation de la bibliothèque consiste à diviser selon l'axe que vous identifiez en premier à une couche donnée, puis à affiner. Dans le Code applicatif, cet axe est la primitive dangereuse ; dans le Runtime, c'est la primitive puis le langage ou le moteur. À la couche plateforme, la chose que vous identifiez en premier est le produit : vous identifiez le serveur, puis déroulez la checklist de mauvaise configuration de ce produit. Ainsi, Plateforme est organisé par produit (Apache, nginx, IIS, Tomcat), ce qui est le même principe appliqué une couche plus loin, pas un écart par rapport à lui. Une unique section générale rassemble les expositions indépendantes du produit (un .git servi, listing de répertoire, sauvegardes, config divulguée) pour qu'elles ne soient pas répétées sous chaque produit, et une section reverse proxy et edge couvre le comportement qui relève du rôle de proxy plutôt que d'un produit en particulier.
Les primitives sous-jacentes traversent toujours chaque produit, donc chaque page est étiquetée avec sa primitive et le tableau ci-dessous offre une entrée orientée primitive, en plus de l'arbre orienté produit.
Par primitive (référence croisée)#
| Primitive | Où elle apparaît |
|---|---|
| Traversée de chemin / mappage | alias/rewrite Apache, off-by-slash alias nginx, normalisation de slash nginx, double décodage IIS, décalage de normalisation du proxy |
| Divulgation de source | handler Apache, MultiViews Apache, astuces NTFS IIS, VCS général, sauvegardes générales |
| Handler / upload vers exécution | handler Apache, FastCGI/PHP-FPM nginx, handlers IIS |
| SSRF / routage | proxy_pass variable nginx, proxy_pass et mauvais routage, exposition de l'origine |
| RCE de déploiement | Tomcat Manager, AJP/Ghostcat |
| Exposition d'information | général (endpoints de statut, VCS, sauvegardes, listing, config) |
| Confiance en-tête / identité | confiance des en-têtes edge |
Fingerprint d'abord#
Avant les checklists, identifiez le serveur : en-têtes Server/X-Powered-By, pages d'erreur par défaut, noms de cookies (JSESSIONID = Java, ASP.NET_SessionId = IIS), ordre et casse des en-têtes, hashs de favicon et comportement face à des requêtes malformées. Le fingerprint sélectionne la section.
Sections#
- Général : expositions sur n'importe quel serveur, endpoints de statut,
.git/VCS, sauvegardes, listing de répertoire, config divulguée. - Apache : mappage handler/type, traversée
Alias/mod_rewrite, négociation MultiViews. - nginx : off-by-slash d'
alias, câblage FastCGI/PHP-FPM, SSRF viaproxy_passvariable, normalisation de slash. - IIS : astuces de noms de fichiers NTFS, traversée double décodage/Unicode, handlers et
web.config. - Tomcat et Java : AJP/Ghostcat, déploiement Manager, traversée par paramètre de chemin.
- Reverse proxy et edge : décalage de normalisation edge/origine, exposition de l'origine, confiance des en-têtes edge.
Références#
- Documentation Apache httpd et nginx (références de configuration)
- PortSwigger Web Security Academy : Information disclosure, Access control, SSRF