Difference between revisions of "4.8 Tester la validation des entrées"

Latest revision as of 10:44, 17 December 2014

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

4.8 Tester la validation des entrées

La faille de sécurité la plus répandue sur les applications web est le manque de validation correcte des entrées venant des clients ou de l'environnement avant leur utilisation. Cette faille conduit à quasiment toutes les vulnérabilités dans les applications web, comme le cross site scripting, les injections SQL, les injections d’interpréteur, les attaques locale/Unicode, les attaques du système de fichier, et les dépassements de tampons (buffer overflows).

Il ne faut jamais faire confiance aux données venant de l'extérieur, puisqu'elles peuvent être manipulées arbitrairement par un attaquant. "Toutes les entrées sont hostiles", a écrit 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 d'appliquer cette règle. Ce chapitre traite du test de validation des données. Cela concerne le test de toutes les formes possibles d'entrées, afin de comprendre si l'application valide suffisamment les données qu'elle reçoit avant de les utiliser.

Les tests de validation des entrées se subdivisent en différentes catégories :

Tester le Cross site scripting
Les tests de Cross Site Scripting (XSS) vérifient s'il est possible de manipuler les paramètres d'entrée de l'application pour générer des sorties malicieuses. Les testeurs trouvent des vulnérabilités XSS quand l'application ne valide pas ses entrées et crée des sorties sous leur contrôle. Cette vulnérabilité permet des attaques variées, par exemple, le vol d'information confidentielles (comme des cookies de session) ou la prise de contrôle du navigateur de la victime. Une attaque XSS brise le schéma suivant : Entrée -> Sortie == cross-site scripting.

Dans ce guide, les types de tests XSS suivants seront vus en détail :
4.8.1 Tester les failles Reflected Cross Site Scripting (OTG-INPVAL-001)
4.8.2 Tester les failles Stored Cross Site Scripting (OTG-INPVAL-002)

Les tests XSS côté client, comme les DOM XSS et Cross Site Flashing seront vus dans la section des tests côté client.

Tester les failles HTTP Verb Tampering and Parameter Pollution HTTP Verb Tampering consiste à tester les réponses de l'application à différentes méthodes HTTP accédant aux objets système. Pour chaque objet système découvert lors de l'exploration, le testeur doit essayer d'y accéder avec toutes les méthodes HTTP. HTTP Parameter Pollution consiste à tester les réponses de l'application recevant plusieurs paramètres HTTP portant le même nom. Par exemple, si le paramètre username est inclus plusieurs fois dans une requête GET ou POST, quelle version est utilisée, s'il y en a une.

Les HTTP Verb Tampering sont décrit dans :

4.8.3 Tester les failles HTTP Verb Tampering (OTG-INPVAL-003)

et les techniques de test des paramètres HTTP sont présentés ici :

4.8.4 Tester les failles HTTP Parameter pollution (OTG-INPVAL-004)

4.8.5 SQL Injection (OTG-INPVAL-005)
Les tests d'injection SQL vérifient s'il est possible d'injecter des données dans l'application de manière qu'elle exécute une requête SQL controllée par l'utilisateur dans la base de donnée back-end. Les testeurs trouvent des vulnérabilités de type injection SQL si l'application utilise des entrées utilisateur pour construire des requêtes SQL sans les valider correctement. Une exploitation réussie de ce type de vulnérabilité permet à un utilisateur non-autorisé d'accéder ou de manipuler des données dans la base de données. Notez que les données de l'application sont souvent un actif central d'une entreprise. Une attaque par injection SQL casse le schéma suivant : Entrée -> Requête SQL == Injection SQL.

Les tests d'injections SQL sont ensuite subdivisés par produit/fournisseur :
4.8.5.1 Oracle Testing
4.8.5.2 MySQL Testing
4.8.5.3 SQL Server Testing
4.8.5.4 Testing PostgreSQL
4.8.5.5 MS Access Testing
4.8.5.6 Testing for NoSQL injection

4.8.6 LDAP Injection (OTG-INPVAL-006)
Les tests d'injection LDAP sont similaires aux tests d'injection SQL. La différence est que l'on va tester le protocole LDAP au lieu de SQL, et que la cible est un serveur LDAP plutôt qu'un serveur SQL. Une attaque LDAP casse le schéma suivant :
Entrée -> Requête LDAP == Injection LDAP

4.8.7 ORM Injection (OTG-INPVAL-007)
Le test d'injection ORM est similaire au test d'injection SQL. Dans ce cas, on utilise une injection SQL sur un modèle d'accès objet généré par un ORM. Du point de vue du testeur, cette attaque est identique à une attaque par injection SQL. Cependant, la vulnérabilité se trouve dans le code généré par un outil ORM.

4.8.8 XML Injection (OTG-INPVAL-008)
Les tests d'injection XML vérifient s'il est possible d'injecter un document XML particulier dans l'application. On trouve des injections XML si le parser XML ne fait pas les validations de données adéquates.
Une injection XML casse le schéma suivant :
Entrée -> document XML == Injection XML

4.8.9 SSI Injection (OTG-INPVAL-009)
Un serveur web donne en général aux développeurs la possibilité d'ajouter des petites parties de code à l'intérieur des pages HTML statiques, sans avoir à travailler avec des langages complets côté serveur ou client. Cette fonctionnalité s'appelle l'injection "Server-Side Include" (SSI). Les tests d'injection SSI vérifient s'il est possible d'injecter dans l'application des données qui seront interprétées par les mécanismes SSI. Une exploitation réussie permettra à un attaquant d'injecter du code dans les pages HTML et même d'exécuter du code à distance.

4.8.10 XPath Injection (OTG-INPVAL-010)
XPath est un langage d'adressage de documents XML. Les tests d'injection XPath visent à vérifier s'il est possible d'injecter des données dans une application et de les exécuter comme des requêtes XPath contrôlées par l'utilisateur. Exploitée avec succès, cette vulnérabilité permet à un attaquant de contourner les mécanismes d'authentification, ou d'accéder à des informations sans autorisation.

4.8.11 IMAP/SMTP Injection (OTG-INPVAL-011)
Cette menace touche toutes les applications qui communiques avec des serveurs email (IMAP/SMTP), le plus souvent les applications webmail. Les tests d'injection IMAP/SMTP visent à vérifier s'il est possible d'injecter des commandes IMAP/SMTP arbitraires dans les serveurs email, grâce à un manque de validation des entrées.
Une attaque par injection IMAP/SMTP casse le schéma suivant :
Entrée -> commande IMAP/SMTP == Injection IMAP/SMTP

4.8.12 Code Injection (OTG-INPVAL-012)
Les tests dinjection de code vérifient s'il est possible d'injecter des données dans une application qui seront plus tard exécutées par le serveur web.
Une injection de code casse le schéma suivant :
Entrée -> Code malicieux == Injection de Code

4.8.13 OS Commanding (OTG-INPVAL-013)
Les testeurs vont essayer d'injecter dans l'application des commandes systèmes via une requête HTTP.
Une injection de commande casse le schéma suivant :
Entrée -> Commande Système == Injection de commande système

4.8.14 Buffer overflow (OTG-INPVAL-014)
Les testeurs vont vérifier différents type de vulnérabilités de dépassement de tampon. Voici les méthodes pour les types courants :
4.8.14.1 Heap overflow
4.8.14.2 Stack overflow
4.8.14.3 Format string

En général, un dépassement de tampon casse le schéma suivant :
Entrée -> tampon fixe ou format de chaîne == Dépassement

4.8.15 Incubated vulnerability (OTG-INPVAL-015)
Les tests Incubated sont des tests complexes, nécessitant plus d'une vulnérabilité de validation pour fonctionner.

4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)
Cette section décrit les tests d'exploitation HTTP, comme les HTTP Verb, HTTP Splitting, HTTP Smuggling.

Dans tous les schémas montrés plus haut, les données doivent être validées par l'application avant d'être utilisées. Le but des tests est de vérifier si l'application vérifie efficacement ses entrées.