Trame pour le pentest de sites Web

*La "méthode" présentée en est une parmi tant d’autres, il n’existe pas de méthodologie unique au pentest. Ce texte étant en format Wiki, n’hésitez pas à faire part de vos remarques.*

Il existe différentes catégories de pentests : le pentest de réseau, le pentest de réseau sans fil, les tests de pénétration physique, le pentest basé sur le social engineering et bien sûr, le pentest de site Web.

Si on devait donner une définition du terme, on pourrait dire que le pentest consiste à tester la résistance, la sécurité  d’un site. Le pentest est le test de la sécurité par l'attaque. Pourquoi vérifier la sécurité d’un site ? Il s’agit non seulement de se prémunir contre certaines attaques mais également – dans le cas des sites de e-commerce – de protéger les personnes qui ont recours aux services proposés par le site Web.

Dans cette méthodologie, on part du principe qu’il s’agit d’une véritable prestation de pentest avec cahier des charges, documents exonératoires de responsabilité, rédaction de rapport.

La première étape du pentest est la plus simple : on liste toutes les questions auxquelles on va devoir répondre pour effectuer le test :

• Quelle méthode va être employée ?
• Si la version white box a été choisie, dispose-t-on de tous les droits nécessaires ?
• Si la version grey box a été choisie, les droits nécessaires ont-ils été accordés ?
• A partir de quelle IP le site va-t-il être testé ?
• A quel moment le site va être testé ?
• Quel est le site ?
• Comment a-t-il été conçu ?
• S’agit-il d’un CMS ? Si oui, lequel et quelle version est utilisée ?
• Existe-t-il une base de données ? (ne riez pas, il existe encore des sites qui ne nécessitent pas de bases de données) Si oui, avec quoi est-elle faite ?
• Quel langage a été utilisé et quelle version de ce langage (PHP par exemple) ?
• Quel serveur Web a été utilisé et quelle version de du serveur Web (Apache par exemple) ?

Une fois cette première étape simple passée, on commence à collecter certaines informations plus précises.

• Le DNS du site ?
• De quel type d’hébergement dispose le site ?
• L’hébergeur a-t-il était prévenu qu’un pentest est en cours ?
• Si le site est sur un serveur mutualisé, qui sont les « voisins » ?
• Le site utilise-t-il certaines applications spécifiques comme jQuery ?
• Le code est-il valide ?
• S’il y a des erreurs dans le code, d’où proviennent-elles ?
• Sont-elles facilement rectifiables ?

On continue en poussant un peu plus long le test.

• Le site présente-t-il des failles XSS ?
• Si oui, avec quel(s) outil(s) ont-elles été découvertes ?
• Quelles failles XSS ont été mises à jour ?
• Le site permet-il de faire des injections SQL ?
• Si oui, avec quel(s) outil(s) ont-elles été découvertes ?
• Comment et où dans le site permet-il des injections SQL ?
• Si le site est un CMS, quel est le compte administrateur ?
• Si le compte administrateur a été rapidement identifié, son mot de passe était-il solide ?
• Si le mot de passe a été bruteforcé, avec quel(s) outil(s) ?
• Au bout de combien de temps le mot de passe administrateur a-t-il été découvert ?
• Le service de FTP est-il accessible ?
• Si oui, comment ?
• Les identifiants ont-ils été découvert ?
• Si oui, avec quel(s) outil(s) ?

Une fois toutes ses questions posées, il ne reste plus qu’à y répondre, à procéder concrètement au test et à rédiger le rapport.

Encore une fois, c’est une ébauche de méthode, si vous voyez des points erronés ou manquants, n’hésitez pas à en faire part dans les commentaires, le but étant d’arriver à un document propre et complet.