Contactez-nous

Tester la configuration de la plateforme applicative

Comment tester la configuration de la plateforme d'application, y compris la recherche de fichiers par défaut, de code de débogage et l'examen des mécanismes de journalisation.

ID
WSTG-CONF-02

Résumé

Une configuration appropriée des éléments individuels qui composent une architecture d'application est importante afin de prévenir les erreurs qui pourraient compromettre la sécurité de l'ensemble de l'architecture.

L'examen et le test des configurations sont des tâches essentielles à la création et à la maintenance d'une architecture. En effet, divers systèmes sont souvent livrés avec des configurations génériques, qui peuvent ne pas s'aligner correctement sur les tâches qu'ils sont censés accomplir sur les sites spécifiques où ils sont installés.

Bien que l'installation typique d'un serveur web et d'un serveur d'application contienne de nombreuses fonctionnalités (comme des exemples d'applications, de la documentation, des pages de test), ce qui n'est pas essentiel doit être supprimé avant le déploiement afin d'éviter une exploitation post-installation.

Objectifs du test

  • S'assurer que les fichiers par défaut et connus ont été supprimés.
  • Valider qu'aucun code ou extension de débogage n'est laissé dans les environnements de production.
  • Examiner les mécanismes de journalisation mis en place pour l'application.

Comment tester

Tests en boîte noire

Fichiers et répertoires d'exemple et connus

Dans une installation par défaut, de nombreux serveurs web et serveurs d'applications fournissent des exemples d'applications et de fichiers pour le bénéfice du développeur, afin de tester si le serveur fonctionne correctement juste après l'installation. Cependant, de nombreuses applications de serveur web par défaut ont par la suite été reconnues comme vulnérables. Ce fut le cas, par exemple, pour CVE-1999-0449 (déni de service dans IIS lorsque le site d'exemple Exair avait été installé), CAN-2002-1744 (vulnérabilité de traversée de répertoire dans CodeBrws.asp dans Microsoft IIS 5.0), CAN-2002-1630 (utilisation de sendmail.jsp dans Oracle 9iAS), ou CAN-2003-1172 (traversée de répertoire dans l'exemple view-source dans Cocoon d'Apache).

Les scanners CGI, qui incluent une liste détaillée des exemples de fichiers et de répertoires connus fournis par différents serveurs web ou d'applications, peuvent être un moyen rapide de déterminer si ces fichiers sont présents. Cependant, la seule façon d'être vraiment sûr est de faire un examen complet du contenu du serveur web ou du serveur d'applications, et de déterminer s'ils sont liés à l'application elle-même ou non.

Revue des commentaires

Il est très courant pour les programmeurs d'ajouter des commentaires lors du développement de grandes applications web. Cependant, les commentaires inclus en ligne dans le code HTML peuvent révéler des informations internes qui ne devraient pas être accessibles à un attaquant. Parfois, une partie du code source est commentée lorsqu'une fonctionnalité n'est plus nécessaire, mais ce commentaire est involontairement divulgué dans les pages HTML renvoyées aux utilisateurs.

La revue des commentaires doit être effectuée afin de déterminer si des informations sont divulguées par le biais de commentaires. Cette revue ne peut être effectuée de manière approfondie que par une analyse du contenu statique et dynamique du serveur web, et par des recherches de fichiers. Il peut être utile de parcourir le site de manière automatique ou guidée, et de stocker tout le contenu récupéré. Ce contenu récupéré peut ensuite être recherché afin d'analyser les commentaires HTML disponibles dans le code.

Configuration du système

Divers outils, documents ou listes de contrôle peuvent être utilisés pour donner aux professionnels de l'informatique et de la sécurité une évaluation détaillée de la conformité des systèmes cibles à diverses bases de référence ou benchmarks de configuration. Ces outils incluent, mais ne sont pas limités à, ce qui suit :

Tests en boîte grise

Revue de la configuration

La configuration du serveur web ou du serveur d'application joue un rôle important dans la protection du contenu du site et doit être soigneusement examinée afin de repérer les erreurs de configuration courantes. Evidemment, la configuration recommandée varie en fonction de la politique du site et des fonctionnalités qui doivent être fournies par le logiciel du serveur. Dans la plupart des cas, cependant, les directives de configuration (fournies par le fournisseur du logiciel ou par des tiers) doivent être suivies pour déterminer si le serveur a été correctement sécurisé.

Il est impossible de dire génériquement comment un serveur doit être configuré, cependant, certaines directives communes doivent être prises en compte :

  • N'activez que les modules du serveur (extensions ISAPI dans le cas d'IIS) qui sont nécessaires à l'application. Cela réduit la surface d'attaque puisque le serveur est réduit en taille et en complexité à mesure que les modules logiciels sont désactivés. Cela empêche également les vulnérabilités qui pourraient apparaître dans le logiciel du fournisseur d'affecter le site si elles ne sont présentes que dans des modules qui ont déjà été désactivés.
  • Gérez les erreurs du serveur (40x ou 50x) avec des pages personnalisées au lieu des pages par défaut du serveur web. Assurez-vous en particulier que les erreurs d'application ne seront pas renvoyées à l'utilisateur final et qu'aucun code n'est divulgué par le biais de ces erreurs, car cela aidera un attaquant. Il est en fait très courant d'oublier ce point car les développeurs ont besoin de ces informations dans les environnements de pré-production.
  • Assurez-vous que le logiciel du serveur s'exécute avec des privilèges minimisés dans le système d'exploitation. Cela empêche une erreur dans le logiciel du serveur de compromettre directement l'ensemble du système, bien qu'un attaquant puisse élever les privilèges une fois qu'il exécute du code en tant que serveur web.
  • Assurez-vous que le logiciel du serveur enregistre correctement les accès légitimes et les erreurs.
  • Assurez-vous que le serveur est configuré pour gérer correctement les surcharges et prévenir les attaques par déni de service. Assurez-vous que le serveur a été correctement réglé en termes de performances.
  • N'accordez jamais aux identités non administratives (à l'exception de `NT SERVICE\WMSvc`) l'accès à applicationHost.config, redirection.config et administration.config (accès en lecture ou en écriture). Cela inclut `Network Service`, `IIS_IUSRS`, `IUSR` ou toute identité personnalisée utilisée par les pools d'applications IIS. Les processus de travail IIS ne sont pas censés accéder directement à l'un de ces fichiers.
  • Ne partagez jamais applicationHost.config, redirection.config et administration.config sur le réseau. Lorsque vous utilisez la configuration partagée, préférez exporter applicationHost.config vers un autre emplacement (voir la section intitulée "Définition des autorisations pour la configuration partagée).
  • Gardez à l'esprit que tous les utilisateurs peuvent lire les fichiers `machine.config` et `web.config` racine de .NET Framework par défaut. Ne stockez pas d'informations sensibles dans ces fichiers si elles ne doivent être vues que par les administrateurs.
  • Cryptez les informations sensibles qui ne doivent être lues que par les processus de travail IIS et non par les autres utilisateurs de la machine.
  • N'accordez pas d'accès en écriture à l'identité que le serveur Web utilise pour accéder au `applicationHost.config` partagé. Cette identité ne doit avoir qu'un accès en lecture.
  • Utilisez une identité distincte pour publier applicationHost.config sur le partage. N'utilisez pas cette identité pour configurer l'accès à la configuration partagée sur les serveurs Web.
  • Utilisez un mot de passe fort lors de l'exportation des clés de chiffrement à utiliser avec la configuration partagée.
  • Maintenez un accès restreint au partage contenant la configuration partagée et les clés de chiffrement. Si ce partage est compromis, un attaquant pourra lire et écrire n'importe quelle configuration IIS pour vos serveurs Web, rediriger le trafic de votre site vers des sources malveillantes et, dans certains cas, prendre le contrôle de tous les serveurs web en chargeant du code arbitraire dans les processus de travail IIS.
  • Envisagez de protéger ce partage avec des règles de pare-feu et des politiques IPsec pour autoriser uniquement les serveurs web membres à se connecter.

Journalisation

La journalisation est un atout important de la sécurité d'une architecture d'application, car elle peut être utilisée pour détecter les failles dans les applications (les utilisateurs essayant constamment de récupérer un fichier qui n'existe pas réellement) ainsi que les attaques soutenues d'utilisateurs malveillants. Les journaux sont généralement correctement générés par les logiciels de serveur web et autres. Il n'est pas courant de trouver des applications qui enregistrent correctement leurs actions dans un journal et, lorsqu'elles le font, l'intention principale des journaux d'application est de produire une sortie de débogage qui pourrait être utilisée par le programmeur pour analyser une erreur particulière.

Dans les deux cas (journaux du serveur et de l'application), plusieurs problèmes doivent être testés et analysés en fonction du contenu du journal :

  1. Les journaux contiennent-ils des informations sensibles ?
  2. Les journaux sont-ils stockés sur un serveur dédié ?
  3. L'utilisation des journaux peut-elle générer une condition de déni de service ?
  4. Comment sont-ils tournés ? Les journaux sont-ils conservés pendant une durée suffisante ?
  5. Comment les journaux sont-ils examinés ? Les administrateurs peuvent-ils utiliser ces examens pour détecter les attaques ciblées ?
  6. Comment les sauvegardes des journaux sont-elles conservées ?
  7. Les données en cours de journalisation sont-elles validées (longueur min/max, caractères, etc.) avant d'être journalisées ?

Informations sensibles dans les journaux

Certaines applications peuvent, par exemple, utiliser des requêtes GET pour transmettre des données de formulaire qui peuvent être vues dans les journaux du serveur. Cela signifie que les journaux du serveur peuvent contenir des informations sensibles (telles que les noms d'utilisateur et les mots de passe, ou les coordonnées bancaires). Ces informations sensibles peuvent être utilisées à mauvais escient par un attaquant s'il obtient les journaux, par exemple, via des interfaces administratives ou des vulnérabilités ou une mauvaise configuration connues du serveur web (comme la mauvaise configuration bien connue `server-status` dans les serveurs HTTP basés sur Apache).

Les journaux d'événements contiennent souvent des données utiles à un attaquant (fuite d'informations) ou qui peuvent être utilisées directement dans des exploits :

  • Informations de débogage
  • Traces de pile
  • Noms d'utilisateur
  • Noms des composants du système
  • Adresses IP internes
  • Données personnelles moins sensibles (par exemple, adresses e-mail, adresses postales et numéros de téléphone associés à des personnes nommées)
  • Données commerciales

De plus, dans certaines juridictions, le stockage de certaines informations sensibles dans les fichiers journaux, telles que les données personnelles, peut obliger l'entreprise à appliquer les lois sur la protection des données qu'elle appliquerait également à ses bases de données backend. Et le fait de ne pas le faire, même sans le savoir, peut entraîner des sanctions en vertu des lois sur la protection des données qui s'appliquent.

Une liste plus large d'informations sensibles est :

  • Code source de l'application
  • Valeurs d'identification de session
  • Jetons d'accès
  • Données personnelles sensibles et certaines formes d'informations personnelles identifiables (PII)
  • Mots de passe d'authentification
  • Chaînes de connexion à la base de données
  • Clés de chiffrement
  • Données de compte bancaire ou de titulaire de carte de paiement
  • Données d'une classification de sécurité supérieure à celle que le système de journalisation est autorisé à stocker
  • Informations commercialement sensibles
  • Informations qu'il est illégal de collecter dans la juridiction concernée
  • Informations qu'un utilisateur a choisi de ne pas collecter ou auxquelles il n'a pas consenti, par exemple l'utilisation de do not track, ou lorsque le consentement à la collecte a expiré

Emplacement des journaux

En règle générale, les serveurs génèrent des journaux locaux de leurs actions et erreurs, consommant le disque du système sur lequel le serveur s'exécute. Cependant, si le serveur est compromis, ses journaux peuvent être effacés par l'intrus pour nettoyer toutes les traces de son attaque et de ses méthodes. Si cela devait se produire, l'administrateur système n'aurait aucune connaissance de la façon dont l'attaque s'est produite ou de l'endroit où se trouvait la source de l'attaque. En fait, la plupart des kits d'outils d'attaque incluent un "nettoyeur de journaux" qui est capable de nettoyer tous les journaux qui contiennent des informations données (comme l'adresse IP de l'attaquant) et sont régulièrement utilisés dans les rootkits au niveau du système de l'attaquant.

Par conséquent, il est sage de conserver les journaux dans un emplacement séparé et non sur le serveur web lui-même. Cela facilite également l'agrégation des journaux provenant de différentes sources qui font référence à la même application (telles que celles d'une ferme de serveurs web) et cela facilite également l'analyse des journaux (qui peut être gourmande en CPU) sans affecter le serveur lui-même.

Stockage des journaux

Un stockage incorrect des journaux peut introduire une condition de déni de service. Tout attaquant disposant de ressources suffisantes pourrait être en mesure de produire un nombre suffisant de requêtes qui rempliraient l'espace alloué aux fichiers journaux, s'ils n'en sont pas spécifiquement empêchés. Cependant, si le serveur n'est pas correctement configuré, les fichiers journaux seront stockés dans la même partition de disque que celle utilisée pour le logiciel du système d'exploitation ou l'application elle-même. Cela signifie que si le disque est saturé, le système d'exploitation ou l'application peut échouer en raison de l'incapacité d'écrire sur le disque.

En règle générale, dans les systèmes UNIX, les journaux seront situés dans /var (bien que certaines installations de serveur puissent résider dans /opt ou /usr/local) et il est important de s'assurer que les répertoires dans lesquels les journaux sont stockés se trouvent dans une partition séparée. Dans certains cas, et afin d'éviter que les journaux système ne soient affectés, le répertoire de journaux du logiciel serveur lui-même (tel que /var/log/apache dans le serveur web Apache) doit être stocké dans une partition dédiée.

Cela ne veut pas dire que les journaux doivent être autorisés à croître pour remplir le système de fichiers dans lequel ils résident. La croissance des journaux du serveur doit être surveillée afin de détecter cette condition car elle peut être révélatrice d'une attaque.

Tester cette condition, qui peut être risquée dans les environnements de production, peut être fait en déclenchant un nombre suffisant et soutenu de requêtes pour voir si ces requêtes sont enregistrées et s'il est possible de remplir la partition de journalisation via ces requêtes. Dans certains environnements où les paramètres QUERY_STRING sont également enregistrés, qu'ils soient produits par des requêtes GET ou POST, de grandes requêtes peuvent être simulées qui rempliront les journaux plus rapidement car, généralement, une seule requête n'entraînera qu'une petite quantité de données à enregistrer, telles que la date et l'heure, l'adresse IP source, la requête URI et le résultat du serveur.

Rotation des journaux

La plupart des serveurs (mais peu d'applications personnalisées) effectueront une rotation des journaux afin de les empêcher de remplir le système de fichiers sur lequel ils résident. L'hypothèse lors de la rotation des journaux est que les informations qu'ils contiennent ne sont nécessaires que pendant une durée limitée.

Cette fonctionnalité doit être testée afin de s'assurer que :

  • Les journaux sont conservés pendant la durée définie dans la politique de sécurité, ni plus ni moins.
  • Les journaux sont compressés une fois tournés (c'est une commodité, car cela signifie que plus de journaux seront stockés pour le même espace disque disponible).
  • Les autorisations du système de fichiers pour les fichiers journaux tournés doivent être les mêmes (ou plus strictes) que celles des fichiers journaux eux-mêmes. Par exemple, les serveurs web devront écrire dans les journaux qu'ils utilisent, mais ils n'ont pas réellement besoin d'écrire dans les journaux tournés, ce qui signifie que les autorisations des fichiers peuvent être modifiées lors de la rotation pour empêcher le processus du serveur web de modifier ceux-ci.

Certains serveurs peuvent effectuer une rotation des journaux lorsqu'ils atteignent une taille donnée. Si cela se produit, il faut s'assurer qu'un attaquant ne peut pas forcer les journaux à tourner afin de masquer ses traces.

Contrôle d'accès aux journaux

Les informations du journal des événements ne doivent jamais être visibles pour les utilisateurs finaux. Même les administrateurs web ne devraient pas avoir accès à ces journaux car cela enfreint la séparation des contrôles de service. Assurez-vous que tout schéma de contrôle d'accès utilisé pour protéger l'accès aux journaux bruts, et toute application fournissant des fonctionnalités pour afficher ou rechercher les journaux ne sont pas liés aux schémas de contrôle d'accès pour les autres rôles d'utilisateur de l'application. Les données des journaux ne doivent pas non plus être visibles pour les utilisateurs non authentifiés.

Revue des journaux

L'examen des journaux peut être utilisé non seulement pour extraire des statistiques d'utilisation des fichiers dans les serveurs web (ce sur quoi la plupart des applications basées sur les journaux se concentrent), mais aussi pour déterminer si des attaques se produisent sur le serveur web.

Afin d'analyser les attaques de serveurs web, les fichiers journaux d'erreurs du serveur doivent être analysés. La revue doit se concentrer sur :

  • 40x (non trouvé) messages d'erreur. Un grand nombre de ceux-ci provenant de la même source peut être révélateur de l'utilisation d'un outil de scanner CGI contre le serveur web
  • 50x (erreur serveur) messages. Ceux-ci peuvent être une indication d'un attaquant abusant de parties de l'application qui échouent de manière inattendue. Par exemple, les premières phases d'une attaque par injection SQL produiront ces messages d'erreur lorsque la requête SQL n'est pas correctement construite et que son exécution échoue sur la base de données backend.

Les statistiques ou l'analyse des journaux ne doivent pas être générées ou stockées sur le même serveur qui produit les journaux. Sinon, un attaquant pourrait, par le biais d'une vulnérabilité du serveur web ou d'une mauvaise configuration, y accéder et récupérer des informations similaires à celles qui seraient divulguées par les fichiers journaux eux-mêmes.

Références

Apache

Lotus Domino

  • Lotus Security Handbook, William Tworek et al., avril 2004, disponible dans la collection IBM Redbooks
  • Lotus Domino Security, un livre blanc X-force, Internet Security Systems, décembre 2002
  • Hackproofing Lotus Domino Web Server, David Litchfield, octobre 2001

Microsoft IIS

  • Meilleures pratiques de sécurité pour IIS 8
  • CIS Microsoft IIS Benchmarks
  • Securing Your Web Server (Patterns and Practices), Microsoft Corporation, janvier 2004
  • IIS Security and Programming Countermeasures, par Jason Coombs
  • From Blueprint to Fortress: A Guide to Securing IIS 5.0, par John Davis, Microsoft Corporation, juin 2001
  • Secure IIS 5 Checklist, par Michael Howard, Microsoft Corporation, juin 2000

iPlanet de Red Hat (anciennement Netscape)

  • Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1, par James M Hayes, The Network Applications Team of the Systems and Network Attack Center (SNAC), NSA, janvier 2001

WebSphere

  • IBM WebSphere V5.0 Security, WebSphere Handbook Series, par Peter Kovari et al., IBM, décembre 2002.
  • IBM WebSphere V4.0 Advanced Edition Security, par Peter Kovari et al., IBM, mars 2002.

Générique