Conduct a Web Penetration Test

But before we get into the content, let’s talk about the report format.

Pay Attention to the Report Format

The first step is to check the scoping document to see what was agreed in terms of format. Did you agree to produce a comprehensive written report, a presentation, or a spreadsheet-based action plan?

You may wish to explain in the introduction why you agreed to document everything in a particular format. An informed reader will understand that the report has been designed to meet this client’s specific needs and that it does not necessarily reflect the format and content of other reports you might write.

Your report can become very long, very quickly, especially if you want to include a lot of screenshots or cover all the tests and associated explanations. This is why it’s important to make it easy to read!

Speaking of spelling mistakes, I have a short anecdote to share with you:

In the early months of my career as a consultant, I worked with several project managers who were particularly fussy about the report format and writing style. These are essentially part of overall service quality, and most consulting firms treat them with the same importance as the report content. One of these project managers even told me, “I’ll warn you now that I’m a stickler for format, and if I see more than three mistakes in the report, I won’t read any further.” As you might imagine, he was not kidding, and I had to go through my report again several times before he would proofread it from start to finish!

I usually proofread a deliverable at least three times and even ask someone else on the team to proofread it!

Okay, let’s now move on to the content. While the format makes your report easy to read for your client, it’s the content that really interests them!

Write a Detailed Report

At the beginning of this chapter, I introduced you to the different sections that are expected to appear in a penetration test report:

We’ll have a look at each of these sections in detail.

Section 1: Executive Summary

The purpose of this section is for anyone with access to the report to quickly understand what the main points are:

1. Vulnerabilities affecting the tested application

2. Actions to take to remediate them, whatever the application’s core function

There’s no set structure for writing this section. In my experience, it’s best to start by highlighting the positive points and then move on to the areas for improvement.

When addressing the issues that need to be corrected, it’s a good idea to keep things at a very high level and to link the identified vulnerabilities as far as possible to a business problem or risk. We can talk about SQL injections or command execution, but the emphasis should be on how attackers can exploit these vulnerabilities, rather than on the vulnerability itself. Just mention the most important points, not the details that don’t really affect the application.

After reading the executive summary, the client should have a clear understanding of what we’ve managed to achieve by testing the application. They should also have all the information they need to decide, for example, whether the application can go into production as is or whether they first need to implement corrective measures.

Section 2: Test Results

It contains two subsections:

1. Vulnerabilities, with:

• The name or title you've given to the vulnerability.

• Details of the vulnerability, giving enough information to quickly locate the vulnerability in the application.

• The criticality of the vulnerability, such as by indicating its CVSS score.

2. Recommendations, with:

• The name or title you've given to the recommendation.

• Details of the recommendation, what teams are expected to do, and (for technical recommendations) an example or link to an article or resources to help implement it.

• The importance of the recommendation in the overall action plan.

• The relative cost or complexity you estimate for implementing the correction.

• The reference to the vulnerabilties it corrects or mitigates.

Section 3: Testing Procedure

This section is usually the most extensive part of the report. It details and explains all the tests carried out on the target and whether they led to the discovery of a vulnerability or, conversely, to proof that no vulnerability exists.

There is some debate among pentesters about what the test details should contain, a debate I myself have had with other colleagues and competitors, and which I saw come up again later on Twitter:

Here’s the transcription of this exchange for screen readers:

@CristiVlad25: Pentesters, what do you write in the report when there are no findings?

@_nwodtuhs: Unpopular opinion, a pentest report should always include what’s been tested, should the result be a vulnerability or a conformity. That way, the client knows what’s been tested and, whatever the results, it demonstrates the quality of the pentest.

Regardless of your chosen level of detail, the approach may be either:

• linear and chronological, as suggested by some national cybersecurity agencies, or

• split into main sections covering each different type of vulnerability (as presented in this course). Websites lend themselves quite well to this type of approach, unlike other types of pentesting.

In this section of the report, you’ll provide details on the following:

1. All the evidence of your work, including the vulnerabilities, payloads, and even the tools you used.

2. Evidence that the application is protected or that there are no vulnerabilities.

If another pentester revisits the application a few months or even years after you have, they must be able to understand, from your report, exactly what you did and what you found. At no point should that pentester be thinking “What on earth did they do here?” or “How the heck did they come up with that result?”

I structure my approach to each test as follows:

• An explanation of what I’m looking for, why I’m looking for it, and how it works.

• The test for the vulnerability in question.

• An interpretation of the test results, whether positive or negative.

Let’s Recap!

• Before writing the report, check with your client that the intended format meets their needs.

• My recommended approach is to provide a comprehensive deliverable that includes an executive summary, the results of the vulnerabilities found, and the associated recommendations, followed by a detailed description of the tests that were carried out. This approach is in line with recommendations made by some national cybersecurity agencies.

• Pay particular attention to the format of the report and proofread it several times if necessary!

• Each section of the report is intended for a specific audience:

  • The executive summary is for senior executives, department heads, and business people with little or no specific IT or security knowledge.

  • The list of vulnerabilities and recommendations is for technical teams who will have to implement the recommendations and understand why the vulnerability exists.

  • The test details are intended for the technical community who will need to understand the entire pentester process and also for future pentesters or other auditors who may need the results of your pentest for another assignment.

In the next chapter, we’ll look more closely at how to approach and formulate the recommendations so that they are as actionable as possible for the client’s teams.