9 types d’attaques par injection d’applications Web populaires

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

Au début d’Internet, l’une des méthodes d’attaque les plus courantes était la force brute simple et basique. Les bots effectuaient généralement ces attaques – ou les personnes disposant de beaucoup de temps libre – qui essayaient des millions de combinaisons de noms d’utilisateur et de mots de passe jusqu’à ce qu’ils en trouvent une qui accorderait l’accès à l’application cible.

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 effectuer 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 saisissant – ou en y injectant – un texte inattendu qui obligerait l’application à faire quelque chose qu’elle n’était pas censée faire. C’est ainsi que les soi-disant attaques par injection sont entrées en scène.

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, ou même pour détourner un serveur entier. C’est pourquoi ces attaques ne constituent pas seulement une menace pour les applications Web, mais également 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 framework, la base de données ou le système d’exploitation utilisé 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 manquent de validation des données d’entrée. Si un champ de saisie de texte permet aux utilisateurs de saisir ce qu’ils veulent, alors l’application est potentiellement exploitable. Pour empêcher ces attaques, l’application doit restreindre autant que possible les entrées que les utilisateurs sont autorisés à entrer.

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

Les vulnérabilités d’injection de code peuvent être faciles à trouver, simplement en testant la saisie de texte d’une application Web avec différents types de contenu. Lorsqu’elles sont trouvées, les vulnérabilités sont modérément difficiles à exploiter. Mais lorsqu’un attaquant parvient à exploiter l’une de ces vulnérabilités, l’impact peut inclure la perte de confidentialité, d’intégrité, de disponibilité ou de fonctionnalité de l’application.

Injection SQL

De la même manière que 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 pourrait 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 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 découverte – et elle pourrait être facilement trouvée – l’ampleur des attaques potentielles ne sera limitée que par les compétences et l’imagination de l’attaquant. Ainsi, l’impact d’une attaque par injection SQL est sans aucun doute élevé.

Injection de commande

Ces attaques sont également possibles, principalement en raison d’une validation insuffisante des entrées. Elles diffèrent des attaques par injection de code en ce que l’attaquant 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 dans lequel l’application est basée ou le langage utilisé par la base de données. Mais ils doivent 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, d’afficher la structure de répertoires d’un serveur, de changer les mots de passe des utilisateurs, entre autres. .

Ces attaques peuvent être prévenues par un administrateur système, en limitant le niveau d’accès système des applications Web exécutées sur un serveur.

Script intersite

Chaque fois qu’une application insère une entrée d’un utilisateur dans la sortie qu’elle génère, sans la valider ni l’encoder, elle donne la possibilité à un attaquant d’envoyer un code malveillant à un autre utilisateur final. Les attaques Cross-Site Scripting (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 des victimes exécutera le script malveillant sans savoir qu’il ne faut pas lui faire confiance. Par conséquent, le navigateur lui permettra d’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 messagerie, dans une base de données, dans un journal des visiteurs, etc. La victime l’obtient lorsque son navigateur demande les informations stockées. Dans les attaques XSS réfléchies, le script malveillant est reflété dans une réponse qui inclut 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 des informations fournies par un utilisateur pour créer une requête XPath pour des données XML. Le fonctionnement de ces attaques est similaire à l’injection SQL : les attaquants envoient des informations malformé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 souhaitez rechercher. Pour effectuer une requête sur des données XML, les applications Web utilisent une entrée utilisateur pour définir un modèle auquel les données doivent correspondre. En envoyant une entrée malformée, 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, il a le potentiel d’être déclenché contre un nombre arbitraire d’objectifs.

Injection de commandes par courrier

Cette méthode d’attaque peut être utilisée pour exploiter les serveurs de messagerie et les applications qui créent des instructions IMAP ou SMTP avec une entrée utilisateur incorrectement validée. Parfois, les serveurs IMAP et SMTP ne disposent pas d’une protection solide contre les attaques, comme ce serait le cas avec la plupart des serveurs Web, et pourraient donc être plus exploitables. En entrant via un serveur de messagerie, les attaquants pourraient contourner les 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 messagerie valide pour envoyer des messages avec des commandes injectées. Si le serveur est vulnérable, il répondra aux demandes des attaquants, leur permettant, par exemple, de passer outre les restrictions du serveur et d’utiliser ses services pour envoyer du spam.

L’injection IMAP pourrait se faire principalement sur les applications de messagerie Web, en exploitant la fonctionnalité de lecture des messages. Dans ces cas, l’attaque peut être effectuée en entrant simplement, dans la barre d’adresse d’un navigateur Web, une URL avec les commandes injectées.

Injection CRLF

L’insertion de caractères de retour chariot et de saut de ligne – combinaison connue sous le nom de CRLF – dans les champs de saisie des formulaires Web représente une méthode d’attaque appelée injection 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 effectué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 découler du piratage d’un site Web.

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

Dans les serveurs qui hébergent de nombreux sites Web ou applications Web, l’en-tête de l’hôte devient nécessaire pour déterminer lequel des sites Web ou applications Web résidents – chacun d’entre eux connu sous le nom d’hôte virtuel – doit traiter une demande entrante. La valeur de l’en-tête indique au serveur auquel des hôtes virtuels envoyer une 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. Cela constitue une vulnérabilité que les attaquants peuvent utiliser pour envoyer des en-têtes d’hôte arbitraires au premier hôte virtuel d’un serveur.

La manipulation de l’en-tête de l’hôte est généralement liée aux applications PHP, bien qu’elle puisse également être effectuée avec d’autres technologies de développement Web. Les attaques d’en-tête d’hôte fonctionnent comme catalyseurs pour d’autres types d’attaques, telles que l’empoisonnement du cache Web. Ses conséquences pourraient inclure l’exécution d’opérations sensibles par les attaquants, par exemple, des réinitialisations de mot 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 être utilisé pour 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.

Encore une fois, le problème fondamental qui permet les attaques par injection LDAP est une entrée utilisateur mal validée. Si le texte qu’un utilisateur envoie à une application est utilisé dans le cadre d’une requête LDAP sans le nettoyer, la requête pourrait 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évenir les 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 avec un accès ouvert à tout internaute. La responsabilité de prévenir ces attaques est répartie entre les développeurs d’applications et les administrateurs de serveurs.