Habituellement serveurs Web donnent aux développeurs la possibilité d'ajouter des petits morceaux de code dynamique à l'intérieur des pages HTML statiques, sans avoir à utiliser de véritables langues côté serveur ou côté client. Cette fonctionnalité est incarnée par le Server-Side Includes (SSI). Dans un test d'injection SSI, nous testons si il est possible d'injecter des données qui seront interprétées par des mécanismes de SSI dans l'application . Une exploitation réussie de cette vulnérabilité permet à un attaquant d'injecter du code dans des pages HTML ou même d'exécuter du code à distance.

Les «Server-Side Includes » sont des directives que le serveur Web analyse avant de servir à la page de l'utilisateur. Elles représentent une alternative à l'écriture de programmes de CGI ou l'insertion de code en utilisant les langages de script côté serveur, quand il y a seulement besoin d'effectuer des tâches très simples. Les implémentations communes fournissent des commandes SSI pour inclure des fichiers externes, définir et imprimer des variables du serveur Web d'environnement CGI et pour exécuter des scripts CGI ou des commandes du système.

Mettre une directive SSI dans un document HTML statique est aussi facile que d'écrire un bout de code comme ce qui suit:

• Pour imprimer l'heure actuelle

<nowiki><!--#echo var="DATE_LOCAL" --></nowiki>

• pour inclure la sortie d'un script CGI.

<nowiki><!--#include virtual="/cgi-bin/counter.pl" --></nowiki>

• pour inclure le contenu d'un fichier.

<nowiki><!--#include virtual="/footer.html" --></nowiki>

• Pour inclure la sortie d'une commande système.

<nowiki><!--#exec cmd="ls" --></nowiki>

Ensuite, si le support du serveur web SSI est activé, le serveur va analyser ces directives. Dans la configuration par défaut, généralement, la plupart des serveurs web ne permettent pas l'utilisation de la directive exec pour exécuter des commandes système.

Comme dans toutes les situations de validation des entrées incorrectes, des problèmes surgissent lorsque l'utilisateur d'une application web est autorisé à fournir des données qui vont faire que l'application ou le serveur Web se comporteront de manière imprévisible. En ce qui concerne l'injection SSI, elle se produit lorsqu'un attaquant peut fournir une entrée qui, si elle est insérée par l'application (ou peut-être directement par le serveur) dans une page générée dynamiquement, serait analysé comme une ou plusieurs directives SSI.

Il s'agit d'une vulnérabilité très similaire à une vulnérabilité de script classique d'injection de la langue. Une atténuation est que le serveur Web doit être configuré pour permettre SSI. D'autre part, les vulnérabilités d'injection de SSI sont souvent plus simples à exploiter, car les directives SSI sont faciles à comprendre et, en même temps, assez puissant, par exemple, ils peuvent émettre le contenu des fichiers et exécuter des commandes système.

La première chose à faire lors d'un test boîte noire est de trouver si le serveur web supporte effectivement les directives SSI. Souvent, la réponse est oui, car le soutien SSI est assez fréquent. Pour le savoir il suffit de découvrir quel type de serveur Web s'exécute sur notre cible, en utilisant les techniques classiques de collecte d'information.

Que nous réussissions ou non à découvrir de cette information, on peut deviner si SSI est pris en charge juste en regardant le contenu du site Web cible. Si il contient. Shtml, les directives SSI sontt probablement prises en charge, car cette extension est utilisée pour identifier les pages qui contiennent ces directives. Malheureusement, l'utilisation de l'extension shtml n'est pas obligatoire, et ne pas avoir trouvé de fichier shtml ne signifie pas nécessairement que la cible n'est pas sujette à des attaques par injection SSI.

La prochaine étape consiste à déterminer si une attaque par injection de SSI est effectivement possible et, si oui, quels sont les points d'entrée que l'on peut utiliser pour injecter notre code malveillant.

Pour ce faire les tests sont exactement les même que ceux utilisés pour tester d'autres vulnérabilités d'injection de code. En particulier, nous devons trouver chaque page où l'utilisateur est autorisé à soumettre une entrée et vérifier si l'application valide correctement l'entrée soumise. Si la désinfection est insuffisante, nous devons vérifier si nous pouvons fournir des données qui va être affichée sans modification (par exemple, un message d'erreur ou un post sur le forum). En plus des données fournies par l'utilisateur, les vecteurs d'entrée comme des en-têtes de requête HTTP et le contenu des cookies devraient toujours être considérés, car ils peuvent être facilement falsifiables.

Une fois que nous avons une liste de points d'injection possibles, on peut vérifier si l'entrée est correctement validée, puis déterminer où l'entrée fournie est stockée. Nous devons nous assurer que nous pouvons injecter des caractères utilisés dans les directives SSI:

< ! # = / . " - > and [a-zA-Z0-9]

Pour tester si la validation est insuffisante, nous pouvons entree, par exemple, une chaîne comme celle-ci dans un formulaire :

<nowiki><!--#include virtual="/etc/passwd" --></nowiki>

Ceci est similaire à un test de vulnérabilités XSS en utilisant

<nowiki><script>alert("XSS")</script></nowiki>

Si l'application est vulnérable, la directive est injectée et sera interprétée par le serveur la prochaine fois que la page est servie, ce qui comprend le contenu du fichier de mot de passe standard Unix.

L'injection peut être réalisée aussi dans les en-têtes HTTP, si l'application Web utilise ces données pour créer une page générée dynamiquement:

GET / HTTP/1.0
Referer: 
User-Agent: 

Si nous avons accès au code source de l'application, on peut très facilement savoir:

• Si les directives SSI sont utilisées. Si elles le sont, alors le serveur web va avoir le support SSI activé, faisant de l'injection SSI un problème potentiel pour enquêter.
• Où la saisie de l'utilisateur, le contenu des cookies et les en-têtes HTTP sont traités. La liste complète des vecteurs d'entrée est ensuite rapidement déterminée.
• Comment est gérée l'entrée, le type de filtrage effectué, quels sont les caractères de l'application qui sont filtrés, et combien de types d'encodage sont pris en compte.

La réalisation de ces étapes s'appuie surtout une utilisation de grep pour trouver les bons mots clés à l'intérieur du code source (directives SSI, variables d'environnement CGI, affectation des variables impliquant une entrée de l'utilisateur, fonctions de filtrage et ainsi de suite).

• Apache Tutorial: “Introduction to Server Side Includes” - http://httpd.apache.org/docs/1.3/howto/ssi.html
• Apache: “Module modinclude” - http://httpd.apache.org/docs/1.3/mod/mod_include.html * Apache: “Security Tips for Server Configuration” - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi * Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt * SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html ## Outils ## * Web Proxy Burp Suite - http://portswigger.net * Paros - http://www.parosproxy.org/index.shtml * WebScarab * String searcher: grep - http://www.gnu.org/software/grep , * votre éditeur de texte favori