Re-testing

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 approximately 4 - 8 hours, on an pentest that was initially executed by DongIT.

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 documentation/delivery of proof for re-test

1. Example - Parameter

Finding initial pentest: Via parameter "jobalert_action" on the path "/nl/jobs/alert", any methods of class "JobsAlertController" can be requested. This includes methods for which it is not intended that they can be invoked.
Delivered proof by client: Fixed, method of the class "JobsAlertController" can no longer be requested.
Preferred proof by client: Solved, a white-list has been set with allowed methods. See attached screenshot (Figure 1).

whitelist_methods
Figure 1: White-listing of allowed methods.

2. Example - Cookie Attributes

Finding initial pentest: Cookie attributes are not set correctly for the session-cookie "PHPSESSID".
Delivered proof by client: Fixed.
Preferred proof by client: Adjusted, cookie attributes have been set to "secure" and "HttpOnly". This has been set in php.ini. See attached screenshot (Figure 2).

cookie_settings
Figure 2: Cookie attributes settings.

3. Example - SQL Injection

Finding initial pentest: The database query on rule 89 in "controllers/pagesController.php" is not parameterized or is not escaped properly. By adjusting the request, the query can be manipulated (SQL-injection).
Delivered proof by client: Solved, implemented the advice given by the pentester.
Preferred proof by client: Solved, queries are now parameterized. See attached screenshot (Figure 3).

parametrisering_query
Figure 3: Parameterized queries.

4. Example - Server-Side Request Forgery

Finding initial pentest: Server-Side Request Forgery has been found at "/include/seotool/index.php" (url parameter).
Delivered proof by client: Solved, Server-Side Request Forgery is no longer possible.
Preferred proof by client: Solved, the directory "/include/seotool" has been deleted from the project, this function was not used.

5. Example - Cross-Site Scripting

Finding initial pentest: Reflected XSS on "/include/menuitem.demo.inc.php" (id parameter).
Delivered proof by client: Adjusted.
Preferred proof by client:  Adjusted, parameter is now filtered in line 10 of "/include/menuitem.demo.inc.php". See attached screenshot (Figure 4).

reflected_xss
Figure 4: Parameter filtered.

6. Example - Password Storage in Clear Text

Finding initial pentest: Erroneous log-in attempts are stored with username and password in readable format in de database tabel "dbacc2.auth_logs". 
Delivered proof by client: Fixed.
Preferred proof by client: Fixed, incorrect log-in attempts are now logged in the database without a password (Figure 5). The existing rules with passwords have been removed from the database.

foutieve_inlogpogingen
Figure 5: Rules with password deleted.

7. Example - NFS-share Publicly Accessible

Finding initial pentest: On 10.0.0.118 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".  
Delivered proof by client: Fixed.
Preferred proof by client: Solved. 1: the NFS-share is protected with a username and password. 2: the password of the compromised account has been changed on gw2012.acme.local.

8. Example - Outdated and Unsupported Software is Used

Finding initial pentest: Outdated and unsupported version of jQuery is used.
Delivered proof by client:  -
Preferred proof by client: This vulnerability has not been solved yet. Development work is being budgeted by client. Or for example: all found vulnerabilities with risk classification "low" are not solved yet. These will be picked up after all "medium" and "high" risks have been resolved.