Attaques par injection SSI et comment les éviter
L'injection SSI (Server-side Include) est un exploit côté serveur qui permet à un attaquant d'injecter du code dans une application/un serveur Web et de l'exécuter lors du prochain chargement de la page, localement, par le serveur Web. Comme c'est si souvent le cas avec attaques par injection , sans validation appropriée des entrées de l'utilisateur, le serveur exécutera le code malveillant le moment venu et l'attaque réussira.
Cet article examine ce que sont les attaques par injection SSI, comment elles fonctionnent et ce que vous pouvez faire pour les éviter.
Que sont les inclusions côté serveur (SSI) ?
Les SSI sont des directives trouvées dans le code HTML d'une application Web et sont utilisées pour fournir une page HTML avec un contenu dynamique. Prenons, par exemple, une application Web contenant plusieurs pages, chacune nécessitant un en-tête ou un pied de page différent. Plutôt que de coder manuellement chacun d’eux, on peut inclure des SSI dans le HTML pour injecter dynamiquement le contenu requis dans chaque page.
Les SSI sont similaires aux Common Gateway Interfaces (CGI) dans la mesure où ils permettent l'échange de données standardisées entre des applications et des serveurs externes. Cependant, les SSI sont utilisés pour exécuter certaines actions avant le chargement de la page en cours ou pendant sa visualisation. Le serveur Web analyse le code HTML à la recherche des directives SSI et les exécute en séquence avant d'afficher la page à l'utilisateur.
SSI a une syntaxe simple : |_+_|. Les directives sont généralement placées dans les commentaires HTML de sorte que, à moins que SSI ne soit activé sur le serveur, les utilisateurs ne voient pas les directives SSI sur la page sans consulter leur source.
Exemples d'injections SSI
Vous trouverez ci-dessous quelques exemples simples de SSI. Les SSI utilisent tous les directives « # ».
Afficher l'en-tête approprié sur une page spécifique
|_+_|
Afficher la date sur une page spécifique
|_+_|
Les directives SSI peuvent exécuter des commandes shell et accéder, modifier, ajouter ou supprimer des fichiers sur le serveur. Comme vous l’avez peut-être deviné, c’est là que le plaisir commence…
Qu’est-ce que l’injection SSI ?
L'injection SSI exploite l'incapacité d'une application Web à nettoyer les entrées fournies par l'utilisateur avant d'insérer les données dans un fichier HTML côté serveur (pensez à un formulaire Web ou à une page de connexion). Une application Web vulnérable exécutera l’entrée fournie par l’utilisateur et affichera le résultat sur la page en question lors de son prochain chargement. En cas d'entrée malveillante, le serveur Web pourrait exécuter des commandes ssh au nom de l'attaquant, ce qui pourrait amener le serveur à afficher des fichiers extrêmement sensibles, comme /etc/passwd, parmi de nombreux autres résultats indésirables.
Des exemples de ce qui précède seraient :
- |_+_|
- |_+_|
Comment fonctionne l’injection SSI ?
La première étape pour le(s) attaquant(s) sera de déterminer si une application web est vulnérable en vérifiant si les caractères/opérateurs utilisés dans SSI sont correctement validés. Ce sont : |_+_|. L'étape suivante consistera à vérifier si le serveur héberge des pages avec le .stm, .shtm ou .shtml. Bien qu'il soit tout à fait possible (et recommandé, en fait) de prendre en charge SSI sans recourir à ces pages, il y a de fortes chances que le serveur prenne en charge SSI s'ils sont présents.
Une fois que l’attaquant a déterminé que l’application Web est vulnérable, il peut passer à l’attaque, qui est l’une des attaques les plus simples que j’ai documentées.
L’attaquant pourrait commencer par injecter des commandes SSI inoffensives pour s’assurer que tout fonctionne correctement. Ils pourraient envoyer la commande suivante :
|_+_|
Si le serveur répond avec l'heure et la date locales, l'attaquant sait désormais que le serveur est exploitable et peut commencer à envoyer des commandes SSI malveillantes au serveur. Des exemples de telles commandes sont :
Lister les fichiers et répertoires sous Linux
|_+_|
Accéder aux répertoires racine sous Linux
|_+_|
Téléchargez et exécutez un script malveillant
|_+_|
Répertorier les fichiers dans les répertoires sous Windows
|_+_|
Afficher le nom de fichier du document actuel
|_+_|
Afficher le chemin et le nom du fichier du document actuel
|_+_|
Modifier le format de sortie de la date et de l'heure
|_+_|
Afficher la taille d'un fichier
|_+_|
Gardez à l’esprit qu’aucune des commandes ci-dessus n’est malveillante en soi. Ils sont malveillants lorsqu’ils sont introduits par de mauvais acteurs. Votre administrateur système pourrait utiliser n’importe lequel d’entre eux au profit de l’organisation.
Risques de l’injection SSI
L'injection SSI étant une attaque si simple et relativement facile à réaliser (si le serveur est vulnérable), elle peut avoir des conséquences désastreuses. En fonction de ce qui est stocké sur votre serveur Web, une attaque par injection SSI réussie peut conduire à tout, depuis un accès non autorisé aux ressources jusqu'aux téléchargements/téléchargements/modifications/corruption de fichiers. Les attaques par injection SSI peuvent également conduire à des attaques par déni de service et même à une prise de contrôle complète du serveur si l'attaquant est en mesure d'accéder aux informations d'identification de l'administrateur.
Cependant, même si l’attaque pourrait être dévastatrice, les inclusions côté serveur sont aujourd’hui rarement utilisées dans le développement Web. Les développeurs Web d’aujourd’hui ont tendance à s’appuyer sur d’autres moyens techniques pour incorporer du contenu dynamique dans leurs pages Web. Des éléments tels que JavaScript et AJAX sont aujourd'hui plus couramment utilisés pour le contenu dynamique sans ouvrir la porte aux attaques par injection SSI.
Pourtant, même si le SSI est beaucoup moins répandu aujourd’hui que dans les années 1990, vous pourrez néanmoins trouver certains sites qui utilisent le SSI. Il est donc bon d’avoir une compréhension de base du SSI (et des attaques par injection SSI), ne serait-ce que pour se rappeler d’éviter de l’utiliser.
Comment se défendre contre les attaques par injection SSI ?
N'utilisez pas SSI
La première et la meilleure façon d’éviter les attaques par injection SSI est tout simplement de ne pas utiliser d’inclusions côté serveur lorsque vous créez un site Web. Le paragraphe ci-dessus mentionne qu'il est possible de charger du contenu dynamique dans des pages Web en utilisant d'autres moyens, tels que Javascript et AJAX. Ces alternatives doivent avoir la priorité sur SSI.
Ne mélangez pas les entrées utilisateur et les pages SSI
Si vous devez utiliser SSI, vous devez éviter d'incorporer des données contrôlables par l'utilisateur dans les pages traitées pour les directives SSI. Cela réduira au moins les chances de réussite d’une attaque SSI.
Évitez d'utiliser les pages .stm, .shtm et .shtml
Il est possible de configurer SSI pour les pages .htm, .html. Bien qu'il s'agisse du « standard », nous pouvons intégrer SSI dans notre site sans utiliser de pages avec les extensions .stm, .shtm et .shtml. Ces pages permettent à un attaquant de déterminer plus facilement que le serveur est vulnérable à l'injection SSI.
Valider la saisie de l'utilisateur
Vous avez donc décidé que vous avez toujours besoin de SSI mais que vous n’utiliserez pas de pages .stm, .shtm ou .shtml. Bien. Mais vous n’avez pas encore fini. Vous devez toujours gérer le fait que vous autorisez la saisie des utilisateurs sur votre site. La règle d’or concernant la saisie de l’utilisateur est… ne lui faites pas confiance ; validez-le. Peu importe de quel type d’utilisateur il s’agit (authentifié, interne ou public) ; vous devez toujours considérer cette entrée comme non fiable. Vous souhaitez valider toutes les entrées utilisateur par rapport à une liste de chaînes ou de caractères autorisés. Et n'oubliez pas de toujours valider les entrées utilisateur côté serveur même si l'entrée a déjà été validée côté client. Si, par exemple, votre site propose un formulaire permettant aux utilisateurs de se connecter, ce champ ne doit accepter que les caractères présents dans un nom d'utilisateur et rien d'autre.
Conclure
Voilà donc en un mot l’injection SSI. C’est une attaque assez simple, mais elle peut avoir d’énormes conséquences. Heureusement, les attaques ne sont plus aussi courantes qu’elles l’étaient autrefois, car nous disposons désormais d’autres moyens de développer les fonctionnalités fournies par les SSI en utilisant d’autres moyens.
Mais si vous devez utiliser des SSI, nous espérons que les conseils ci-dessus vous aideront à sécuriser votre site/application Web et à éviter les attaques par injection SSI.
Comme toujours, restez en sécurité (et nettoyez les commentaires de vos utilisateurs) !