Divulgation d'informations sensibles : messages d'erreur, versions et données exposées

La divulgation d'informations sensibles regroupe toutes les situations où une application révèle des données techniques, structurelles ou métier qui ne devraient pas être accessibles à un utilisateur non privilégié. Ces informations, prises individuellement, peuvent sembler anodines. Combinées, elles permettent à un attaquant de construire une reconnaissance précise avant de lancer une attaque ciblée.

Messages d'erreur détaillés

Les messages d'erreur verbeux révèlent la structure interne de l'application : stack traces, noms de fichiers, requêtes SQL, numéros de ligne. Une exception non gérée qui retourne la stack trace complète indique le langage, le framework, les dépendances et parfois les chemins absolus du système de fichiers. Une erreur SQL expose la structure de la base de données.

Gestion d'erreurs : production vs. développement

// Express.js : handler d'erreurs
app.use((err, req, res, next) => {
  // Log complet côté serveur uniquement
  console.error(err.stack);

  // Réponse générique côté client
  const isProd = process.env.NODE_ENV === 'production';
  res.status(err.status || 500).json({
    error: isProd ? 'Une erreur est survenue.' : err.message,
    ...(isProd ? {} : { stack: err.stack }),
  });
});

Numéros de version et empreintes logicielles

Les en-têtes HTTP révèlent fréquemment le serveur web, sa version et le framework utilisé. Server: Apache/2.4.49, X-Powered-By: Express, X-AspNet-Version: 4.0.30319 : ces informations permettent à un attaquant de cibler des CVEs connues pour cette version précise. La base de données Shodan indexe des millions de serveurs avec leurs empreintes.

Suppression des en-têtes révélateurs (nginx)

# nginx.conf
server_tokens off;  # Masque la version dans Server: et les pages d'erreur

# Supprimer X-Powered-By côté application (Node.js/Express) :
app.disable('x-powered-by');

# Ou via un middleware :
const helmet = require('helmet');
app.use(helmet());  // Inclut la suppression de X-Powered-By

Mode debug activé en production

Le mode debug active des fonctionnalités conçues pour le développement qui ne doivent jamais être accessibles en production. Django avec DEBUG=True expose une page d'erreur interactive avec les variables d'environnement, la configuration et la trace complète. PHP avec display_errors=On affiche les erreurs directement dans la page. Ces modes peuvent exposer des clés API, des chaînes de connexion à la base de données ou des secrets de configuration.

Données sensibles dans les cookies et les en-têtes

Certaines applications stockent des informations opérationnelles dans des cookies ou des en-têtes qui sont lisibles par l'utilisateur. Le cookie BIGipServer de F5 Load Balancer encode l'adresse IP et le port interne du serveur en base64. Les cookies de persistance de session peuvent révéler l'architecture interne. Ces informations facilitent les attaques contre l'infrastructure.

Exposition de données via les timestamps TCP

Les timestamps TCP permettent d'estimer la date de démarrage d'un système et sa durée de fonctionnement (uptime). Ces informations révèlent si un serveur a été récemment redémarré (et donc potentiellement patché) ou s'il tourne en continu depuis des mois sans mise à jour. C'est un vecteur de reconnaissance discret mais réel.

Exposition de données sensibles dans les logs

Les logs d'application contiennent parfois des mots de passe, des tokens ou des données personnelles. Cela se produit quand les paramètres de requête (dont certains peuvent contenir des mots de passe ou des tokens) sont loggés en entier, ou quand des objets contenant des données sensibles sont sérialisés dans les logs sans filtrage.

Filtrage des données sensibles dans les logs

// Ne jamais logger les paramètres bruts d'une requête d'authentification
// Mauvais :
logger.info('Login attempt', { body: req.body }); // contient le mot de passe

// Correct :
logger.info('Login attempt', { email: req.body.email }); // uniquement l'email

Récapitulatif

1. Messages d'erreur génériques en production : logs détaillés côté serveur uniquement
2. Masquer les empreintes logicielles : supprimer Server, X-Powered-By, X-AspNet-Version
3. Désactiver le mode debug en production : vérifier les variables d'environnement dans le pipeline de déploiement
4. Auditer les cookies et en-têtes : supprimer les informations opérationnelles et d'infrastructure
5. Filtrer les logs : ne jamais logger les mots de passe, tokens ou données personnelles brutes