Nederlands
Why execute a retest
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 retest.
What is a retest
A retest is not a complete new pentest. With a retest, 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 retest 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 retest 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 retest takes approximately 4 - 8 hours, on an pentest that was initially executed by DongIT.
Retest on research results from different testing organization
For a retest on an initial penetration test performed by another organization, it is necessary to provide the previous pentest reports. Our security experts can also assess the quality of old reports and provide advice on the quality and accuracy of the previous findings.
Request a retest via the Reporter portal
To perform a retest on the findings from a previously performed penetration test, the client must request a retest via the Reporter portal under each Submission (Request a retest). In the text field, as shown below, the client can then indicate how the finding has been corrected/processed.
What information must be supplied with a retest?
- 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 retest faster and more effectively.
- If a vulnerability arises from an application design choice or contains an accepted risk, this must also be indicated. A pentester will judge the design choice or the comment.
- Optionally add screenshots (of the code with highlights) or references to commits in GIT. See below a number of examples for properly documenting and supplying retest information.
Examples documentation/delivery of proof for retest
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.