1.2 CVE-2011-4415

Ce schéma d'attaque consiste à provoquer un dépassement de tampon par la manipulation de variables d'environnement. Une fois que l'adversaire a découvert qu'il peut modifier une variable d'environnement, il peut essayer de faire déborder les tampons associés. Cette attaque exploite la confiance implicite souvent accordée aux variables d'environnement. [Identifier l'application cible] L'adversaire identifie une application ou un programme cible pour effectuer le dépassement de tampon. Dans cette attaque, l'adversaire recherche une application qui charge le contenu d'une variable d'environnement dans un tampon. [Trouver le vecteur d'injection] L'adversaire identifie un vecteur d'injection pour délivrer le contenu excessif dans le tampon de l'application ciblée. [Craft overflow content] L'adversaire prépare le contenu à injecter. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour exécuter un code arbitraire, l'adversaire prépare la charge utile de telle sorte que l'adresse de retour écrasée soit remplacée par une adresse de son choix. [Débordement de la mémoire tampon] En utilisant le vecteur d'injection, l'adversaire injecte le contenu du débordement dans la mémoire tampon.

Un attaquant peut utiliser l'injection SSI (Server Side Include) pour envoyer du code à une application Web qui sera ensuite exécuté par le serveur Web. Cette méthode permet à l'attaquant d'obtenir des résultats similaires à ceux du Cross Site Scripting, à savoir l'exécution de code arbitraire et la divulgation d'informations, mais à une échelle plus limitée, car les directives SSI sont loin d'être aussi puissantes qu'un langage de script à part entière. Néanmoins, l'attaquant peut facilement accéder à des fichiers sensibles, tels que des fichiers de mots de passe, et exécuter des commandes shell. [Déterminer l'applicabilité] L'adversaire détermine si les inclusions côté serveur sont activées sur le serveur Web cible. [Trouver le point d'injection] Rechercher les entrées contrôlables par l'utilisateur, y compris les en-têtes HTTP, qui peuvent transmettre des directives d'inclusion côté serveur au serveur Web. [Injection SSI] En utilisant le point d'injection trouvé, l'adversaire envoie du code arbitraire à inclure par l'application côté serveur. Il peut alors avoir besoin de visualiser une page particulière pour que le serveur exécute la directive d'inclusion et lance une commande ou ouvre un fichier au nom de l'adversaire.

Un attaquant est en mesure d'amener une victime à charger dans son navigateur Web un contenu qui contourne les contrôles de la zone de sécurité et d'accéder à des privilèges accrus pour exécuter du code de script ou d'autres objets Web tels que des contrôles ActiveX ou des applets non signés. Il s'agit d'une attaque par élévation de privilèges ciblant la sécurité des navigateurs Web par zone. [Trouvez les systèmes susceptibles de subir l'attaque] Trouvez les systèmes qui contiennent des fonctionnalités accessibles à la fois depuis la zone Internet et la zone locale. Il doit y avoir un moyen de fournir une entrée à cette fonctionnalité depuis la zone Internet et cette entrée originale doit être utilisée ultérieurement sur une page de la zone locale. [Trouver le point d'insertion de la charge utile] L'attaquant doit d'abord trouver une fonctionnalité du système ou éventuellement une autre faiblesse du système (par exemple, la sensibilité au cross site scripting) qui lui fournirait un mécanisme pour transmettre la charge utile (c'est-à-dire le code à exécuter) à l'utilisateur. L'emplacement à partir duquel ce code est exécuté dans le navigateur de l'utilisateur doit se trouver dans la zone de la machine locale. [Concevoir et injecter la charge utile] Développer la charge utile à exécuter dans la zone de privilège supérieure du navigateur de l'utilisateur. Injectez la charge utile et essayez d'inciter la victime (si possible) à exécuter la fonctionnalité qui libère la charge utile.

Un attaquant utilise des méthodes d'injection SQL standard pour injecter des données dans la ligne de commande afin de les exécuter. Cela peut se faire directement par une mauvaise utilisation de directives telles que MSSQL_xp_cmdshell ou indirectement par l'injection de données dans la base de données qui seraient interprétées comme des commandes shell. Un peu plus tard, une application dorsale peu scrupuleuse (ou qui pourrait faire partie de la fonctionnalité de la même application) récupère les données injectées stockées dans la base de données et les utilise comme arguments de ligne de commande sans effectuer la validation appropriée. Les données malveillantes s'échappent du plan de données en générant de nouvelles commandes à exécuter sur l'hôte. [Sonde pour la vulnérabilité d'injection SQL] L'attaquant injecte la syntaxe SQL dans les entrées de données contrôlables par l'utilisateur pour rechercher l'exécution non filtrée de la syntaxe SQL dans une requête. [Exécution de commandes arbitraires par injection SQL avec la directive MSSQL_xp_cmdshell] L'attaquant exploite une attaque par injection SQL pour injecter du code shell à exécuter en exploitant la directive xp_cmdshell. [Injecter des données malveillantes dans la base de données] Tirer parti de l'injection SQL pour injecter des données dans la base de données qui pourraient être utilisées ultérieurement pour réaliser une injection de commande si elles étaient utilisées comme argument de ligne de commande [Déclencher l'exécution de la ligne de commande avec les arguments injectés] L'attaquant provoque l'exécution de la fonctionnalité de ligne de commande qui exploite le contenu de la base de données précédemment injecté comme arguments.

Un attaquant exploite une faiblesse présente dans le code de la couche d'accès à la base de données généré par un outil ORM (Object Relational Mapping) ou une faiblesse dans la manière dont un développeur a utilisé un framework de persistance pour injecter ses propres commandes SQL à exécuter contre la base de données sous-jacente. L'attaque est similaire à une injection SQL classique, sauf que l'application n'utilise pas JDBC pour communiquer directement avec la base de données, mais une couche d'accès aux données générée par un outil ou un framework ORM (par exemple Hibernate). Bien que la plupart du temps, le code généré par un outil ORM contienne des méthodes d'accès sûres qui sont à l'abri de l'injection SQL, il arrive que l'injection SQL soit toujours possible, soit en raison d'une faiblesse du code généré, soit parce que le développeur n'a pas utilisé correctement les méthodes d'accès générées. Déterminer le cadre de persistance utilisé] Un attaquant tente de déterminer quel cadre de persistance est utilisé par l'application afin d'exploiter une faiblesse dans le code de la couche d'accès aux données généré ou une faiblesse dans la manière dont la couche d'accès aux données a pu être utilisée par le développeur. L'attaquant injecte la syntaxe ORM dans les entrées de données contrôlables par l'utilisateur de l'application afin de déterminer s'il est possible de modifier la structure et le contenu des requêtes de données. Effectuer une injection SQL à travers la couche d'accès aux données générée] Un attaquant exploite une faiblesse dans les méthodes d'accès aux données générées qui ne séparent pas correctement le plan de contrôle du plan de données, ou potentiellement une façon particulière dont le développeur aurait pu mal utiliser le code généré, pour modifier la structure des requêtes SQL exécutées et/ou injecter des requêtes SQL entièrement nouvelles.

Un attaquant modifie les paramètres du message SOAP envoyé par le consommateur de services au fournisseur de services pour lancer une attaque par injection SQL. Du côté du fournisseur de services, le message SOAP est analysé et les paramètres ne sont pas correctement validés avant d'être utilisés pour accéder à une base de données d'une manière qui n'utilise pas la liaison des paramètres, permettant ainsi à l'attaquant de contrôler la structure de la requête SQL exécutée. Ce modèle décrit une attaque par injection SQL dont le mécanisme de livraison est un message SOAP. Détecter une manipulation incorrecte des paramètres SOAP] L'attaquant manipule les paramètres du message SOAP et recherche des indications selon lesquelles cette manipulation a entraîné un changement de comportement de l'application ciblée. Probe for SQL Injection vulnerability] L'attaquant injecte de la syntaxe SQL dans les paramètres SOAP vulnérables identifiés pendant la phase d'exploration pour rechercher l'exécution non filtrée de la syntaxe SQL dans une requête. Injection SQL via les paramètres SOAP] L'attaquant injecte du SQL via les paramètres SOAP identifiés comme vulnérables durant la phase d'exploration pour lancer une attaque par injection SQL de premier ou de second ordre.

L'adversaire utilise une répétition du processus d'encodage pour un ensemble de caractères (c'est-à-dire l'encodage d'un caractère) pour obscurcir la charge utile d'une requête particulière. Cela peut permettre à l'adversaire de contourner les filtres qui tentent de détecter les caractères ou les chaînes de caractères illégaux, tels que ceux qui pourraient être utilisés dans des attaques par traversée ou par injection. Les filtres peuvent être capables de détecter les chaînes codées illégales, mais pas les chaînes doublement codées. Par exemple, un point (.), souvent utilisé dans les attaques de traversée de chemin et donc souvent bloqué par les filtres, pourrait être codé en URL comme %2E. Cependant, de nombreux filtres reconnaissent cet encodage et bloquent quand même la requête. Dans un double encodage, le % dans l'encodage de l'URL ci-dessus serait à nouveau encodé en tant que %25, ce qui donnerait %252E que certains filtres pourraient ne pas détecter, mais qui pourrait toujours être interprété comme un point (.) par les interprètes de la cible. À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un attaquant enregistre tous les points d'entrée de l'application. Sonder les points d'entrée pour localiser les vulnérabilités] Essayer de doubler le codage de certaines parties de l'entrée afin d'essayer de passer les filtres. Par exemple, en doublant le codage de certains caractères dans l'URL (par exemple, les points et les barres obliques), un adversaire peut essayer d'accéder à des ressources restreintes sur le serveur Web ou forcer la navigation vers des pages protégées (et ainsi contourner le service d'autorisation). Un adversaire peut également tenter d'autres attaques de type injection en utilisant ce modèle d'attaque : injection de commande, injection SQL, etc.

L'adversaire modifie directement ou indirectement les variables d'environnement utilisées par le logiciel cible ou le contrôlant. L'objectif de l'adversaire est d'amener le logiciel cible à s'écarter de son fonctionnement prévu d'une manière qui lui soit profitable. [Sonder l'application cible] L'adversaire sonde d'abord l'application cible afin de déterminer des informations importantes sur la cible. Ces informations peuvent inclure les types de logiciels utilisés, les versions des logiciels, les entrées utilisateur consommées par l'application, etc. Plus important encore, l'adversaire essaie de déterminer quelles variables d'environnement pourraient être utilisées par le logiciel sous-jacent, voire par l'application elle-même. [À l'aide des informations trouvées en sondant l'application, l'adversaire tente de manipuler toutes les variables d'environnement contrôlées par l'utilisateur qu'il a trouvées et qui sont utilisées par l'application, ou qu'il soupçonne d'être utilisées par l'application, et observe les effets de ces changements. Si l'adversaire remarque des changements significatifs dans l'application, il saura qu'une certaine variable d'environnement est importante pour le comportement de l'application et indique un vecteur d'attaque possible. [Manipulation des variables d'environnement contrôlées par l'utilisateur] L'adversaire manipule la ou les variables d'environnement trouvées afin d'abuser du flux normal des processus ou d'accéder à des ressources privilégiées.

Un adversaire inclut des caractères de formatage dans un champ de saisie de chaîne de l'application cible. La plupart des applications supposent que les utilisateurs fournissent un texte statique et peuvent réagir de manière imprévisible à la présence d'un caractère de formatage. Par exemple, dans certaines fonctions du langage de programmation C telles que printf, le caractère de formatage %s imprimera le contenu d'un emplacement mémoire en s'attendant à ce que cet emplacement identifie une chaîne de caractères et le caractère de formatage %n imprimera le nombre de DWORD écrits dans la mémoire. Un adversaire peut utiliser cela pour lire ou écrire dans des emplacements mémoire ou des fichiers, ou simplement pour manipuler la valeur du texte résultant de manière inattendue. La lecture ou l'écriture de la mémoire peut entraîner le plantage du programme et l'écriture de la mémoire peut entraîner l'exécution de code arbitraire si l'adversaire peut écrire dans la pile du programme. L'adversaire fait l'inventaire des points d'entrée de l'application. Déterminer l'entrée contrôlable par l'utilisateur susceptible d'être injectée par une chaîne de format] Déterminer l'entrée contrôlable par l'utilisateur susceptible d'être injectée par une chaîne de format. Pour chaque entrée contrôlable par l'utilisateur que l'adversaire soupçonne d'être vulnérable à l'injection de chaînes de format, il tente d'injecter des caractères de formatage tels que %n, %s, etc. L'objectif est de manipuler la création de la chaîne de caractères à l'aide de ces caractères de formatage. Après avoir déterminé qu'une entrée donnée est vulnérable à l'injection de chaînes de format, émettez des hypothèses sur l'utilisation sous-jacente et les contraintes associées.

Un attaquant manipule ou crée une requête LDAP dans le but de porter atteinte à la sécurité de la cible. Certaines applications utilisent les entrées de l'utilisateur pour créer des requêtes LDAP qui sont traitées par un serveur LDAP. Par exemple, un utilisateur peut fournir son nom d'utilisateur lors de l'authentification et celui-ci peut être inséré dans une requête LDAP pendant le processus d'authentification. Un attaquant pourrait utiliser cette entrée pour injecter des commandes supplémentaires dans une requête LDAP qui pourraient divulguer des informations sensibles. Par exemple, la saisie d'un * dans la requête susmentionnée pourrait renvoyer des informations sur tous les utilisateurs du système. Cette attaque est très similaire à une attaque par injection SQL dans la mesure où elle manipule une requête pour recueillir des informations supplémentaires ou forcer une valeur de retour particulière. [L'attaquant fait l'inventaire des points d'entrée de l'application. [Déterminer les entrées contrôlables par l'utilisateur susceptibles de faire l'objet d'une injection LDAP] Pour chaque entrée contrôlable par l'utilisateur que l'attaquant soupçonne d'être vulnérable à une injection LDAP, il tente d'injecter des caractères qui ont une signification particulière dans LDAP (comme le caractère guillemet simple, etc.). L'objectif est de créer une requête LDAP avec une syntaxe invalide [Essayer d'exploiter la vulnérabilité de l'injection LDAP] Après avoir déterminé qu'une entrée donnée est vulnérable à l'injection LDAP, émettre une hypothèse sur ce à quoi ressemble la requête sous-jacente. En utilisant éventuellement un outil, essayez itérativement d'ajouter une logique à la requête pour extraire des informations du LDAP, ou pour modifier ou supprimer des informations dans le LDAP.

Ce type d'attaque exploite une vulnérabilité de dépassement de tampon dans le logiciel client ciblé par l'injection de contenu malveillant à partir d'un service hostile personnalisé. Ce service hostile est créé pour délivrer le contenu correct au logiciel client. Par exemple, si l'application côté client est un navigateur, le service hébergera une page web que le navigateur chargera. [Identifier l'application côté client cible] L'adversaire identifie une application côté client cible pour effectuer le dépassement de tampon. Les navigateurs sont les plus courants. S'il existe une vulnérabilité connue du navigateur, l'adversaire peut la cibler. [Trouver un vecteur d'injection] L'adversaire identifie un vecteur d'injection pour envoyer le contenu excessif dans la mémoire tampon de l'application ciblée. [Créer un service hostile] L'adversaire crée un service hostile qui transmet le contenu à l'application côté client. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour exécuter du code arbitraire, l'adversaire prépare la charge utile de telle sorte que l'adresse de retour écrasée soit remplacée par une adresse de son choix. [Débordement de la mémoire tampon] En utilisant le vecteur d'injection, l'adversaire transmet le contenu à l'application côté client en utilisant le service hostile et en faisant déborder la mémoire tampon.

Un attaquant exploite une faiblesse dans la validation des entrées en contrôlant le format, la structure et la composition des données à une interface de traitement des entrées. En fournissant des données d'une forme non standard ou inattendue, un attaquant peut avoir un impact négatif sur la sécurité de la cible.

Un attaquant trompe une victime pour qu'elle exécute un contenu flash malveillant qui exécute des commandes ou effectue des appels flash spécifiés par l'attaquant. Un exemple de cette attaque est le cross-site flashing, un paramètre contrôlé par l'attaquant à un appel de référence se charge à partir d'un contenu spécifié par l'attaquant. [Trouver les points d'entrée de l'injection] L'attaquant commence par faire l'inventaire des points d'entrée de l'application. [Déterminer la sensibilité de l'application à l'injection Flash] Déterminer la sensibilité de l'application à l'injection Flash. Pour chaque URL identifiée lors de la phase d'exploration, l'attaquant tente d'utiliser diverses techniques telles que le chargement direct en tant que fonction, la page malveillante contrôlée ou l'hôte, l'injection Flash HTML et l'injection DOM pour déterminer si l'application est sensible à l'injection Flash. [Injecter du contenu malveillant dans la cible] Injecter du contenu malveillant dans la cible en utilisant les vecteurs d'injection vulnérables identifiés lors de la phase d'expérimentation.

Un adversaire crée un fichier contenant des scripts mais dont le type MIME spécifié est tel que les scripts ne sont pas attendus. L'adversaire incite la victime à accéder à une URL qui répond avec le fichier de script. Certains navigateurs détectent que le type MIME spécifié du fichier ne correspond pas au type réel de son contenu et passent automatiquement à l'utilisation d'un interpréteur pour le type de contenu réel. Si le navigateur n'invoque pas de filtres de script avant de faire cela, le script de l'adversaire peut s'exécuter sur la cible sans être nettoyé, révélant éventuellement les cookies de la victime ou exécutant un script arbitraire dans son navigateur. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire suit tous les liens et actions publics sur un site Web. Il enregistre toutes les zones qui permettent à un utilisateur de télécharger du contenu via une requête HTTP POST. Cela se trouve généralement dans les blogs ou les forums. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et télécharge des fichiers avec du contenu de script, mais dont le type MIME est spécifié comme un type de fichier qui ne peut pas exécuter de contenu de script. Si l'application vérifie uniquement le type MIME du fichier, elle peut laisser passer le fichier, ce qui entraîne l'exécution du script par tout utilisateur qui accède au fichier. [Une fois que l'adversaire a déterminé quels emplacements de téléchargement de fichiers sont vulnérables à la non-concordance des types MIME, il télécharge un script malveillant déguisé en fichier sans script. L'adversaire peut avoir de nombreux objectifs, depuis le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page d'une victime. [Pour que l'attaque réussisse, la victime doit voir le contenu malveillant stocké sur la page Web.

Une attaque de ce type exploite les vulnérabilités de l'authentification des canaux de communication client/serveur et de l'intégrité des données. Il tire parti de la confiance implicite qu'un serveur accorde au client, ou plus important encore, à ce que le serveur croit être le client. Un attaquant exécute ce type d'attaque en communiquant directement avec le serveur lorsque celui-ci pense qu'il ne communique qu'avec un client valide. Il existe de nombreuses variantes de ce type d'attaque.

Un adversaire empoisonne des fichiers avec une charge utile malveillante (ciblant les systèmes de fichiers accessibles par le logiciel cible), qui peut être transmise par des canaux standard tels que le courrier électronique, et du contenu web standard comme des fichiers PDF et multimédia. L'adversaire exploite des vulnérabilités connues ou des routines de traitement dans les processus cibles, afin d'exploiter la confiance de l'hôte pour exécuter du contenu distant, y compris des fichiers binaires.

Les applications doivent souvent transformer les données en provenance et à destination d'un format de données (par exemple, XML et YAML) en utilisant un analyseur syntaxique. Il peut être possible pour un adversaire d'injecter des données qui peuvent avoir un effet négatif sur l'analyseur syntaxique lors de son traitement. De nombreux langages de formatage de données permettent de définir des structures de type macro qui peuvent être utilisées pour simplifier la création de structures complexes. En imbriquant ces structures et en faisant en sorte que les données soient substituées de manière répétée, un adversaire peut faire en sorte que l'analyseur syntaxique consomme davantage de ressources pendant le traitement, ce qui entraîne une consommation excessive de la mémoire et de l'unité centrale. Un adversaire détermine le flux de données d'entrée qui est traité par un analyseur syntaxique de données qui prend en charge l'utilisation de la substitution du côté de la victime. Un adversaire fabrique des données d'entrée qui peuvent avoir un effet négatif sur le fonctionnement de l'analyseur lorsque les données sont analysées sur le système de la victime.

Un adversaire injecte des charges utiles de données sérialisées surdimensionnées dans un analyseur syntaxique pendant le traitement des données afin de produire des effets indésirables sur l'analyseur syntaxique, tels que l'épuisement des ressources du système et l'exécution de code arbitraire. Un adversaire détermine le flux de données d'entrée qui est traité par un analyseur de données sérialisées du côté de la victime. Un adversaire crée des données d'entrée qui peuvent avoir un effet négatif sur le fonctionnement de l'analyseur de données lorsque les données sont analysées sur le système de la victime.

Dans cette attaque, l'idée est de faire échouer un filtre actif en provoquant une transaction surdimensionnée. Un attaquant peut essayer d'alimenter le programme avec des chaînes d'entrée trop longues afin de submerger le filtre (en provoquant un dépassement de tampon) et en espérant que le filtre n'échoue pas de manière sûre (c'est-à-dire que l'entrée de l'utilisateur est laissée dans le système sans être filtrée). [Enquête] L'attaquant examine l'application cible, éventuellement en tant qu'utilisateur valide et authentifié. Cette opération peut être effectuée manuellement ou à l'aide d'un outil dynamique (boîte noire). Un attaquant peut également utiliser un script personnalisé à cette fin. [Surveillez les réponses] Soyez attentif à tout signe d'échec. Observez attentivement ce qui s'est passé lorsque l'échec du filtre s'est produit. Les données sont-elles entrées ? [Abuser du système par le biais d'un échec du filtre] Un attaquant écrit un script pour provoquer systématiquement l'échec du filtre.

Un attaquant utilise des entrées contrôlables par l'utilisateur pour sonder, attaquer et injecter des données dans la base de données XML, en utilisant des techniques similaires à l'injection SQL. L'entrée contrôlable par l'utilisateur peut permettre de visualiser des données sans autorisation, de contourner l'authentification ou l'application frontale pour accéder directement à la base de données XML, et éventuellement de modifier les informations de la base de données. [A l'aide d'un navigateur ou d'un outil automatisé, un adversaire enregistre toutes les instances d'entrées contrôlables par l'utilisateur utilisées pour structurer les requêtes XML [Déterminer la structure des requêtes] A l'aide de moyens manuels ou automatisés, testez les entrées trouvées pour détecter les faiblesses XML. [Injecter du contenu dans les requêtes XML] Créer un contenu malveillant contenant des expressions XML qui n'est pas validé par l'application et qui est exécuté dans le cadre des requêtes XML.

Un adversaire qui est autorisé à envoyer des requêtes à une cible envoie des variantes des requêtes attendues dans l'espoir que ces requêtes modifiées puissent retourner des informations (directement ou indirectement par le biais de journaux d'erreurs) au-delà de ce que l'ensemble des requêtes attendues devrait fournir. [Observer les communications et les entrées] L'adversaire de fuzzing observe le système cible à la recherche d'entrées et de communications entre modules, sous-systèmes ou systèmes. [Générer des entrées floues] Compte tenu d'un outil de fuzzing, d'une entrée ou d'un protocole cible, et de limites de temps, de complexité et de variété d'entrées, générer une liste d'entrées à essayer. Bien que le fuzzing soit aléatoire, il n'est pas exhaustif. Les paramètres tels que la durée, la composition et le nombre de variations à essayer sont importants pour obtenir l'impact le plus rentable du fuzzer. [Observer le résultat] Observez les sorties des entrées fournies au système par les fuzzers et voyez s'il y a des messages de journal ou d'erreur qui fournissent des données utilisateur/sensibles ou qui donnent des informations sur un modèle attendu qui pourrait être utilisé pour produire ces données. [Si les journaux ne révèlent pas de données utilisateur/sensibles, un adversaire tentera de faire en sorte que les entrées de fuzzing correspondent à un modèle attendu.

Un adversaire exploite la possibilité de coder des entrées ou des contenus potentiellement dangereux utilisés par des applications de telle sorte que ces dernières sont inefficaces pour valider cette norme de codage. [A l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase "Explorer" comme liste de cibles et injecte diverses charges utiles en utilisant différents types d'encodage pour déterminer si un point d'entrée représente réellement une vulnérabilité avec une logique de validation insuffisante et pour caractériser la mesure dans laquelle la vulnérabilité peut être exploitée.

Dans ce modèle d'attaque, l'adversaire utilise le fuzzing pour tenter d'identifier les faiblesses du système. Le fuzzing est une méthode de test de la sécurité et de la fonctionnalité des logiciels qui consiste à introduire dans le système des données construites de manière aléatoire et à rechercher une indication qu'une défaillance s'est produite en réponse à ces données. Le fuzzing traite le système comme une boîte noire et est totalement libre de toute idée préconçue ou hypothèse sur le système. Le fuzzing peut aider un attaquant à découvrir certaines hypothèses faites sur les entrées utilisateur dans le système. Le fuzzing offre à un attaquant un moyen rapide de découvrir potentiellement certaines de ces hypothèses, même s'il ne connaît pas nécessairement les éléments internes du système. Ces hypothèses peuvent ensuite être retournées contre le système en créant spécialement des entrées utilisateur qui peuvent permettre à un attaquant d'atteindre ses objectifs. Observer les communications et les entrées] Le pirate observe le système cible à la recherche d'entrées et de communications entre modules, sous-systèmes ou systèmes. Générer des entrées fuzzées] Compte tenu d'un outil de fuzzing, d'une entrée ou d'un protocole cible, et de limites de temps, de complexité et de variété d'entrées, il génère une liste d'entrées à essayer. Bien que le fuzzing soit aléatoire, il n'est pas exhaustif. Les paramètres tels que la durée, la composition et le nombre de variations à essayer sont importants pour obtenir l'impact le plus rentable du fuzzer. Observer le résultat] Observez les sorties des entrées introduites dans le système par les fuzzers et voyez si quelque chose d'intéressant se produit. En cas d'échec, déterminez pourquoi cela s'est produit. Déterminez l'hypothèse sous-jacente qui a été invalidée par l'entrée. Créer des charges utiles d'exploitation] Introduisez dans le système des entrées spécialement conçues pour exploiter la faiblesse identifiée par le fuzzing et permettre d'atteindre les objectifs de l'attaquant. Les fuzzers révèlent souvent des moyens de passer à travers les filtres de validation des entrées et d'introduire des données non désirées dans le système.

Certaines API suppriment certains caractères de tête d'une chaîne de paramètres. Un adversaire peut introduire intentionnellement des caractères de tête "fantômes" (caractères supplémentaires qui n'affectent pas la validité de la demande au niveau de la couche API) qui permettent à l'entrée de passer les filtres et donc de traiter l'entrée de l'adversaire. Cela se produit lorsque l'API ciblée accepte des données d'entrée sous plusieurs formes syntaxiques et les interprète de manière sémantique équivalente, alors que le filtre ne prend pas en compte l'ensemble des formes syntaxiques acceptables pour l'API ciblée. [À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et injecte diverses séquences de caractères "fantômes" en tête pour déterminer comment l'application les filtre. [Contournement du filtrage des entrées] En utilisant ce que l'adversaire a appris sur la façon dont l'application filtre les données d'entrée, il crée des données d'entrée spécifiques qui contournent le filtre. Cela peut conduire à des attaques par traversée de répertoire, à l'exécution de commandes shell arbitraires, à la corruption de fichiers, etc.

Cette attaque repose sur l'utilisation de cookies HTTP pour stocker des informations d'identification, des informations d'état et d'autres données critiques sur les systèmes clients. Il existe plusieurs formes différentes de cette attaque. La première forme de cette attaque consiste à accéder aux cookies HTTP pour extraire les données potentiellement sensibles qu'ils contiennent. La deuxième forme consiste à intercepter ces données lorsqu'elles sont transmises du client au serveur. Ces informations interceptées sont ensuite utilisées par l'adversaire pour se faire passer pour l'utilisateur ou la session à distance. La troisième forme est celle où le contenu du cookie est modifié par l'adversaire avant qu'il ne soit renvoyé au serveur. Dans ce cas, l'adversaire cherche à convaincre le serveur cible de fonctionner sur la base de ces informations falsifiées. Obtenir une copie du cookie] L'adversaire doit d'abord obtenir une copie du cookie. Il peut s'agir d'un utilisateur final légitime souhaitant élever ses privilèges ou d'une personne reniflant le réseau pour obtenir une copie des cookies HTTP. Obtenir des informations sensibles à partir du cookie] L'adversaire peut être en mesure d'obtenir des informations sensibles à partir du cookie. Les développeurs de l'application web peuvent avoir supposé que les cookies ne sont pas accessibles par les utilisateurs finaux, et peuvent donc y avoir placé des informations potentiellement sensibles. Modifier les cookies pour contourner les contrôles de sécurité] L'adversaire peut être en mesure de modifier ou de remplacer les cookies pour contourner les contrôles de sécurité de l'application.

Un attaquant exploite une faiblesse dans la routine de conversion MIME pour provoquer un dépassement de tampon et prendre le contrôle de la machine du serveur de messagerie. Le système MIME est conçu pour permettre à différents formats d'information d'être interprétés et envoyés par e-mail. Les points d'attaque existent lorsque les données sont converties en format compatible MIME et inversement. [Identifier le serveur de messagerie cible] L'adversaire identifie un serveur de messagerie cible qu'il souhaite attaquer. [Déterminer la viabilité de l'attaque] Déterminer si le serveur de messagerie n'est pas corrigé et s'il est potentiellement vulnérable à l'un des débordements de tampon de conversion MIME connus (par exemple Sendmail 8.8.3 et 8.8.4). [Trouver le vecteur d'injection] Identifier les endroits du système où les routines de conversion MIME vulnérables peuvent être utilisées. [Craft overflow content] L'adversaire crée des messages électroniques avec des en-têtes spéciaux qui provoqueront un dépassement de tampon pour la routine de conversion MIME vulnérable. L'intention de cette attaque est d'exploiter le débordement pour exécuter du code arbitraire et accéder à la machine du serveur de messagerie. L'adversaire va donc créer un e-mail qui non seulement fait déborder le tampon ciblé, mais le fait de telle sorte que l'adresse de retour écrasée est remplacée par une adresse de son choix. [Débordement de la mémoire tampon] Envoyer des messages électroniques au système cible avec des en-têtes spécialement conçus qui déclenchent le débordement de la mémoire tampon et exécutent le code shell.

Un attaquant fournit au logiciel cible des données d'entrée qui contiennent des séquences de caractères spéciaux conçues pour contourner la logique de validation des entrées. Cet exploit repose sur le fait que la cible effectue plusieurs passages sur les données d'entrée et traite une "couche" de caractères spéciaux à chaque passage. De cette manière, l'attaquant peut déguiser une entrée qui serait autrement rejetée comme non valide en la dissimulant avec des couches de caractères spéciaux/échappatoires qui sont supprimés par les étapes de traitement suivantes. L'objectif est de découvrir d'abord les cas où la couche de validation des entrées s'exécute avant une ou plusieurs couches d'analyse. C'est-à-dire que l'entrée de l'utilisateur peut passer par la logique suivante dans une application : <parser1> --> <validation d'entrée> --> <parser2>. Dans ce cas, l'attaquant devra fournir une entrée qui passera par le validateur d'entrée, mais qui, après être passée par le parser2, sera convertie en quelque chose que le validateur d'entrée était censé arrêter. [Déterminer les entrées de l'application/du système où le contournement de la validation d'entrée est souhaité] L'attaquant doit d'abord déterminer toutes les entrées de l'application/du système où la validation d'entrée est effectuée et où il veut la contourner. [Déterminer les codages de caractères acceptés par l'application/le système] L'attaquant doit ensuite fournir différents codages de caractères à l'application/au système et déterminer ceux qui sont acceptés. L'attaquant devra observer la réponse de l'application/du système aux données codées pour déterminer si les données ont été interprétées correctement. [Combiner plusieurs codages acceptés par l'application] L'attaquant combine maintenant les codages acceptés par l'application. L'attaquant peut combiner différents codages ou appliquer le même codage plusieurs fois. [Exploiter la capacité à contourner la validation des entrées] L'attaquant exploite sa capacité à contourner la validation des entrées pour obtenir un accès non autorisé au système. Il existe de nombreuses attaques possibles, et quelques exemples sont mentionnés ici.

Ce type d'attaque exploite l'utilisation de liens symboliques pour provoquer des dépassements de tampon. Un adversaire peut essayer de créer ou de manipuler un fichier de lien symbolique de telle sorte que son contenu donne lieu à des données hors limites. Lorsque le logiciel cible traite le fichier de lien symbolique, il peut potentiellement faire déborder les tampons internes dont la vérification des limites est insuffisante. [Identifier l'application cible] L'adversaire identifie une application ou un programme cible qui pourrait charger certains fichiers en mémoire. [Trouver le vecteur d'injection] L'adversaire identifie un vecteur d'injection pour délivrer le contenu excessif dans le tampon de l'application cible. [Craft overflow file content] L'adversaire prépare le contenu à injecter. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour exécuter un code arbitraire, l'adversaire prépare la charge utile de telle sorte que l'adresse de retour écrasée soit remplacée par une adresse de son choix. [Débordement de la mémoire tampon] À l'aide du contenu du fichier spécialement conçu, l'adversaire crée un lien symbolique entre la ressource identifiée et le fichier malveillant, ce qui provoque une attaque ciblée par débordement de mémoire tampon.

Ce type d'attaque exploite l'utilisation de balises ou de variables provenant de données de configuration formatées pour provoquer un dépassement de tampon. L'adversaire crée une page HTML malveillante ou un fichier de configuration qui inclut des chaînes de caractères surdimensionnées, provoquant ainsi un débordement. [Identification de l'application cible] L'adversaire identifie une application ou un programme cible pour effectuer le dépassement de tampon. Les adversaires recherchent des applications ou des programmes qui acceptent des fichiers formatés, tels que des fichiers de configuration, en entrée. [Trouver un vecteur d'injection] L'adversaire identifie un vecteur d'injection pour délivrer le contenu excessif dans la mémoire tampon de l'application cible. [Craft overflow content] L'adversaire prépare le contenu à injecter. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour exécuter un code arbitraire, l'adversaire prépare la charge utile de telle sorte que l'adresse de retour écrasée soit remplacée par une adresse de son choix. [Débordement de la mémoire tampon] L'adversaire télécharge le fichier modifié dans l'application, ce qui provoque un débordement de la mémoire tampon.

Dans cette attaque, le logiciel cible reçoit des données d'entrée dont l'adversaire sait qu'elles seront modifiées et augmentées en taille pendant le traitement. Cette attaque repose sur le fait que le logiciel cible n'anticipe pas que les données étendues peuvent dépasser une certaine limite interne, créant ainsi un dépassement de tampon. [Identifier l'application cible] L'adversaire identifie une application ou un programme cible pour effectuer le dépassement de tampon. Les adversaires recherchent souvent des applications qui acceptent les entrées utilisateur et qui effectuent une gestion manuelle de la mémoire. [Trouver le vecteur d'injection] L'adversaire identifie un vecteur d'injection pour transmettre le contenu excessif au tampon de l'application cible. [Craft overflow content] L'adversaire prépare l'entrée à donner au programme. Si l'intention est simplement de faire planter le logiciel, il suffit que l'entrée s'étende à une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour l'exécution d'un code arbitraire, l'adversaire concevra une entrée qui se développe de manière à non seulement faire déborder le tampon ciblé, mais aussi de telle sorte que l'adresse de retour écrasée soit remplacée par une adresse choisie par l'adversaire qui pointe vers un code injecté par l'adversaire. [Débordement de la mémoire tampon] En utilisant le vecteur d'injection, l'adversaire donne l'entrée modifiée au programme, ce qui fait déborder la mémoire tampon.

Un attaquant génère un message ou un bloc de données qui fait croire au destinataire que le message ou le bloc de données a été généré et signé cryptographiquement par une source autorisée ou réputée, trompant une victime ou le système d'exploitation de la victime pour qu'il effectue des actions malveillantes.

Un adversaire incorpore un ou plusieurs octets nuls dans l'entrée du logiciel cible. Cette attaque repose sur l'utilisation d'un octet nul comme terminateur de chaîne dans de nombreux environnements. L'objectif est de faire en sorte que certains composants du logiciel cible arrêtent de traiter l'entrée lorsqu'ils rencontrent le ou les octets nuls. [A l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et injecte des octets nuls postfix pour observer comment l'application les traite en tant qu'entrée. L'adversaire recherche des zones où l'entrée de l'utilisateur est placée au milieu d'une chaîne de caractères, et l'octet nul fait en sorte que l'application arrête de traiter la chaîne à la fin de l'entrée de l'utilisateur. [Après avoir déterminé les points d'entrée qui sont vulnérables, l'adversaire place un ou plusieurs octets nuls de manière à supprimer les données après l'octet ou les octets nuls d'une manière qui lui est bénéfique.

Si une chaîne passe par un filtre quelconque, un NULL terminal peut ne pas être valide. L'utilisation d'une autre représentation de NULL permet à un adversaire d'intégrer le NULL au milieu de la chaîne tout en postfixant les données appropriées de manière à éviter le filtre. Un exemple est un filtre qui recherche une barre oblique en fin de chaîne. Si l'insertion d'une chaîne de caractères est possible, mais que le slash doit exister, un encodage alternatif de NULL en milieu de chaîne peut être utilisé. [À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et injecte des octets nuls postfix suivis d'une barre oblique inverse pour observer comment l'application les traite en entrée. L'adversaire recherche des zones où la saisie de l'utilisateur est placée au milieu d'une chaîne de caractères, et l'octet nul fait en sorte que l'application arrête de traiter la chaîne à la fin de la saisie de l'utilisateur. [Après avoir déterminé les points d'entrée vulnérables, l'adversaire place un ou plusieurs octets nuls suivis d'une barre oblique inverse de façon à contourner un filtre d'entrée et à supprimer les données après l'octet ou les octets nuls d'une manière qui lui est bénéfique.

Ce type d'attaque est une forme de Cross-Site Scripting (XSS) où un script malveillant est inséré dans le HTML côté client analysé par un navigateur web. Le contenu servi par une application web vulnérable comprend du code script utilisé pour manipuler le Document Object Model (DOM). Ce code script ne valide pas correctement les données d'entrée ou n'effectue pas un codage de sortie correct, ce qui permet à un adversaire d'injecter un script malveillant et de lancer une attaque XSS. Une distinction essentielle entre les autres attaques XSS et les attaques basées sur le DOM est que dans les autres attaques XSS, le script malveillant s'exécute lorsque la page Web vulnérable est initialement chargée, alors que l'attaque basée sur le DOM s'exécute quelque temps après le chargement de la page. Une autre distinction des attaques basées sur le DOM est que dans certains cas, le script malveillant n'est jamais envoyé au serveur web vulnérable. Une telle attaque est garantie pour contourner toute tentative de filtrage côté serveur pour protéger les utilisateurs. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme une liste de cibles et injecte diverses charges utiles de script courantes et des caractères spéciaux pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser la mesure dans laquelle la vulnérabilité peut être exploitée. En ce qui concerne le XSS basé sur le DOM, l'adversaire recherche des zones où l'entrée est utilisée pour modifier directement le DOM. [Une fois que l'adversaire a déterminé quels paramètres sont vulnérables au XSS, il crée une URL malveillante contenant l'exploit XSS. L'adversaire peut avoir de nombreux objectifs, comme le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page de la victime. Dans le cas d'un XSS basé sur le DOM, le script malveillant peut même ne pas être envoyé au serveur, puisque le navigateur de la victime manipule lui-même le DOM. Cela peut permettre d'éviter les mécanismes de détection côté serveur. [Faire en sorte que la victime clique sur l'URL] Pour que l'attaque réussisse, la victime doit accéder à l'URL malveillante.

Un adversaire incorpore des scripts malveillants dans le contenu qui sera servi aux navigateurs web. L'objectif de l'attaque est que le logiciel cible, le navigateur côté client, exécute le script avec le niveau de privilège des utilisateurs. Une attaque de ce type exploite les vulnérabilités d'un programme en permettant à des hôtes distants d'exécuter du code et des scripts. Les navigateurs Web, par exemple, ont mis en place des contrôles de sécurité simples, mais si un attaquant distant est autorisé à exécuter des scripts (en les injectant dans du contenu généré par l'utilisateur, comme des tableaux d'affichage), ces contrôles peuvent être contournés. En outre, ces attaques sont très difficiles à détecter pour un utilisateur final. [À l'aide d'un navigateur ou d'un outil automatisé, un attaquant suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accédées et tous les autres points d'entrée potentiels de l'application web. [L'attaquant utilise les points d'entrée recueillis lors de la phase d'exploration comme une liste de cibles et injecte diverses charges utiles de script courantes pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser l'étendue de l'exploitation de la vulnérabilité. [Si l'attaquant réussit à exploiter la vulnérabilité, il peut choisir de voler les informations d'identification de l'utilisateur afin de les réutiliser ou de les analyser ultérieurement. [Navigation forcée] Lorsque l'attaquant cible l'application actuelle ou une autre (par le biais de vulnérabilités CSRF), c'est l'utilisateur qui effectue les attaques sans s'en rendre compte. Ces attaques visent principalement les failles de logique applicative, mais elles peuvent également être utilisées pour créer une attaque généralisée contre un site web particulier sur le réseau actuel de l'utilisateur (Internet ou non). [L'usurpation de contenu] En manipulant le contenu, l'attaquant cible les informations que l'utilisateur souhaite obtenir du site web.

Cette attaque cible l'encodage de l'URL combiné à l'encodage des caractères slash. Un attaquant peut tirer parti des multiples façons d'encoder une URL et abuser de l'interprétation de l'URL. Une URL peut contenir des caractères spéciaux qui nécessitent un traitement syntaxique particulier afin d'être interprétés. Les caractères spéciaux sont représentés par un pourcentage suivi de deux chiffres représentant le code d'octet du caractère original (%HEX-CODE). Par exemple, le caractère espace US-ASCII sera représenté par %20. Cette méthode est souvent appelée "terminaison échappée" ou "codage en pourcentage". Comme le serveur décode l'URL à partir des requêtes, il peut restreindre l'accès à certains chemins URL en validant et en filtrant les requêtes URL qu'il reçoit. Un attaquant tentera de créer une URL avec une séquence de caractères spéciaux qui, une fois interprétée par le serveur, sera équivalente à une URL interdite. Il peut être difficile de se protéger contre cette attaque car l'URL peut contenir d'autres formats d'encodage tels que l'encodage UTF-8, l'encodage Unicode, etc. L'attaquant accède au serveur en utilisant une URL spécifique. L'attaquant essaie d'encoder certains caractères spéciaux dans l'URL. L'attaquant découvre que certains caractères ne sont pas filtrés correctement. L'attaquant crée une demande de chaîne d'URL malveillante et l'envoie au serveur. Le serveur décode et interprète la chaîne d'URL. Malheureusement, comme le filtrage des entrées n'est pas effectué correctement, les caractères spéciaux ont des conséquences néfastes.

[Trouver l'application cible] Trouver l'application Web cible qui accepte une entrée utilisateur et récupère des données sur le serveur [Examiner les demandes d'application existantes] Examiner les demandes HTTP/GET pour voir le format de la requête URL. Les adversaires vérifient si ce type d'attaque est possible grâce à des faiblesses dans la protection de l'application contre la falsification des requêtes côté serveur (Server Side Request Forgery) [Demande malveillante] L'adversaire crée une demande URL malveillante qui suppose le niveau de privilège du serveur pour interroger des services réseau internes ou externes et envoie la demande à l'application.

Cette attaque vise les applications et les logiciels qui utilisent la fonction syslog() de manière non sécurisée. Si une application n'utilise pas explicitement un paramètre de chaîne de format dans un appel à syslog(), une entrée utilisateur peut être placée dans le paramètre de chaîne de format, ce qui entraîne une attaque par injection de chaîne de format. Les adversaires peuvent alors injecter des commandes de chaîne de format malveillantes dans l'appel de fonction, ce qui entraîne un dépassement de tampon. De nombreuses vulnérabilités logicielles sont signalées, la cause principale étant une mauvaise utilisation de la fonction syslog(). [Identification de l'application cible] L'adversaire identifie une application ou un programme cible pour effectuer le dépassement de tampon. Dans cette attaque, les adversaires recherchent des applications qui utilisent syslog() de manière incorrecte. [Trouver le vecteur d'injection] L'adversaire identifie un vecteur d'injection pour délivrer le contenu excessif dans la mémoire tampon de l'application cible. Pour chaque entrée contrôlable par l'utilisateur que l'adversaire soupçonne d'être vulnérable à l'injection de chaînes de format, il tente d'injecter des caractères de formatage tels que %n, %s, etc. Le but est de manipuler la création de la chaîne en utilisant ces caractères de formatage. [Craft overflow content] L'adversaire prépare le contenu à injecter. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour l'exécution d'un code arbitraire, l'adversaire créera un ensemble de contenu qui non seulement déborde le tampon ciblé, mais le fait de telle sorte que l'adresse de retour écrasée est remplacée par une adresse choisie par l'adversaire qui pointe vers un code injecté par l'adversaire. [Débordement de la mémoire tampon] En utilisant le vecteur d'injection, l'adversaire fournit au programme l'injection de la chaîne de format, provoquant un débordement de la mémoire tampon.

L'injection SQL aveugle résulte d'une atténuation insuffisante de l'injection SQL. Bien que la suppression des messages d'erreur de la base de données soit considérée comme une bonne pratique, la suppression seule n'est pas suffisante pour empêcher l'injection SQL. L'injection SQL aveugle est une forme d'injection SQL qui permet de surmonter l'absence de messages d'erreur. Sans les messages d'erreur qui facilitent l'injection SQL, l'adversaire construit des chaînes d'entrée qui sondent la cible au moyen de simples expressions booléennes SQL. L'adversaire peut déterminer si la syntaxe et la structure de l'injection ont réussi en fonction de l'exécution ou non de la requête. Appliqué de manière itérative, l'adversaire détermine comment et où la cible est vulnérable à l'injection SQL. Hypothèse de requêtes SQL dans l'application] [Déterminer comment injecter des informations dans les requêtes] [Déterminer les entrées contrôlables par l'utilisateur susceptibles d'être injectées] Déterminer les entrées contrôlables par l'utilisateur susceptibles d'être injectées. Pour chaque entrée contrôlable par l'utilisateur que l'adversaire soupçonne d'être vulnérable à l'injection SQL, il tente d'injecter les valeurs déterminées à l'étape précédente. Si aucune erreur ne se produit, l'adversaire sait que l'injection SQL a réussi. Déterminer le type de base de données] Détermine le type de base de données, comme MS SQL Server, Oracle ou MySQL, en utilisant des conditions logiques dans le cadre des requêtes injectées [Extraire des informations sur le schéma de la base de données] Extraire des informations sur le schéma de la base de données en amenant la base de données à répondre à des questions oui/non sur le schéma. Exploiter la vulnérabilité de l'injection SQL] Utiliser les informations obtenues lors des étapes précédentes pour réussir à injecter la base de données afin de contourner les contrôles ou de modifier, ajouter, récupérer ou supprimer des données de la base de données.

Un attaquant peut fournir une chaîne Unicode à un composant du système qui ne connaît pas l'Unicode et l'utiliser pour contourner le filtre ou faire en sorte que le mécanisme de classification ne comprenne pas correctement la demande. Cela peut permettre à l'attaquant de faire passer des données malveillantes à travers le filtre de contenu et/ou de faire en sorte que l'application achemine la demande de manière incorrecte. [À l'aide d'un navigateur ou d'un outil automatisé, un attaquant suit tous les liens et actions publics sur un site Web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. [Sonder les points d'entrée pour localiser les vulnérabilités] L'attaquant utilise les points d'entrée recueillis lors de la phase "Explorer" comme liste de cibles et injecte diverses charges utiles codées en Unicode pour déterminer si un point d'entrée représente effectivement une vulnérabilité avec une logique de validation insuffisante et pour caractériser la mesure dans laquelle la vulnérabilité peut être exploitée.

Cette attaque vise l'encodage de l'URL. Un adversaire peut tirer parti des multiples façons de coder une URL et abuser de l'interprétation de l'URL. [A l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre toutes les URL qui contiennent des paramètres. [Sonder les URL pour localiser les vulnérabilités] L'adversaire utilise les URL collectées lors de la phase "Explore" comme liste de cibles et teste les paramètres avec différents codages de caractères spéciaux pour voir comment l'application Web les traite. [Injection de caractères spéciaux dans les paramètres de l'URL] À l'aide des informations recueillies lors de la phase "Expérimentation", l'adversaire injecte des caractères spéciaux dans l'URL en utilisant l'encodage de l'URL. Cela peut entraîner une traversée de chemin, un scriptage intersite, une injection SQL, etc.

Une attaque de ce type consiste pour un adversaire à insérer des caractères malveillants (comme une redirection XSS) dans un nom de fichier, directement ou indirectement, qui est ensuite utilisé par le logiciel cible pour générer du texte HTML ou d'autres contenus potentiellement exécutables. De nombreux sites web s'appuient sur le contenu généré par les utilisateurs et créent dynamiquement des ressources telles que des fichiers, des noms de fichiers et des liens URL directement à partir des données fournies par les utilisateurs. Dans ce type d'attaque, l'attaquant télécharge du code qui peut s'exécuter dans le navigateur du client et/ou rediriger le navigateur du client vers un site dont il est propriétaire. Toutes les variantes de charge utile d'attaque XSS peuvent être utilisées pour passer et exploiter ces vulnérabilités.

Cette attaque vise l'utilisation de la barre oblique inverse dans l'encodage alternatif. Un adversaire peut fournir une barre oblique inverse comme caractère de tête et faire croire à un analyseur syntaxique que le caractère suivant est spécial. Cela s'appelle un échappement. En utilisant cette astuce, l'adversaire tente d'exploiter d'autres façons de coder le même caractère, ce qui entraîne des problèmes de filtrage et ouvre des voies d'attaque. [À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase "Explorer" comme liste de cibles et tente d'échapper à plusieurs caractères spéciaux différents à l'aide d'une barre oblique inverse. [Manipulation de l'entrée] Une fois que l'adversaire a déterminé comment contourner les filtres qui filtrent les caractères spéciaux à l'aide d'une barre oblique inversée, il manipule l'entrée de l'utilisateur d'une manière qui n'est pas prévue par l'application.

Cette attaque cible l'encodage des caractères Slash. Un adversaire tenterait d'exploiter les problèmes de filtrage courants liés à l'utilisation des caractères slash pour accéder aux ressources de l'hôte cible. Les systèmes basés sur des répertoires, tels que les systèmes de fichiers et les bases de données, utilisent généralement le caractère slash pour indiquer la traversée entre les répertoires ou d'autres composants du conteneur. Pour des raisons historiques obscures, les PC (et, par conséquent, les systèmes d'exploitation Microsoft) choisissent d'utiliser une barre oblique inverse, alors que le monde UNIX utilise généralement la barre oblique directe. Le résultat de cette schizophrénie est que de nombreux systèmes basés sur MS doivent comprendre les deux formes de la barre oblique. Cela donne à l'adversaire de nombreuses occasions de découvrir et d'abuser d'un certain nombre de problèmes de filtrage courants. L'objectif de ce modèle est de découvrir un logiciel serveur qui n'applique des filtres qu'à une version, mais pas à l'autre. [À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase d'"Exploration" comme liste de cibles et recherche les zones où les entrées utilisateur sont utilisées pour accéder aux ressources de l'hôte cible. L'adversaire tente d'utiliser différents codages des caractères slash pour contourner les filtres d'entrée. [Traverser les répertoires d'application] Une fois que l'adversaire a déterminé comment contourner les filtres qui filtrent les caractères obliques, il manipule la saisie de l'utilisateur pour inclure des obliques afin de traverser les répertoires et d'accéder à des ressources qui ne sont pas destinées à l'utilisateur.

Cette attaque vise les bibliothèques ou les modules de code partagé qui sont vulnérables aux attaques par débordement de tampon. Un adversaire qui a connaissance des bibliothèques ou du code partagé vulnérables connus peut facilement cibler les logiciels qui utilisent ces bibliothèques. Tous les clients qui utilisent la bibliothèque de code deviennent ainsi vulnérables par association. Cela a un effet très large sur la sécurité d'un système, affectant généralement plus d'un processus logiciel. [Identifier l'application cible] L'adversaire, qui connaît les bibliothèques ou les modules de code partagé vulnérables, identifie une application ou un programme cible qui les utilise. [Trouver le vecteur d'injection] L'adversaire tente d'utiliser l'API et, s'il y parvient, il envoie une grande quantité de données pour voir si l'attaque par débordement de mémoire tampon fonctionne réellement. [Créer un contenu de débordement] L'adversaire crée le contenu à injecter en fonction de sa connaissance de la vulnérabilité et du résultat souhaité. Si l'intention est simplement de faire planter le logiciel, il suffit que le contenu consiste en une quantité excessive de données aléatoires. Si l'intention est d'exploiter le débordement pour exécuter du code arbitraire, l'adversaire élaborera un ensemble de contenu qui non seulement fait déborder le tampon ciblé, mais le fait de telle sorte que l'adresse de retour écrasée est remplacée par une adresse de son choix qui pointe vers du code injecté par l'adversaire. [Débordement du tampon] En utilisant l'API comme vecteur d'injection, l'adversaire injecte le contenu de débordement élaboré dans le tampon.

Cette attaque est une variation spécifique de l'utilisation d'encodages alternatifs pour contourner la logique de validation. Cette attaque exploite la possibilité d'encoder des entrées potentiellement dangereuses en UTF-8 et de les soumettre à des applications qui ne s'attendent pas à cette norme d'encodage ou qui ne sont pas en mesure de la valider, ce qui rend le filtrage des entrées difficile. UTF-8 (8-bit UCS/Unicode Transformation Format) est un codage de caractères à longueur variable pour Unicode. Les caractères UTF-8 légaux ont une longueur de un à quatre octets. Cependant, la première version de la spécification UTF-8 comportait quelques erreurs (dans certains cas, elle autorisait des caractères trop longs). Les codeurs UTF-8 sont censés utiliser le codage "le plus court possible", mais les décodeurs naïfs peuvent accepter des codages plus longs que nécessaire. Selon la RFC 3629, une forme particulièrement subtile de cette attaque peut être menée contre un analyseur syntaxique qui effectue des contrôles de validité critiques pour la sécurité contre la forme codée UTF-8 de son entrée, mais interprète certaines séquences d'octets illégales comme des caractères. [À l'aide d'un navigateur ou d'un outil automatisé, un attaquant suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. [Sonder les points d'entrée pour localiser les vulnérabilités] L'attaquant utilise les points d'entrée recueillis lors de la phase "Explorer" comme liste de cibles et injecte diverses charges utiles codées en UTF-8 pour déterminer si un point d'entrée représente réellement une vulnérabilité avec une logique de validation insuffisante et pour caractériser la mesure dans laquelle la vulnérabilité peut être exploitée.

Les attaques par altération des journaux Web impliquent qu'un attaquant injecte, supprime ou altère de toute autre manière le contenu des journaux Web, généralement dans le but de masquer un autre comportement malveillant. De plus, l'écriture de données malveillantes dans les fichiers journaux peut cibler des tâches, des filtres, des rapports et d'autres agents qui traitent les journaux dans un schéma d'attaque asynchrone. Ce schéma d'attaque est similaire à celui de "Log Injection-Tampering-Forging", sauf que dans ce cas, l'attaque vise les journaux du serveur Web et non l'application. [Déterminer le format du fichier journal du serveur Web de l'application] L'attaquant observe le système et recherche des indicateurs de l'utilitaire de journalisation utilisé par le serveur Web. [Déterminer le contenu injectable] L'attaquant lance diverses actions de journalisation avec des données malveillantes pour déterminer quel type d'injection de journal est possible. [Manipulation des fichiers journaux] L'attaquant modifie le contenu des journaux soit directement en les manipulant ou en les falsifiant, soit indirectement en injectant des requêtes spécialement conçues que le serveur Web recevra et écrira dans les journaux. Ce type d'attaque suit généralement une autre attaque et est utilisé pour tenter de couvrir les traces de l'attaque précédente.

Un attaquant peut créer une entrée spéciale contrôlable par l'utilisateur, composée d'expressions XPath, pour injecter la base de données XML et contourner l'authentification ou glaner des informations qu'il ne pourrait normalement pas obtenir. L'injection XPath permet à un attaquant de parler directement à la base de données XML, contournant ainsi complètement l'application. L'injection XPath résulte de l'incapacité d'une application à nettoyer correctement les entrées utilisées dans le cadre des expressions XPath dynamiques utilisées pour interroger une base de données XML. [A l'aide d'un navigateur ou d'un outil automatisé, un adversaire enregistre toutes les instances d'entrées contrôlables par l'utilisateur utilisées pour construire des requêtes XPath. [Déterminer la structure des requêtes] En utilisant des moyens manuels ou automatisés, tester les entrées trouvées pour détecter les faiblesses de XPath. [Injecter du contenu dans les requêtes XPath] Créer un contenu malveillant contenant des expressions XPath qui n'est pas validé par l'application et qui est exécuté dans le cadre des requêtes XPath.

Cette attaque utilise les fréquents allers-retours client-serveur dans les conversations Ajax pour scanner un système. Si Ajax n'ouvre pas de nouvelles vulnérabilités en soi, il les optimise du point de vue de l'attaquant. La première étape habituelle pour un attaquant est de prendre l'empreinte de l'environnement cible pour comprendre quelles attaques fonctionneront. Étant donné que l'empreinte repose sur l'énumération, le modèle conversationnel de demandes et de réponses rapides et multiples qui est typique des applications Ajax permet à un attaquant de rechercher de nombreuses vulnérabilités, des ports connus, des emplacements de réseau, etc. Les connaissances acquises grâce à l'empreinte Ajax peuvent être utilisées pour soutenir d'autres attaques, telles que XSS. [À l'aide d'un navigateur ou d'un outil automatisé, un pirate envoie des requêtes à une page Web et enregistre la réponse HTML reçue. Les adversaires analysent ensuite le HTML pour identifier toute architecture JavaScript sous-jacente connue. Cela peut aider à mettre en correspondance les vulnérabilités connues du public avec la page Web et peut également aider l'adversaire à deviner l'architecture de l'application et le fonctionnement interne d'un système.

Dans ce type d'attaque, un adversaire injecte des commandes du système d'exploitation dans les fonctions d'une application existante. Une application qui utilise des entrées non fiables pour construire des chaînes de commande est vulnérable. Un adversaire peut tirer parti de l'injection de commandes du système d'exploitation dans une application pour élever ses privilèges, exécuter des commandes arbitraires et compromettre le système d'exploitation sous-jacent. Identifier les entrées pour les commandes du système d'exploitation] L'attaquant détermine les entrées contrôlables par l'utilisateur qui sont transmises dans le cadre d'une commande au système d'exploitation sous-jacent. L'attaquant examine l'application cible, éventuellement en tant qu'utilisateur valide et authentifié [Varier les entrées, à la recherche de résultats malveillants] Selon que l'application exploitée est distante ou locale, l'attaquant crée l'entrée malveillante appropriée, contenant des commandes du système d'exploitation, à transmettre à l'application [Exécuter des commandes malveillantes] L'attaquant peut voler des informations, installer un mécanisme d'accès par porte dérobée, élever les privilèges ou compromettre le système d'une autre manière.

Cette attaque vise les utilitaires de ligne de commande disponibles dans un certain nombre de shells. Un adversaire peut tirer parti d'une vulnérabilité trouvée dans un utilitaire de ligne de commande pour élever ses privilèges jusqu'à root. [Identifier le système cible] L'adversaire commence par trouver un système cible sur lequel il souhaite obtenir des privilèges élevés. Il peut s'agir d'un système auquel il a déjà un certain niveau d'accès ou d'un système auquel il va accéder sans autorisation à un niveau de privilège inférieur par d'autres moyens. [Trouver un vecteur d'injection] L'adversaire identifie les utilitaires de ligne de commande exposés par l'hôte cible qui contiennent des vulnérabilités de débordement de tampon. L'adversaire sait probablement quels utilitaires présentent ces vulnérabilités et quelles sont les versions concernées, il obtiendra donc également les numéros de version de ces utilitaires. [Créer une commande de débordement] Une fois que l'adversaire a trouvé un utilitaire vulnérable, il utilise sa connaissance de la vulnérabilité pour créer la commande qui exploitera le débordement de la mémoire tampon. [Débordement de la mémoire tampon] En utilisant le vecteur d'injection, l'adversaire exécute la commande créée, obtenant ainsi des privilèges élevés sur la machine.