La configuration correcte des éléments simples qui composent une architecture d'application est importante afin d'éviter des erreurs qui pourraient compromettre la sécurité de l'ensemble de l'architecture.

L'étude et les tests de configuration sont des tâches essentielles dans la création et le maintien d'une architecture, de nombreux systèmes différents sont généralement fournis avec des configurations génériques qui pourraient ne pas être adaptés à la tâche qu'ils devront produire sur le site. L'installation web typique du serveur d'applications va produire un grand nombre de fonctionnalités (comme les exemples d'application, la documentation, lees pages de test) qui ne sont pas toutes essentielles et doivent donc être retirées avant le déploiement pour éviter l'exploitation post-installation.

De nombreux serveurs Web et serveurs d'applications fournissent dans les installations par défaut des applications de test et des fichiers qui sont fournis pour le bénéfice du développeur afin de vérifier que le serveur fonctionne correctement après l'installation. Cependant, de nombreuses applications Web fournies par défaut se révèlent été plus tard vulnérable. Ce fut le cas, par exemple, pour CVE-1999-0449 (Denial of Service dans IIS lorsque le site d'échantillonnage Exair avait été installé), CAN-2002-1744 (vulnérabilité directory traversal dans codebrws.asp dans Microsoft IIS 5.0), CAN -2002-1630 (utilisation de sendmail.jsp dans Oracle 9iAS), ou CAN-2003-1172 (directory traversal dans l'échantillon view-source Apache Cocoon en).

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

Il est très fréquent, et même recommandé, pour les programmeurs d'inclure des commentaires détaillés dans leur code source afin de permettre à d'autres programmeurs de mieux comprendre pourquoi telle décision a été prise pour le codage d'une fonction donnée. Les programmeurs en général le font aussi lors de l'élaboration de grandes applications Web. Cependant, les commentaires inclus dans le code HTML pourrait révéler une information à un attaquant potentiel qui ne devrait pas être mis à leur disposition. Parfois, même lorsqu'une fonctionnalité n'est plus nécessaire elle est commentée dans le code source, mais ce commentaire est anvoyé dans les pages HTML retournées aux utilisateurs sans qu'ils le veuillent..

Un examen des commentaire doit être effectué afin de déterminer si aucune information est passé à travers les commentaires. Cette examen ne peut être entièrement fait qu'à travers une analyse de contenu du serveur Web statiques et dynamiques, et la recherche de fichiers. Il peut être utile, toutefois, de naviguer sur le site, dans un mode automatique ou guidé et stocker tout le contenu récupéré. Ce contenu récupéré peut ensuite être utilisé afin d'analyser les commentaires HTML disponibles, le cas échéant, dans le code.

L'examen de la configuration du serveur web ou de celle du serveur d'applications joue un rôle important dans la protection du contenu du site et il doit être soigneusement conduites afin de repérer les erreurs de configuration courantes. De toute évidence, la configuration recommandée varie en fonction de la politique du site, et la fonctionnalité qui doit être fourni par le logiciel serveur. Dans la plupart des cas, cependant, les directives de configuration (fournies par le fournisseur du logiciel ou par des parties tierces) doivent être suivies afin de déterminer si le serveur a été correctement configuré. Il est impossible de dire de façon générique comment un serveur doit être configuré, cependant, quelques lignes directrices communes devraient être pris en compte:

Activez uniquement les modules de serveur (extensions ISAPI dans le cas IIS) qui sont nécessaires pour l'application. Cela permet de réduire la surface d'attaque sur le serveur en réduisant la taille et la complexité. Elle empêche également les vulnérabilités qui pourraient apparaître dans le logiciel du fournisseur et ainsi affecter le site s'ils ne sont présents que dans les modules qui ont été désactivés. Gérer les erreurs du serveur (40x ou 50x) avec des pages spécialement conçues au lieu des pages par défaut du serveur web. Plus précisément s'assurer que les erreurs d'application ne seront pas retournées à l'utilisateur final et qu'aucun code ne soit fournit à un attaquant par leur biais. Il est en fait très commun d'oublier ce point car les développeurs ont besoin de cette information dans les environnements de pré-production. Assurez-vous que le logiciel du serveur s'exécute avec des privilèges réduits au minimum dans le système d'exploitation. Ceci permet d'éviter qu'une erreur dans le logiciel serveur ne compromette directement l'ensemble du système, surtout si un attaquant peut élever ses privilèges lors de l'exécution de code sur le serveur Web. Assurez-vous que le logiciel du serveur loggue correctement à la fois les accès légitime et erreurs. Assurez-vous que le serveur est configuré pour traiter correctement les surcharges et prévenir les attaques par déni de service. Assurez-vous que la performance due serveur a été réglée correctement.

Le Logging est un atout important de la sécurité d'une architecture de l'application, car il peut être utilisé pour détecter des défauts dans les applications (les utilisateurs essaient constamment de récupérer un fichier qui n'existe pas réellement) ainsi que les attaques subies et de voir les utilisateurs malintentionnés. Les journaux sont généralement correctement générée par Web et autres logiciels serveur. Il n'est pas fréquent de trouver des applications qui enregistrent correctement leurs actions dans un journal et, quand ils le font, l'intention principale de l'application est de produire une sortie de débogage qui pourrait être utilisé par le programmeur pour analyser une erreur particulière.

Dans les deux cas (serveur et journaux d'application), plusieurs aspects devraient être testés et analysés en fonction du contenu du journal:

• Est-ce que les journaux contiennent des informations sensibles?
• Les journaux sont stockés dans un serveur dédié?
• Peut-on générer un déni de service par l'utilisation de la log?
• Comment sont géré leur cycle de vie? Sont ils conservés pendant le temps suffisant?
• Comment les journaux sont-ils examinés? Les administrateurs utilisent-ils ces journaux pour détecter les attaques ciblées?
• Comment sont conservés les sauvegardes du journal?
• Est ce que la forme des données enregistrées a été validée ( longueur min / max, etc ) avant qu'elles ne soient collectées?

Certaines applications peuvent, par exemple, utiliser les requêtes GET pour transmettre les données de formulaire qui seront visible dans les logs du serveur. Cela signifie que les journaux du serveur peuvent contenir des informations sensibles (telles que noms d'utilisateur des mots de passe ou coordonnées bancaires). Cette information sensible peut être détourné par un pirate si les journaux peuvent être obtenu, par exemple, par le biais des interfaces d'administration ou de vulnérabilités connuse du serveur Web ou d'une mauvaise configuration (comme la célèbre mauvaise configuration server-status des serveurs HTTP Apache).

En outre, dans certaines juridictions, le stockage des informations sensibles dans les fichiers journaux, comme les données personnelles, pourrait obliger l'entreprise à appliquer les lois de protection des données qu'ils appliquent à leurs bases de données back-end. Et ne pas le faire, même inconsciemment, peut entraîner des sanctions en vertu des lois de protection des données qui s'appliquent.

Les serveurs génèrent des journaux locaux de leurs actions et des erreurs, consommant de l'espace disque du système. Toutefois, si le serveur est compromis, ses journaux peuvent être anéantis par l'intrus pour nettoyer toutes les traces de ses attaques et méthodes. Si cela devait se produire les administrateurs système n'auront aucune connaissance de la façon dont l'attaque a eu lieu ou si la source de l'attaque a été localisée. En fait, la plupart des boîtes à outils d'attaque comprennent un outil qui est capable de nettoyer tous les journaux qui contiennent des informations données (comme l'adresse IP de l'attaquant) et sont couramment utilisées dans les rootkits.

Par conséquent, il est plus sage de conserver les journaux dans un endroit distinct et non dans le serveur web lui-même. Cela rend également plus facile d'agrégés les journaux provenant de différentes sources mais qui se réfèrent à la même application (tels que ceux d'une batterie de serveurs Web) et cela rend aussi plus facile l'analyse du journal (ce qui peut être coûteux en temps CPU) sans affecter le serveur lui-même.

Les journaux peuvent introduire un déni de service si ils ne sont pas correctement stockées. Évidemment, n'importe quel attaquant disposant de ressources suffisantes pourraient être en mesure, sauf s'il est détecté et bloqué, de produire un nombre suffisant de demandes qui remplissent l'espace alloué aux fichiers journaux. Toutefois, si le serveur n'est pas configuré correctement, les fichiers journaux sont stockés dans la partition de disque identique à celle utilisée pour le stockage des logiciels du système d'exploitation ou de l'application elle-même. Cela signifie que, si le disque devait être rempli, le système d'exploitation ou de l'application peut échouer, car il est incapable d'écrire sur le disque.

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

Cela ne veut pas dire que les journaux devraient être autorisés à grandir pour remplir le système de fichiers dans lequel ils résident, mais la croissance des journaux du serveur doivent être surveillée afin de détecter cela, car ça peut être le signe d'une attaque.

Ce test est aussi dangereux et aussi facile dans les environnements de production. Un nombre suffisant et durable de demandes doivent être enregistrées pour voir s'il y a une possibilité de remplir la partition journal à travers ces demandes . Dans certains environnements où les paramètres QUERY_STRING sont également enregistrées indépendamment du fait qu'ils sont produits par des requêtes GET ou POST, de grosses requêtes peuvent être simulées pour qu 'elles remplissent les journaux plus rapidement, généralement (une seule demande entraînera seulement une petite quantité de données à collecter: résultat date et l'heure, l'adresse IP source, demande d'URI, et le serveur).

La plus-part (en dehors de quelques applications personnalisées) font tourner les journaux afin de les empêcher de remplir le système de fichiers. L'hypothèse lors de la rotation des journaux est que l'information y est seulement nécessaire pour une quantité de temps limitée.

Cette fonction 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é, pas plus et pas moins.
• Les journaux sont compressés lors de la rotation (ce qui est une commodité, car cela signifie que plus de journaux pourront être stockés dans le même espace disque disponible)
• Les permissions du système de fichiers de rotation sont les mêmes (ou plus strictes) que celles du fichier journal lui-même. Par exemple, les serveurs Web ont besoin d'écrire dans les journaux qu'ils utilisent, mais ils n'ont pas vraiment besoin d'écrire dans les journaux issus de la rotation, ce qui signifie que les permissions des fichiers peuvent être modifiés lors de la rotation pour empêcher le serveur web, de modifier ceux-ci.

Certains serveurs peuvent faire tourner les journaux quand ils atteignent une taille donnée. Si cela se produit, il faut s'assurer que l'attaquant ne peut pas forcer les journaux pour les faire pivoter afin d'effacer ses traces.

L'étude des journaux peut être utilisée pour obtenir plus que des statistiques sur l'utilisation des fichiers sur les serveurs Web (ce qui est généralement la finalité de la plupart des journaux applicatifs), mais permet également de déterminer si les attaques ont lieu au niveau du serveur web. Afin d'analyser si le serveur web subit des attaques les fichiers journaux d'erreurs du serveur doivent être analysés. L'examen devrait se concentrer sur:

Les messages d'erreur 40x (non trouvé); une grande quantité de ces derniers en provenance de la même source pourrait être le signe d'un outil de scanner CGI utilisé sur le serveur Web Les messages 50x (erreur serveur) . Ceux-ci peuvent être une indication qu'un attaquant a tenter d'abuser l'application par des demandes qui échouent de manière inattendue. Par exemple, les premières phases d'une attaque par injection SQL vont produire ces messages d'erreur lorsque la requête SQL n'est pas correctement construite et son exécution échoue sur la base des données back-end.

Les statistiques du journal ou de l'analyse ne doivent pas être générées, ni stockées, dans le même serveur qui produit les journaux. Dans le cas contraire, 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 ainsi des informations comme il elles étaient divulguées par les fichiers journaux eux-mêmes.

• Apache
  • Apache Security, par Ivan Ristic, O'reilly, mars 2005.
  • Apache Security Secrets: Revealed (Encore une fois), Mark Cox, Novembre 2003 - http://www.awe.com/mark/apcon2003/
  • Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox, Octobre 2002 - http://www.awe.com/mark/apcon2002
  • Performance Tuning - http://httpd.apache.org/docs/misc/perf-tuning.html
• Lotus Domino
  • Lotus Security Handbook, William Tworek et al., Avril 2004, disponible dans la collection Redbooks IBM
  • Sécurité Lotus Domino, un X-force blanc-papier, Internet Security Systems, Décembre 2002
  • Hackproofing Lotus Domino Web Server, David Litchfield, Octobre 2001,
  • NGSSoftware Regard recherche sur la sécurité, disponible à http://www.nextgenss.com
• Microsoft IIS
  • IIS 6.0 Sécurité, par Rohyt Belani, Michael Muckin, -http://www.securityfocus.com/print/infocus/1765
  • Sécurisation de votre serveur Web (Patterns and Practices), Microsoft Corporation, Janvier 2004
  • Sécurité IIS et contre-programmation, par Jason Coombs
  • De Blueprint to Forteresse: Un guide pour la sécurisation IIS 5.0, par John Davis, Microsoft Corporation, Juin 2001
  • Sécurisés Internet Information Services 5 Liste de contrôle, de Michael Howard, Microsoft Corporation, Juin 2000
  • “INFO: utilisation de URLScan sur IIS» - http://support.microsoft.com/default.aspx?scid=307608 Red Hat (anciennement Netscape) iPlanet
• * Guide pour la configuration sécurisée et administration de iPlanet Web Server, Enterprise Edition 4.1, par James M Hayes, L'équipe du Réseau Applications des Systèmes et Réseau d'attaque Center (SNAC), la NSA, Janvier 2001
• WebSphere
  • IBM WebSphere V5.0 sécurité, WebSphere Handbook Series, par Peter Kovari et al., IBM, Décembre 2002.
  • IBM WebSphere Advanced Edition V4.0 de sécurité, par Peter Kovari et al., IBM, Mars 2002.