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).
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).
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).
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).
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.