How to effectively prepare for a re-test

Why execute a re-test

The results of the penetration test show that the investigated web application or a network contain vulnerabilities. Based on the pentest report, developers/administrators start working to correct or reduce the identified vulnerabilities and risks. In order to be assured that the vulnerabilities have been resolved in the correct manner after further development, it is advised to carry out a re-test.

What is a re-test

A re-test is not a complete new pentest. With a re-test, a security expert will research the adjustments and check whether the vulnerabilities have actually been fixed. The security researcher will also check for example whether the vulnerability is structurally resolved and not just in a single place (ad hoc). A re-test report will be delivered based on the previous penetration test report which will show whether risks are deducted and vulnerabilities have been solved, supported by proof.

What are the costs

A re-test is invoiced on the basis of subsequent calculation against the standard hourly rate. The number of working hours required depends strongly on the amount and type of (solved) vulnerabilities and/or the quality of the supplied information (see examples below). Indication: an average re-test takes about 4 - 8 hours.

Mandatory documentation to be submitted for a re-test

To effectively prepare for the execution of a re-test, the following information must be pre-transmitted in a clear document:

  • List of vulnerabilities/risks that have been corrected and/or adjusted, as well as vulnerabilities that are not adjusted or contain accepted risks including explanatory notes. Refer to the numbering of the initial pentest report.
  • Indicate for each finding and sub-finding exactly what has changed, and where and how it has been modified. Delivery of comprehensive information benefits the required test time, making it possible to carry out a re-test faster and more effectively.
  • Include screenshots (of the code with highlights) or references to commits in GIT. See a few examples below on how to properly document and present the required information.
  • For a re-test on a prior penetration test performed by another organization, it is necessary to provide these previous pentest reports. Our security expert can also assess the quality of old reports and provide advice on the quality and accuracy of the previous findings.

Examples with clearly supplied documentation

Example 1

Short version of finding: Via parameter "jobalert_action" on the path "/nl/jobs/alert", any method of te "JobsAlertController" class can be requested. This includes methods for which it is not intended that they can be invoked. 
Proof by client: Solved, a white-list has been set with allowed methods that can be requested. See the attached screenshot (Figure 1).

Figure 1: Allowed methods white-listed.

Example 2

Short version of finding: The database query on rule 89 in "controllers/pagesController.php" is not parameterized or is not escaped. By adjusting the request the query can be manipulated (SQL-injection).
Proof by client: Solved, the queries are now parameterized. See attached screenshot (Figure 2).

Figure 2: Parameterized queries.

Example 3

Short version of finding: Cookie attributes are not set correctly on the session-cookie "PHPSESSID".
Proof by client: Adjusted, cookie attributes have been set to "secure" and "HttpOnly". This has been set in php.ini. See attached screenshot (Figure 3).

Figure 3: Cookie attribute settings.

Examples with unclear or insufficient documentation

Example 4

Short version of finding: Server-Side Request Forgery has been found at "/include/seotool/index.php" (url parameter).
(Insufficient) proof by client: Solved.
Required proof by client: Solved, the directory "/include/seotool" has been deleted from the project, this functionality was not being used.

Example 5

Short version of finding: Reflected XSS on "/include/" (parameter id).
(Insufficient) proof by client: Adjusted.
Required proof by client:  Adjusted, parameter is now filtered in rule 10 of "/include/". See attached screenshot (Figure 4).

Figure 4: Parameter filtered.

Example 6

Short version of finding: Erroneous log-in attempts are stored with username and password in readable format in the database table "dbacc2.auth_logs".
(Insufficient) proof by client: Fixed.
Required proof by client: Fixed, incorrect login attempts are now logged in the database without a password (Figure 5). The existing rules with passwords have been removed from the database.

Figure 5: Rules with passwords have been removed.

Example 7

Short version of finding: On it is possible to approach an unsecured NFS-share. On this NFS-share a username and password was found in the file "log.txt". With these credentials it is possible to log in at https: //gw2012.acme.local/login.".
(Insufficient) proof by client: Fixed.
Required proof by client: Solved. 1: the NFS-share is protected wit a username and password. 2: the password of the account found has been changed on gw2012.acme.local.