Mauvaise configuration de serveur : en-têtes et fichiers exposés

Une application peut avoir un code irréprochable et pourtant se révéler fragile à cause de la manière dont elle est installée : un mode de débogage laissé actif, un dossier de sauvegarde accessible, un compte par défaut jamais désactivé. C’est comme une maison dotée d’une excellente serrure dont on aurait oublié de fermer la fenêtre du garage. Les erreurs de configuration comptent parmi les constats les plus fréquents en audit, et souvent les plus simples à corriger.

Ce que recouvre la « mauvaise configuration »

Une application web repose sur plusieurs couches : un système, un serveur web, un langage, un cadre de développement, une base de données, parfois un service cloud. Chaque couche a des réglages, et leurs valeurs par défaut sont souvent choisies pour faciliter l’installation, pas pour la sécurité. Un durcissement (hardening) consiste à les resserrer.

Examiner les en-têtes de réponse

Vous avez vu au chapitre 4 les en-têtes de sécurité qui protègent. Il faut aussi regarder ceux qui divulguent. Une réponse peut contenir :

HTTP/1.1 200 OK
Server: NomDuServeur/version-précise
X-Powered-By: NomDuLangage/version-précise
Set-Cookie: session=...

Ces mentions, anodines pour l’utilisateur, indiquent à un attaquant quelles failles connues viser (par exemple celles recensées sur cve.org ou nvd.nist.gov pour cette version précise). Un constat classique, de gravité généralement faible, est « divulgation de versions logicielles » : la correction consiste à masquer ces informations et à tenir les logiciels à jour, car masquer ne remplace pas corriger.

Les messages d’erreur et le mode débogage

Provoquez, avec une requête volontairement incorrecte sur votre application d’entraînement (un paramètre manquant, un chemin inexistant), une erreur, et lisez la réponse. Trois situations :

• Page d’erreur générique (« Une erreur est survenue ») : correct.
• Page d’erreur avec une trace complète : noms de fichiers, chemins du serveur, extrait de requêtes, parfois des identifiants : constat.
• Interface de débogage active d’un cadre de développement : constat sérieux, car elle peut offrir des fonctions d’exploration, voire d’exécution.

En production, le mode débogage doit être désactivé, et les détails consignés dans des journaux internes, jamais affichés à l’utilisateur.

Les fichiers et dossiers qui n’auraient pas dû être là

Un serveur sert tout ce qui se trouve dans le dossier public. Des fichiers laissés par inadvertance par les équipes sont une source classique de fuites :

• des sauvegardes (copies d’une page avec une extension supplémentaire, archives du site, exports de base de données) ;
• des fichiers de configuration contenant des identifiants de connexion à la base ;
• des fichiers de gestion de version du code source, oubliés dans le dossier public ;
• des fichiers de test ou de documentation interne (pages d’information sur la configuration du serveur, par exemple) ;
• des journaux accessibles par adresse.

Comment les découvrir ? Par la cartographie (chapitre 1), la lecture de la page d’exclusion destinée aux moteurs de recherche (qui, voulant cacher des chemins, les révèle parfois), et l’examen de l’arborescence connue d’un cadre de développement. Des outils dressent la liste des chemins courants à partir d’un dictionnaire : dans votre laboratoire, ils sont utiles ; sur un site réel, ils ne s’emploient qu’avec autorisation, avec un débit raisonnable.

Une règle à retenir : le dossier public ne contient que du public

La meilleure défense est architecturale : placer le code, la configuration et les secrets hors de la racine web, de sorte qu’une erreur de configuration du serveur ne les expose jamais. Seuls les fichiers destinés au public (pages, images, scripts, feuilles de style) résident dans le dossier servi.

Comptes et réglages par défaut

Beaucoup de logiciels sont livrés avec un compte administrateur initial, un mot de passe de démonstration, une console d’administration activée. Si l’installation ne les neutralise pas, la porte reste ouverte. Votre application d’entraînement en contient volontairement, avec la mention dans sa documentation : c’est instructif. En audit, on vérifie systématiquement que les identifiants par défaut ont été supprimés ou changés et que les consoles d’administration ne sont pas exposées publiquement.

Le chiffrement du transport

Examinez la configuration HTTPS : redirection automatique du HTTP vers HTTPS, certificat valide, absence de protocoles obsolètes, en-tête Strict-Transport-Security. Des outils dédiés évaluent la configuration TLS d’un serveur ; pour un serveur de laboratoire, vous pouvez les exécuter librement. Sur un site réel, la vérification d’un certificat par un navigateur reste sans risque, mais une analyse approfondie exige l’autorisation.

Défendre : le durcissement, une discipline

• Partir d’une configuration minimale : n’activer que ce dont l’application a besoin (modules, méthodes, ports).
• Désactiver le débogage et afficher des erreurs génériques en production.
• Masquer les bannières de version (utile, mais secondaire par rapport aux mises à jour).
• Supprimer ou changer tous les comptes, mots de passe et exemples par défaut.
• Séparer les environnements : développement, test et production sont distincts, avec des secrets différents.
• Automatiser la configuration (scripts, outils d’infrastructure) pour qu’elle soit reproductible et revue, plutôt que bricolée à la main.
• Appliquer le moindre privilège aux comptes de service, aux permissions de fichiers et aux droits cloud.
• Surveiller : alertes sur l’apparition de nouveaux fichiers dans les dossiers publics, balayage régulier de la configuration.

Des référentiels de configuration sécurisée sont publiés par les autorités ; le guide d’hygiène de l’ANSSI (cyber.gouv.fr) et les ressources de l’OWASP (owasp.org) sont de bons points de départ.

À vous de jouer

Sur votre application d’entraînement locale :

1. Relevez les en-têtes de réponse d’une page : y a-t-il des mentions de version ? Notez-les.
2. Provoquez une erreur (chemin inexistant ou paramètre invalide) et décrivez la page d’erreur : générique ou détaillée ?
3. Consultez la documentation de l’application : quels comptes ou réglages par défaut sont mentionnés ?
4. Rédigez deux constats (un sur la divulgation d’informations, un sur un autre point) et proposez des corrections.

La configuration n’est qu’un des aspects de l’hygiène d’une application : ce qu’elle embarque de code tiers en est un autre, tout aussi important. C’est la leçon suivante.