During my first pentest reports it happened a few times that I suddenly realised that I hadn’t saved some data which would have been good to include in the report. Usually this costs you only time to reproduce the problem and gather that data again, but sometimes it’s not possible. Either you are not allowed to access the target system anymore or in case of a test environment it might not be even running anymore. In this case you need to accept that your report will be worse as it could have been. To avoid these situations I tried to summarize for myself what is needed to a report and how all relevant data should be stored for a finding. Bear in mind that usually every penetration tester has their own way to keep their data so this here is just my way(or the highway..).
It happens time to time that I need to do penetration test on a production system because the costumer doesn’t have any test environment. That is always a bad start. The explanation is usually that the target system is not a separate application or appliance but it is tightly integrated in the company’s infrastructure. Nevertheless it is very unfortunate from the penetration tester’s point of view. This brings the following limitations in the pentest:
- no insertion in the database that cannot be removed
- no agressive tests
- careful with business logic
For example in a production system it is difficult to decide whether clicking on a submit button will immediately order something for €1000, send out 10000 e-mails or first pop up a confirmation window which might be vulnerable to Cross Site Scripting.