Le problème des applications web est qu’elles sont ouvertement exposées à des milliards d’internautes, dont beaucoup voudront enfreindre les mesures de sécurité, quelles qu’en soient les raisons.

Dans les premiers temps de l’internet, l’une des méthodes d’attaque les plus courantes était la simple force brute. Ces attaques étaient généralement effectuées par des robots – ou par des personnes disposant de beaucoup de temps libre – qui essayaient des milliards de combinaisons de noms d’utilisateur et de mots de passe jusqu’à ce qu’ils en trouvent une qui leur permette d’accéder à l’application ciblée.

Les attaques par force brute ne sont plus une menace, grâce aux politiques de mots de passe, aux tentatives de connexion limitées et aux captchas. Mais les cybercriminels adorent découvrir de nouveaux exploits et les utiliser pour réaliser de nouveaux types d’attaques. Il y a longtemps, ils ont découvert que les champs de texte des applications ou des pages web pouvaient être exploités en y entrant – ou en y injectant – un texte inattendu qui forcerait l’application à faire quelque chose qu’elle n’est pas censée faire. C’est ainsi que sont apparues les attaques par injection.

Les attaques par injection peuvent être utilisées non seulement pour se connecter à une application sans connaître le nom d’utilisateur et le mot de passe, mais aussi pour exposer des informations privées, confidentielles ou sensibles, voire pour détourner un serveur entier. C’est pourquoi ces attaques ne constituent pas seulement une menace pour les applications web, mais aussi pour les utilisateurs dont les données résident sur ces applications et, dans le pire des cas, pour d’autres applications et services connectés.

Injection de code

L’injection de code est l’un des types d’attaques par injection les plus courants. Si les attaquants connaissent le langage de programmation, le cadre, la base de données ou le système d’exploitation utilisés par une application web, ils peuvent injecter du code via des champs de saisie de texte pour forcer le serveur web à faire ce qu’ils veulent.

Ces types d’attaques par injection sont possibles sur les applications qui ne disposent pas d’une validation des données d’entrée. Si un champ de saisie de texte permet aux utilisateurs d’entrer ce qu’ils veulent, l’application est potentiellement exploitable. Pour prévenir ces attaques, l’application doit restreindre autant que possible les données que les utilisateurs sont autorisés à saisir.

Par exemple, elle doit limiter la quantité de données attendues, vérifier le format des données avant de les accepter et restreindre l’ensemble des caractères autorisés.

Les vulnérabilités liées à l’injection de code peuvent être faciles à trouver, simplement en testant l’entrée de texte d’une application web avec différents types de contenu. Une fois trouvées, les vulnérabilités sont modérément difficiles à exploiter. Mais lorsqu’un pirate parvient à exploiter l’une de ces vulnérabilités, l’impact peut être une perte de confidentialité, d’intégrité, de disponibilité ou de fonctionnalité de l’application.

Injection SQL

De manière similaire à l’injection de code, cette attaque insère un script SQL – le langage utilisé par la plupart des bases de données pour effectuer des opérations de requête – dans un champ de saisie de texte. Le script est envoyé à l’application, qui l’exécute directement sur sa base de données. Par conséquent, l’attaquant peut passer par un écran de connexion ou faire des choses plus dangereuses, comme lire des données sensibles directement à partir de la base de données, modifier ou détruire des données de la base de données, ou exécuter des opérations d’administration sur la base de données.

Les applications PHP et ASP sont sujettes aux attaques par injection SQL en raison de leurs interfaces fonctionnelles plus anciennes. Les applications J2EE et ASP.Net sont généralement mieux protégées contre ces attaques. Lorsqu’une vulnérabilité d’injection SQL est trouvée – et elles peuvent être facilement trouvées – l’ampleur des attaques potentielles ne sera limitée que par l’habileté et l’imagination de l’attaquant. L’impact d’une attaque par injection SQL est donc indubitablement élevé.

Injection de commandes

Ces attaques sont également possibles, principalement en raison d’une validation insuffisante des entrées. Elles diffèrent des attaques par injection de code dans la mesure où le pirate insère des commandes système au lieu de morceaux de code de programmation ou de scripts. Par conséquent, le pirate n’a pas besoin de connaître le langage de programmation sur lequel l’application est basée ou le langage utilisé par la base de données. En revanche, il doit connaître le système d’exploitation utilisé par le serveur d’hébergement.

Les commandes système insérées sont exécutées par le système d’exploitation hôte avec les privilèges de l’application, ce qui pourrait permettre d’exposer le contenu de fichiers arbitraires résidant sur le serveur, de montrer la structure des répertoires d’un serveur, de modifier les mots de passe des utilisateurs, entre autres choses.

Ces attaques peuvent être évitées par un administrateur système, en limitant le niveau d’accès au système des applications web fonctionnant sur un serveur.

Scripts intersites

Chaque fois qu’une application insère l’entrée d’un utilisateur dans la sortie qu’elle génère, sans la valider ou l’encoder, elle donne la possibilité à un attaquant d’envoyer un code malveillant à un autre utilisateur final. Les attaques par scripts intersites (XSS) profitent de ces opportunités pour injecter des scripts malveillants dans des sites web de confiance, qui sont finalement envoyés à d’autres utilisateurs de l’application, qui deviennent les victimes de l’attaquant.

Le navigateur de la victime exécutera le script malveillant sans savoir qu’il n’est pas digne de confiance. Par conséquent, le navigateur le laissera accéder aux jetons de session, aux cookies ou aux informations sensibles stockées par le navigateur. S’ils sont correctement programmés, les scripts peuvent même réécrire le contenu d’un fichier HTML.

Les attaques XSS peuvent généralement être divisées en deux catégories différentes : stockées et réfléchies.

Dans les attaques XSS stockées, le script malveillant réside en permanence sur le serveur cible, dans un forum de discussion, dans une base de données, dans le journal des visiteurs, etc. La victime l’obtient lorsque son navigateur demande les informations stockées. Dans les attaques XSS par réflexion, le script malveillant est reflété dans une réponse qui comprend l’entrée envoyée au serveur. Il peut s’agir d’un message d’erreur ou d’un résultat de recherche, par exemple.

Injection XPath

Ce type d’attaque est possible lorsqu’une application web utilise les informations fournies par un utilisateur pour construire une requête XPath pour des données XML. Le fonctionnement de cette attaque est similaire à celui de l’injection SQL: les attaquants envoient des informations mal formées à l’application afin de découvrir comment les données XML sont structurées, puis ils attaquent à nouveau pour accéder à ces données.

XPath est un langage standard avec lequel, comme SQL, vous pouvez spécifier les attributs que vous voulez trouver. Pour effectuer une requête sur des données XML, les applications web utilisent les données de l’utilisateur pour définir un modèle auquel les données doivent correspondre. En envoyant des données mal formées, le modèle peut se transformer en une opération que l’attaquant souhaite appliquer aux données.

Contrairement à ce qui se passe avec SQL, dans XPath, il n’y a pas de versions différentes. Cela signifie que l’injection XPath peut être effectuée sur n’importe quelle application web qui utilise des données XML, quelle que soit l’implémentation. Cela signifie également que l’attaque peut être automatisée ; par conséquent, contrairement à l’injection SQL, elle peut être lancée contre un nombre arbitraire d’objectifs.

Injection de commandes de courrier électronique

Cette méthode d’attaque peut être utilisée pour exploiter des serveurs de messagerie et des applications qui créent des instructions IMAP ou SMTP avec des entrées utilisateur mal validées. Parfois, les serveurs IMAP et SMTP ne disposent pas d’une protection solide contre les attaques, comme c’est le cas pour la plupart des serveurs web, et peuvent donc être plus facilement exploités. En entrant par un serveur de messagerie, les attaquants peuvent contourner des restrictions telles que les captchas, un nombre limité de requêtes, etc.

Pour exploiter un serveur SMTP, les attaquants ont besoin d’un compte de courrier électronique valide pour envoyer des messages contenant des commandes injectées. Si le serveur est vulnérable, il répondra aux demandes des attaquants, ce qui leur permettra, par exemple, de contourner les restrictions du serveur et d’utiliser ses services pour envoyer du spam.

L’injection IMAP pourrait être réalisée principalement sur des applications de webmail, en exploitant la fonctionnalité de lecture des messages. Dans ce cas, l’attaque peut être réalisée en entrant simplement, dans la barre d’adresse d’un navigateur web, une URL contenant les commandes injectées.

Injection de CRLF

L’insertion de caractères de retour de chariot et de saut de ligne (combinaison connue sous le nom de CRLF) dans les champs de saisie des formulaires web constitue une méthode d’attaque appelée injection de CRLF. Ces caractères invisibles indiquent la fin d’une ligne ou la fin d’une commande dans de nombreux protocoles Internet traditionnels, tels que HTTP, MIME ou NNTP.

Par exemple, l’insertion d’un CRLF dans une requête HTTP, suivie d’un certain code HTML, pourrait envoyer des pages web personnalisées aux visiteurs d’un site web.

Cette attaque peut être réalisée sur des applications web vulnérables qui n’appliquent pas le filtrage approprié à l’entrée de l’utilisateur. Cette vulnérabilité ouvre la porte à d’autres types d’attaques par injection, telles que XSS et l’injection de code, et pourrait également entraîner le détournement d’un site web.

Injection d’en-tête d’hôte

Dans les serveurs qui hébergent de nombreux sites ou applications web, l’en-tête hôte devient nécessaire pour déterminer lequel des sites ou applications web résidents – chacun d’entre eux étant connu sous le nom d’hôte virtuel – doit traiter une requête entrante. La valeur de l’en-tête indique au serveur à quel hôte virtuel envoyer la requête. Lorsque le serveur reçoit un en-tête d’hôte non valide, il le transmet généralement au premier hôte virtuel de la liste. Ceci constitue une vulnérabilité que les attaquants peuvent utiliser pour envoyer des en-têtes arbitraires au premier hôte virtuel d’un serveur.

La manipulation de l’en-tête d’hôte est généralement liée aux applications PHP, bien qu’elle puisse également être réalisée avec d’autres technologies de développement web. Les attaques par en-tête d’hôte servent de catalyseur à d’autres types d’attaques, telles que l’empoisonnement du cache web. Les conséquences peuvent être l’exécution d’opérations sensibles par les attaquants, par exemple la réinitialisation de mots de passe.

Injection LDAP

LDAP est un protocole conçu pour faciliter la recherche de ressources (appareils, fichiers, autres utilisateurs) dans un réseau. Il est très utile pour les intranets et, lorsqu’il est utilisé dans le cadre d’un système d’authentification unique, il peut servir à stocker les noms d’utilisateur et les mots de passe. Les requêtes LDAP impliquent l’utilisation de caractères de contrôle spéciaux qui affectent son contrôle. Les attaquants peuvent potentiellement modifier le comportement prévu d’une requête LDAP s’ils peuvent y insérer des caractères de contrôle.

Là encore, le problème fondamental qui permet les attaques par injection LDAP est la validation incorrecte des données de l’utilisateur. Si le texte qu’un utilisateur envoie à une application est utilisé dans le cadre d’une requête LDAP sans être nettoyé, la requête peut finir par récupérer une liste de tous les utilisateurs et la montrer à un attaquant, simplement en utilisant un astérisque (*) au bon endroit dans une chaîne d’entrée.

Prévention des attaques par injection

Comme nous l’avons vu dans cet article, toutes les attaques par injection sont dirigées vers des serveurs et des applications dont l’accès est ouvert à n’importe quel internaute. La responsabilité de prévenir ces attaques est répartie entre les développeurs d’applications et les administrateurs de serveurs.

Les développeurs d’applications doivent connaître les risques liés à une validation incorrecte des entrées utilisateur et apprendre les meilleures pratiques pour assainir les entrées utilisateur à des fins de prévention des risques. Les administrateurs de serveurs doivent auditer périodiquement leurs systèmes afin de détecter les vulnérabilités et de les corriger dès que possible. Il existe de nombreuses options pour réaliser ces audits, soit à la demande, soit automatiquement.