La complexité intrinsèque et l'hétérogénéité des infrastructures de serveur web interconnectées , qui peuvent compter des centaines d'applications Web, font de l'étude de la gestion du déploiement de chaque application de leur configuration une étape fondamentale dans les tests. En fait, il suffit d'une seule vulnérabilité pour saper la sécurité de l'ensemble de l'infrastructure, et même les petits et (presque) sans importance problèmes peuvent se transformer en de graves dangers pour une autre application sur le même serveur. Afin de remédier à ces problèmes, il est d'une importance capitale d'effectuer une révision en profondeur des questions de sécurité et de configuration connues.

La gestion correcte de la configuration de l'infrastructure serveur web est très importante afin de préserver la sécurité de l'application elle-même. Si des éléments tels que le logiciel de serveur Web, les serveurs de base de données back-end, ou les serveurs d'authentification ne sont pas correctement examinés et sécurisés, ils peuvent présenter des risques ou introduire de nouvelles vulnérabilités qui pourraient compromettre l'application elle-même.

Par exemple, un serveur web vulnérable qui permettrait à un attaquant distant de divulguer le code source de l'application elle-même (une vulnérabilité qui a été soulevée à de nombreuses reprises dans les deux serveurs Web ou serveurs d'applications) pourrait compromettre l'application, car des utilisateurs anonymes peuvent utiliser l'information divulguée dans le code source pour conduire des attaques contre l'application ou ses utilisateurs.

Afin de tester l'infrastructure de configuration, les étapes suivantes doivent être conduites:

Les différents éléments qui composent l'infrastructure doivent être déterminés afin de comprendre comment ils interagissent avec une application Web et comment ils affectent sa sécurité. Tous les éléments de l'infrastructure doivent être examinés afin de s'assurer qu'ils ne comportent pas de vulnérabilités connues. Un examen doit être fait des outils d'administration utilisés pour maintenir les différents éléments. Les systèmes d'authentification, le cas échéant, doivent être revus afin de s'assurer qu'ils répondent aux besoins de l'application et qu'ils ne peuvent pas être manipulés par les utilisateurs externes comme effet de levier. Une liste des ports définis qui sont nécessaires à l'application doivent être maintenues et gardées sous contrôle des changements.

L'étude de l'architecture doit être conduite lors des tests afin de déterminer quels composants sont utilisés pour créer l'application Web. Une petite installation, comme une simple application CGI, peut utiliser un serveur unique qui exécute un serveur Web qui exécute le C, Perl, Shell ou une application CGI , et peut-être aussi le mécanisme d'authentification. Sur les configurations plus complexes, comme un système de banque en ligne, plusieurs serveurs peuvent être impliqués, y compris: un reverse proxy, un serveur Web frontal, un serveur d'application et un serveur de base de données ou un serveur LDAP. Chacun de ces serveurs seront utilisés à des fins différentes et peuvent même être divisé en différents réseaux avec des dispositifs pare-feu entre ceux-ci, dans des DMZ différentes pour que l'accès au serveur web ne permette un accès à distance qu'à la méthode d'authentification elle-même, de sorte que les différents éléments de l'architecture soient isolés pour qu'un élément compromis ne compromettent pas l'ensemble de l'architecture.

Prendre connaissance de l'architecture de l'application peut être facilité si cette information est fournie à l'équipe de test par les développeurs d'applications sous forme de documents ou au moyen d'entrevues, mais peut aussi se révéler très difficile, voire aboutir sur un test de pénétration aveugle.

Dans ce dernier cas, le testeur doit d'abord commencer par l'hypothèse selon laquelle il existe une configuration simple (un seul serveur) et, à travers les informations récupérées à partir d'autres tests, calculer les différents éléments et remettre en question cette hypothèse pour prolonger l'architecture. Le testeur va commencer par poser des questions simples comme: «Y a t-il un système de pare-feu protégeant le serveur web“, auxquelles seront répondues sur la base des résultats des analyses de réseaux axés sur le serveur Web et l'analyse des réponses aux requêtes sur les ports du serveur (s'ils sont filtrés pas de réponse ou paquet ICMP unreachable reçu) ou si le serveur est directement connecté à l'Internet (ex renvoie paquets RST pour tous les ports non ouverts). Cette analyse peut être améliorée afin de déterminer le type de système de pare-feu utilisé basées sur des essais de paquets réseau: est-ce qu'un firewall stateful ou est-ce un filtre de liste d'accès sur un routeur? Comment est-il configuré? Peut-elle être contournée?

La détection d'un proxy inverse devant le serveur web peut être faite par l'analyse de la bannière du serveur web, qui peut directement communiquer l'existence d'un reverse proxy (par exemple, si «WebSEAL» ¹⁾ est retournée). Il peut également être déterminée en obtenant les réponses données par le serveur Web pour les demandes et en les comparant aux réponses attendues. Par exemple, certains proxys inverses agissent comme des «systèmes de prévention d'intrusion” (ou web-shields) en bloquant les attaques connues ciblées sur le serveur Web. Si le serveur Web est appelé à répondre par un message 404 à une demande qui vise une page disponible et renvoie un message d'erreur différent pour certaines attaques web courantes comme celles réalisées par les scanners CGI, cela pourrait être une indication d'un reverse proxy (ou un pare-feu au niveau applicatif) qui filtre des requêtes et renvoie une page d'erreur différente de celle attendue. Un autre exemple: si le serveur Web retournee un ensemble de méthodes HTTP disponibles (y compris TRACE), mais que ces méthodes retournent des erreurs alors il y a probablement quelque chose entre les deux, qui les bloquent. Dans certains cas, le système de protection lui-même se trahit:

GET /web-console/ServerInfo.jsp%00 HTTP/1.0
HTTP/1.0 200
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83
...
<TITLE>Error</TITLE>
 <BODY>
 <H1>Error</H1>
 FW-1 at XXXXXX: Access denied.</BODY>

Les Serveurs proxy inverses peuvent également être utilisés en tant que proxy-caches pour accélérer les performances des serveurs d'applications back-end. Détecter ces procurations peut être fait sur la base,de l'en-tête du serveur ou par l'analyse des demandes de synchronisation qui doivent être mise en mémoire par le serveur de cache en comparant le temps nécessaire à la première requête de serveur de demandes ultérieures.

Un autre élément qui peut être détecté: les équilibreurs de charge réseau. Typiquement, ces systèmes permettent d'équilibrer la charge TCP / IP d'un port donné sur plusieurs serveurs basés sur des algorithmes différents (round-robin, la charge du serveur web, le nombre de demandes, etc.) La détection de cet élément d'architecture doit être faite par l'examen des demandes multiples et comparer les résultats pour déterminer si les demandes vont vers des serveurs Web identiques ou différents. Par exemple, sur la base de la Date de l'en-tête: si les horloges des serveurs ne sont pas synchronisées. Dans certains cas, le processus d'équilibrage de charge réseau peut injecter de nouvelles informations dans les en-têtes qui le feront ressortir distinctement, comme le cookie AlteonP introduit par l'équilibreur de charge Nortel Alteon WebSystems.

Les serveurs d'applications Web sont généralement faciles à détecter. La demande de plusieurs ressources sont gérées par le serveur d'application lui-même (et non le serveur web) et l'en-tête de réponse varient considérablement (y compris les valeurs différentes ou supplémentaires dans l'en-tête de réponse). Une autre façon de détecter ceux-ci est de voir si le serveur Web tente de placer des cookies qui sont indicatifs de l'utilisation d'un serveur d'applications Web (comme le JSESSIONID fournies par certains serveurs J2EE), ou de réécrire des URL automatiquement afin de faire suivre la session.

Les Backends d'authentification (telles que les annuaires LDAP, bases de données relationnelles, des serveurs RADIUS) ne sont toutefois pas aussi facile à détecter d'une manière immédiate, car ils seront cachés par l'application elle-même.

L'utilisation d'une base de données principale peut être déterminée simplement en naviguant dans une application. S'il y a un contenu très dynamique généré “à la volée”, il est probablement extrait d'une sorte de base de données par l'application elle-même. Parfois, la façon dont l'information est demandée peut donner une idée sur l'existence d'une base de données back-end. Par exemple, une application d'achat en ligne qui utilise des identifiants numériques ('id') pour parcourir les différents articles de la boutique. Toutefois, lorsque vous faites un test aveugle, la connaissance de la base de données sous-jacente est habituellement disponible uniquement lorsque l'application présente des des vulnérabilités, tels que mauvaise gestion des exceptions ou de la sensibilité à l'injection SQL.

Les vulnérabilités serveurs trouvées dans les différents éléments qui composent l'architecture de l'application, que ce soit le serveur Web ou le backend de base de données, peut gravement compromettre l'application elle-même. Par exemple, considérons une vulnérabilité du serveur qui permette à un utilisateur à distance non authentifié d'envoyer des fichiers sur le serveur web, ou même de remplacer les fichiers. Cette vulnérabilité pourrait compromettre l'application, par un utilisateur non autorisé qui peut être en mesure de remplacer l'application elle-même ou d'introduire du code qui aurait une incidence sur les serveurs principaux.

Examiner les vulnérabilités de serveur peut être difficile à faire si le test doit être fait par le biais d'un test aveugle. Dans ces cas, les vulnérabilités doivent être testées à partir d'un site distant, généralement à l'aide d'un outil automatisé, mais le test de certaines vulnérabilités peuvent avoir des conséquences imprévisibles sur le serveur Web, et certains tests (comme ceux qui sont directement impliqués dans des attaques par déni de service ) pourrait ne pas être possible en raison de l'indisponibilité du service en cause si le test a réussi. En outre, certains outils automatisés signalent les vulnérabilités en fonction de la version du serveur Web récupérées. Cela conduit à des faux positifs et des faux négatifs: d'une part, si la version du serveur Web a été enlevée ou masquée par l'administrateur du site local, les outils d'analyse ne sauront pas marquer le serveur vulnérable, même s'il l'est, d'autre part, si le fournisseur du logiciel ne met pas à jour la version du serveur Web lorsque des vulnérabilités sont corrigées, l'outil d'analyse permettra de signaler les vulnérabilités qui n'existent pluss. Ce dernier cas est en fait très commun tant certains vendeurs de systèmes d'exploitation backport les patchs des failles de sécurité dans le logiciel qu'ils fournissent, mais ne font pas un chargement de la version du logiciel. Ce qui se passe dans la plupart des distributions GNU / Linux comme Debian, Red Hat ou SuSE. Dans la plupart des cas, l'analyse de vulnérabilité d'une architecture d'application ne trouvera que les vulnérabilités associées aux éléments exposés de l'architecture (comme le serveur web) et ne sera généralement pas en mesure de trouver des vulnérabilités associées à des éléments qui ne sont pas directement exposées, telles que l'authentification backend, les backends de bases de données ou des proxy inverse.

Enfin, tous les éditeurs de logiciels ne divulguent pas les vulnérabilités d'une manière publique, et par conséquent, ces faiblesses ne sont pas enregistrées dans les bases de données des vulnérabilités connues du public ²⁾). Ces informations ne sont communiquées qu'aux clients ou ne sont publiées que par le biais de correctifs qui n'ont pas de mises en garde qui les accompagnent. Cela réduit l'utilité des outils d'analyse de vulnérabilité. En général, la couverture des vulnérabilités par ces outils sera très bonne pour les produits communs (comme le serveur Web Apache, le serveur Microsoft Internet Information ou IBM Lotus Domino), mais pas pour des produits peu connus.

C'est pourquoi l'examen des vulnérabilités est meilleure quand le testeur dispose de données internes au logiciel utilisé, y compris les versions et correctifs appliqués et utilisés dans le logiciel. Avec cette information, le testeur peut récupérer les informations du fournisseur lui-même et analyser quelles vulnérabilités pourraient être présents dans l'architecture et la façon dont ils peuvent affecter l'application elle-même. Lorsque cela est possible, ces vulnérabilités peuvent être testés afin de déterminer leurs effets réels et de détecter si il pourrait y avoir des éléments extérieurs (tels que les systèmes de détection d'intrusion ou de prévention) qui pourraient réduire ou éliminer la possibilité d'une exploitation réussie. Les testeurs pourrait même déterminer, par un examen de la configuration, que la vulnérabilité n'est pas présente, car elle affecte un composant logiciel qui n'est pas en cours d'utilisation.

Il est également intéressant de noter que les vendeurs vont parfois corriger les vulnérabilités silencieusement et diffuser les correctifs disponibles avec les nouvelles versions logicielles. Différents fournisseurs auront des cycles de release différents qui déterminent la durée des supports qu'ils fournissent sur les versions plus anciennes. Un testeur avec des informations détaillées sur les versions des logiciels utilisés par l'architecture peut analyser le risque inhérent à l'utilisation d'anciennes versions de logiciels. Cela est essentiel, car si une vulnérabilité apparaît dans une ancienne version du logiciel qui n'est plus supportée, les hommes chargés de la maintenance ne seront pas directement informés. Aucun patch ne sera jamais mis à disposition pour cela et aucune mises en garde ne sera produite pour dire que la version est vulnérable (car elles n'est plus supportée). Même dans le cas où l'on a conscience que la vulnérabilité est présente et que le système est, de fait, vulnérable, il y aura besoin de faire une mise à niveau complète à une nouvelle version du logiciel, ce qui peut introduire des temps d'arrêt significatif dans l'architecture de l'application ou pourraient forcer à réécrire l'application en raison d'incompatibilités avec la dernière version du logiciel.

Toutes les infrastructures web requièrent l'existence d'outils d'administration pour maintenir et mettre à jour les informations utilisées par l'application: contenu statique (pages Web, fichiers graphiques), code source de l'application, bases de données d'authentification des utilisateurs, etc Selon le site, la technologie, ou les logiciels utilisés, les outils d'administration seront différents. Par exemple, certains serveurs Web seront gérés à l'aide des interfaces d'administration qui sont, eux-mêmes, des serveurs web (comme le serveur Web iPlanet) ou seront administrés par les fichiers textes de configuration (dans le cas d'Apache ³⁾) ou utiliseront des outils de système d'exploitation GUI (si vous utilisez Microsoft IIS ou serveur ASP.Net). Dans la plupart des cas, cependant, les configurations du serveur seront traitées à l'aide de différents outils de maintenance de fichiers utilisés par le serveur web, qui sont gérés par des serveurs FTP, WebDAV, systèmes de fichiers réseau (NFS, CIFS) ou d'autres mécanismes. De toute évidence, le système d'exploitation et les éléments qui composent l'architecture de l'application seront également gérées à l'aide d'autres outils. Les demandes peuvent également avoir des interfaces d'administration noyés dans la masse et qui sont utilisés pour gérer les données de l'application elle-même (utilisateurs, contenu, etc.)

L'examen des interfaces d'administration permettant de gérer les différentes parties de l'architecture est très important, car si un attaquant parvient à accéder à l'un d'eux, il peut alors compromettre ou nuire à l'architecture de l'application. Ainsi, il est important de:

• Lister toutes les interfaces possibles administratifs.
• Déterminer si les interfaces d'administration sont disponibles à partir d'un réseau interne ou sont également disponibles sur Internet.
• Si elles sont disponibles à partir d'Internet, de déterminer les mécanismes qui contrôlent l'accès à ces interfaces.
• Changer le mot de passe et nom d'utilisateur par défaut .

Certaines entreprises choisissent de ne pas gérer tous les aspects de leurs applications sur serveur Web, mais peuvent avoir d'autres parties qui gèrent le contenu fourni par l'application web. Cette société externe peut soit fournir une partie seulement du contenu (nouvelles mises à jour ) ou peut gérer le serveur web complètement (y compris le contenu et le code). Il est fréquent de trouver des interfaces d'administration disponibles à partir d'Internet dans ces situations, puisque l'utilisation d'Internet est moins cher que la fourniture d'une ligne dédiée qui permettra de relier l'entreprise extérieure à l'infrastructure de l'application pour un interface de gestion uniquement. Dans cette situation, il est très important de vérifier si les interfaces d'administration peuvent être vulnérables aux attaques.

<references/>