Nederlands
Why Perform a Retest?
The results of a pentest may reveal vulnerabilities within the investigated web application or network. Upon receipt of the pentest report, developers and administrators commence efforts to address or mitigate the identified vulnerabilities and risks. To ensure that these vulnerabilities have been adequately resolved following further development, it is recommended to conduct a retest.
What is a Retest?
A retest differs from a completely new pentest. During a retest, a pentester examines the adjustments made and verifies whether the vulnerabilities have indeed been remedied. Additionally, the pentester assesses whether the vulnerability has been resolved structurally, rather than just addressed in an ad hoc manner. A retest report is then provided based on the initial pentest report, demonstrating deductions in risks and the resolution of vulnerabilities, supported by evidence.
Costs Associated with Retesting
Retesting is invoiced based on subsequent calculations at the standard hourly rate. The number of working hours required varies depending on the quantity and type of (resolved) vulnerabilities, as well as the quality of the information provided (see examples below). On average, a retest typically takes approximately 8 - 16 hours for a pentest initially conducted by DongIT.
Retesting on Results from Other Testing Organizations
For a retest based on an initial pentest conducted by another organization, it is essential to furnish the previous pentest reports. Our pentesters can also evaluate the quality of the old reports and offer guidance on the accuracy and reliability of the previous findings.
Requesting a Retest via the Reporter Portal
To initiate a retest based on the findings from a previously conducted pentest, Client Users are required to submit a retest request through the Reporter portal under each Finding (Request a Retest). In the text field provided, Client Users can specify how the identified findings have been rectified or addressed.
What Information is Required for a Retest?
- For each Finding, Client Users must clearly outline the modifications made, including details on where and how they have been implemented. Providing comprehensive information significantly expedites the retest process, enabling faster and more effective testing.
- In cases where a vulnerability stems from a design choice within an application or represents an accepted risk, this must be clearly indicated. The pentester will assess the design choice or rationale provided.
- Client Users can include screenshots (highlighting code) or references to commits in GIT for enhanced clarity. Below are a few examples illustrating the proper documentation and provision of retest information.
Documentation/Examples for Providing Retest Request Evidence
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.
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.