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 rompre ses mesures de sécurité – pour quelque raison que ce soit..


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

Les attaques par force brute ne sont plus une menace, grâce aux politiques de mot 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 sur les applications ou les pages Web pouvaient être exploités en entrant – ou en injectant – du texte inattendu qui forcerait l’application à faire quelque chose qu’elle n’était pas censée faire. De cette façon, 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 constituent non 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, sur 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’il veut.

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, l’application est potentiellement exploitable. Pour empêcher ces attaques, l’application doit restreindre autant que possible les utilisateurs entrants sont autorisés à entrer.

Par exemple, il doit limiter la quantité de données attendues, vérifier le format des données avant de l’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. Une fois 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 pourrait inclure une perte de confidentialité, d’intégrité, de disponibilité ou de fonctionnalité d’application.

Injection SQL

D’une 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 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 ses anciennes interfaces fonctionnelles. Les applications J2EE et ASP.Net sont généralement plus protégées contre ces attaques. Lorsqu’une vulnérabilité d’injection SQL est détectée – et elles pourraient être facilement trouvées -, 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 d’entrée insuffisante. Ils 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 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 s’exécutant sur un serveur.

Scriptage 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 du code malveillant à un autre utilisateur final. Les attaques de type Cross-Site Scripting (XSS) saisissent 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 doit pas 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 pourraient 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 stockée Attaques XSS, le script malveillant réside en permanence sur le serveur cible, dans un forum de messages, 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 réfléchi Attaques XSS, le script malveillant se reflète dans une réponse qui inclut l’entrée envoyée au serveur. Cela peut être un message d’erreur ou 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 créer une requête XPath pour les données XML. La façon dont ces attaques fonctionnent 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 les données XML, les applications Web utilisent l’entrée utilisateur pour définir un modèle auquel les données doivent correspondre. En envoyant une entrée mal formé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 peut être déclenché contre un nombre arbitraire d’objectifs.

Injection de commande de messagerie

Cette méthode d’attaque peut être utilisée pour exploiter des serveurs de messagerie et des applications qui génèrent des instructions IMAP ou SMTP avec des entrées utilisateur incorrectement validées. Parfois, les serveurs IMAP et SMTP ne bénéficient pas d’une protection efficace contre les attaques, comme ce serait le cas avec la plupart des serveurs Web, et pourraient donc être plus exploitables. En pénétrant via un serveur de messagerie, les attaquants pourraient contourner les restrictions telles que les captchas, un nombre limité de demandes, 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 contourner les restrictions du serveur et d’utiliser ses services pour envoyer du spam.

L’injection IMAP pourrait être effectuée 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 du formulaire 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 demande 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 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 résulter d’un 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 d’hôte devient nécessaire pour déterminer lequel des sites Web ou applications Web résidents – chacun d’entre eux, appelé 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 demande. 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 des 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, la réinitialisation des 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 être utilisé pour stocker des noms d’utilisateur et des 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 souhaité d’une requête LDAP s’ils peuvent y insérer des caractères de contrôle.

Encore une fois, le problème racine qui permet les attaques par injection LDAP est une entrée utilisateur incorrectement validée. Si le texte qu’un utilisateur envoie à une application est utilisé dans le cadre d’une requête LDAP sans la 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 (*) à droite placer à l’intérieur d’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 serveur.

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map