Table of Contents
La faille de sécurité la plus courante d'une application web est l'échec de bien valider les entrées provenant du client ou de l'environnement avant de les utiliser. Cette faiblesse conduit à la quasi-totalité des grandes vulnérabilités dans les applications Web, tels que le cross-site scripting, l'injection SQL, injection interpreter, les attaques locale/ Unicode, les attaques du système de fichiers, et les dépassements de tampon.
Les données d'une entité externe ou d'un client ne devraient jamais être considérées comme étant de confiance, car elles peuvent être arbitrairement altérées par un attaquant. “Toute entrée est le Diable”, a déclaré Michael Howard dans son célèbre ouvrage “Writing Secure Code”. C'est la règle numéro un. Malheureusement, les applications complexes ont souvent un grand nombre de points d'entrée, ce qui rend difficile pour un développeur de faire respecter cette règle.
Dans ce chapitre, nous décrivons les tests de validation de données. Telle est la tâche de tester toutes les formes possibles d'entrée pour comprendre si la demande valide suffisamment de données entrées avant de l'utiliser.
Nous avons divisé les tests de validation des données dans les catégories suivantes:
Test de Cross site scripting
testing_for_reflected_cross_site_scripting
Reflected Cross-Site Scripting (XSS) est un autre nom pour les XSS non-persistants, où l'attaque ne se chargent pas avec l'application web vulnérable mais est originaire du chargement de l'URI affectée par la victime. Dans cet article, nous allons voir quelques façons tester une application web pour ce type de vulnérabilité.
testing_for_stored_cross_site_scripting
Le Cross-Site Scripting (XSS) stocké est le type le plus dangereux des Cross Site Scripting. Les applications Web qui permettent aux utilisateurs de stocker des données sont potentiellement exposés à ce type d'attaque. Ce chapitre donne des exemples d'injection des scripts cross site stockés et descénarios d'exploitation connexes.
testing_for_http_verb_tampering
Test des injections SQL
Une attaque par injection SQL se compose d'insertion ou «injection» d'une requête SQL via les données entrées par le client . Un exploit par injection SQL est réussi lorsque l'attaquant peut lire les données sensibles de la base de données, modifier des données de bases de données (insérer / modifier / supprimer), exécuter des opérations d'administration sur la base de données (par exemple, l'arrêt du SGBD), récupérer le contenu d'un fichier donné existant sur le fichier de SGBD les fichiers système ou écrire dans le système de fichiers, et, dans certains cas, exécuter des commandes du système d'exploitation. L'attaque par injection SQL est un type d'attaque par injection, dans lequel les commandes SQL sont injectés dans les entrées de données dans le but d'influer sur l'exécution de commandes SQL prédéfinies.
Cette section décrit comment tester une base de données Oracle à partir du Web
Les vulnérabilités d'injection SQL se produisent chaque fois que l'entrée est utilisé dans la construction d'une requête SQL sans avoir été dûment contrainte ou désinfectés. L'utilisation de SQL dynamique (la construction de requêtes SQL par concaténation de chaînes de caractères) ouvre la porte à ces vulnérabilités. L'injection SQL permet à un attaquant d'accéder aux serveurs SQL. Il permet l'exécution de code SQL avec les privilèges de l'utilisateur utilisé pour se connecter à la base de données.
Dans cette section nous allons voir quelques techniques d'injection SQL qui utilisent des caractéristiques spécifiques de Microsoft SQL Server.
Cet article explique comment exploiter les vulnérabilités d'injection SQL lorsque la base de données principale est MS Access. En particulier, l'article se concentre sur la façon d'exploiter les injection SQL aveugles. Après une introduction initiale sur les fonctions typiques qui sont utiles pour exploiter une vulnérabilité d'injection SQL, une méthode pour exploiter les Injection SQL aveugles sera abordée.
Dans cette section, certaines techniques d'injection SQL pour PostgreSQL seront abordées
Test d'autres injections
LDAP est l'acronyme de Lightweight Directory Access Protocol. LDAP est un protocole pour stocker les informations sur les utilisateurs, les hôtes et de nombreux autres objets. L'injection LDAP est une attaque côté serveur, ce qui pourrait permettre à un attaquant ded ivulguer, modifier ou insérerdes informations sensibles sur les utilisateurs et les hôtes représentés dans une structure LDAP
L'injection ORM est une attaque par injection SQL contre le modèle de données objet ORM . Du point de vue d'un testeur, cette attaque est pratiquement identique à une attaque par injection SQL. Cependant, la vulnérabilité d'injection existe dans le code généré par l'outil ORM.
On parle de tests d'injection XML lorsque on essaye d'injecter un document XML dans l'application: si l'analyseur XML ne parvient pas à faire une validation des données le test sera positif.
Habituellement serveurs Web donnent aux développeurs la possibilité d'ajouter des petits morceaux de code dynamique à l'intérieur des pages HTML statiques, sans avoir à utiliser de véritables langues côté serveur ou côté client. Cette fonctionnalité est incarnée par le Server-Side Includes (SSI). Dans un test d'injection SSI, nous testons si il est possible d'injecter des données qui seront interprétées par des mécanismes de SSI dans l'application . Une exploitation réussie de cette vulnérabilité permet à un attaquant d'injecter du code dans des pages HTML ou même d'exécuter du code à distance.
XPath est un langage qui a été conçu et développé principalement pour adresser certaines parties d'un document XML. Dans un essai d'injection XPath, nous testons si il est possible d'injecter des données dans une application pour qu'elle exécute des requêtes XPath contrôlées par l'utilisateur. Lorsqu'elle est exploitée avec succès, cette vulnérabilité peut permettre à un attaquant de contourner les mécanismes d'authentification ou d'accéder à des informations sans autorisation.
Cette menace affecte toutes les applications qui communiquent avec les serveurs de messagerie (IMAP / SMTP), et généralement des applications de messagerie Web. Le but de ce test est de vérifier la capacité d'injecter des commandes IMAP / SMTP arbitraires dans les serveurs de messagerie, si les données d'entrée ne sont pas correctement filtrées.
Cette section décrit comment un testeur peeut vérifier s'il est possible d'entrer du code en entrée sur une page Web et le faire exécuter par le serveur web. Plus d'informations sur Injection de code peut être trouvé dans l'article code_injection,
Cet article décrit comment tester une application pour détecter l'injection de commande OS. Nous essayons d'injecter une commande OS via une requête HTTP.
Test des débordements de tampons
Dans ce test, nous vérifions si un testeur peut faire un débordement de heap(tas) qui exploite un segment de mémoire.
Cette section présente un test de débordement qui se concentre sur la façon de manipuler la pile du programme.
Autres Tests
Cette section décrit comment tester les attaques de format de chaîne qui peuvent être utilisées pour planter un programme ou exécuter du code nuisible. Le problème provient de l'utilisation d'entrées utilisateur non filtrées comme paramètre de format chaîne de caractères dans certaines fonctions C qui effectuent la mise en forme, telles que printf().
testing_for_incubated_vulnerability
Également souvent désignés comme attaques persistantes, les tests des vulnérabilités incubées est une méthode d'analyse complexe qui nécessite plus d'une vulnérabilité de validation des données pour fonctionner. Cette section décrit un ensemble d'exemples pour tester les vulnérabilités incubées.
testing_for_http_splitting_smuggling
Dans ce chapitre, nous allons illustrer des exemples d'attaques que tirent profit de fonctionnalités spécifiques du protocole HTTP, que ce soit en exploitant les faiblesses de l'application Web ou des particularités dans la manière dont les agents interprètent les messages HTTP