Throughout the course, we learned a number of methods to discover bugs and vulnerabilities in different
types of software and infrastructure, usually at the end of the test you will need to inform the client
with all of the vulnerabilities that you found or with all of the findings.
This is done using a test report.
So basically what we mean by a test report, it's just a document that includes everything that you
found through your engagement so that the client or the admin can go ahead and fix all of the vulnerabilities
and the weaknesses that you found.
These reports are also read by executives a lot of the time.
Therefore, you would need to account for that.
So a good report should be easy enough.
But it's also easy to understand now if you're working as a tester, then the company that you're working
for will probably have their own template and their own standards that you have to follow when writing
a report.
And in many cases, you won't even be doing that.
You'll simply be forwarding your findings to another member in your own team and they will be fill in
the blanks properly in the report.
Therefore, you probably will not need to write one from scratch.
And in many cases you won't even write the actual report that the client sees.
With that being said, I still want to show you how this is done, just to give you an idea of what
a test report looks like.
Now, first of all, before I show you the sample that I have, I'm going to include this repository,
which basically contains a large number of Pantazis reports.
So you could actually look through these for inspiration and just to see the different styles that different
companies follow when making a test report.
So you can click on any of these and you'll find the report and you can actually go through it to learn
how this specific company, you write their reports and maybe you find something that you like that
you would start including in your own report.
So I'm going to include this in the resources of the lecture so you could come back to it for inspiration.
But what I really want to do is walk you through a sample of reports that we use here in security.
Just to give you an idea of the main sections that most reports have.
I will also include this in the resources.
So feel free to modify it and use it or take some elements of it if you want to.
So you'll notice from the repository in here, each company has its own style of writing reports, but
in general there is always a few main sections that you will find in every report.
So starting with the first page right here, we have the covering page.
So again, you can sell this as you want.
You usually have the company logo, you have the title, and then you'll have the date of the report
and the version.
This is very important.
And then we have the company, our company information.
So this report is written by us.
This is our company information.
And then you have in the forcefield, you have the company that you're writing this report for.
So you'd have the company name, you'll have a specific ID for this company.
This is the idea that you identified this company within your own records.
Again, this is probably not something you'll be doing yourself.
You'll be given this idea by your own company.
And then we have contact information for both companies.
So you can see in this company we have this there one and then Tester two with their email addresses.
This could be obviously a bigger list with all of the team that is doing the test and similar to the
company that you're doing the test for.
Again, you have their names, their position in the company and their contact information.
Now, again, keep in mind, you don't always have to style the first page like this, but more or less
usually in the first page, you'll have the title, the date, the version and the contact information.
This is how we do it.
But again, you can do it the way you want and you can draw inspiration from the resource that I'm going
to include here.
Next, we usually have the table of contents again, as you can see, simple stuff usually would have
in any kind of document.
This will help you navigate throughout this whole document.
And like I said in here, we can see the main sections of any protest report.
So it's very important to have an executive summary.
This is a summary of the whole engagement that is designed for less technical people.
So it's supposed to give them an idea of your findings without diving too deep in the technical details.
Then we have an engagement summary where we detail the scope.
So this is what you tested, which parts of their system that you tested, the risk ratings that you
used, and an overview of everything that you found.
So, again, so far, we're not diving deep or simply this is just a summary of the whole engagement.
You'll get a better idea of all of this as I go through the report.
And then in the technical details section, this is where you dive really deep in everything that you
found.
So we basically have a section for every finding.
So as you can see, this is just a sample.
So I only made three findings.
We have initial injection, a cross site request forgery.
Yes.
SRF and an information disclosure.
So as you can see in the first section, we basically just had a summary of everything that we found,
whereas in the technical details were basically breaking down every single finding.
And we're going to talk about how we found it in details, how to replicate it.
You're going to include screenshots, if you can, so that the technical team can understand exactly
the severity of this vulnerability and how to fix it.
You'll notice other companies will include appendix at the end, they will include recommendations where
they will tell you exactly how to fix vulnerabilities.
Like I said, it really depends on the company.
Every single company have their own style and every single company have their own format.
So what I'm showing you right here is just a sample of how we do it.
You can draw inspiration from the resources and in many cases you'll just have to follow the template
that your company has because they don't want you to do it your own way.
So let's go to the next page and you'll see in this page we have the legal information.
And that's why I actually said you'll probably not do this yourself.
You'll never need to do this yourself because you'll have parts of the report like this.
You'll never have to modify and they'll actually be written by the legal team in your company.
So they'll account for anything that could go out of control to make sure that you will not be sued.
If anything goes wrong, it will contain stuff like disclaimers, GDP, our privacy, legal stuff and
all of that stuff that we don't really know very well.
I testers and legal people usually write, and then we have the changelog of the document.
So every time a change is made to the document, you can see we have the date, we have the version
and we have a comment.
Why did we do this change or what's so significant about this change?
So this was the initial report when we made it on January 1st and then on the 10th of January, we made
a second version where we are done with the second stage.
Again, this is just samples.
But just to give you an idea that keeping a changelog of all of the changes that this document goes
through is very, very important.
Not all of the companies do it.
But again, that's just our own choice to add it in our report.
I keep saying this just to give you an idea that there is no set rules to making these kind of documents.
You can add or remove anything you want, but the main parts would be the legal part, the executive
summary and then the technical part.
These will be the main parts of the report.
So now we have the executive summary and you could read through this.
This is not supposed to be long.
So in my opinion, it needs to be a page maximum two pages if you really have to.
And it basically just says we were instructed to test a system.
It will explain how this document is organized, where the first section is less detailed, just to
give you an idea of the risk.
And the second one is detailed for the technical people to understand these risks and fix them and then
were given the risk rating.
So we're assuming this is at high risk based on the vulnerabilities we found.
It will detail the methodology that we followed.
And then we have some charts in here.
Remember, this part is being read by the executives.
These are people that are not very technical most of the time, and they also don't have a lot of time.
So we're including graphs in here to show them the amount of vulnerabilities we found.
So we can see we have five vulnerabilities that are high.
We have 10 that are medium and eight that are low.
So this will give them a really good understanding of the threats that they face.
And then we're going to go into the summary again.
This will still be read by the less technical people.
So, first of all, we're detailing the scope to make sure that we tell them what we tested, even though
they already told us what to test, just so that in case in the future, if something was discovered
outside our scope and they come back to us, we can say, well, this was outside of the scope.
We did not test this next year, including the risk rating.
So you'll have this in every document.
You want me to modify it.
We're basically just saying how we would classify a certain vulnerability as low, medium, high or
critical.
And we're saying, in our opinion, how you should handle the low, medium, high and critical vulnerabilities
you can see for the critical we're saying you need to fix immediately, whereas for the law you need
to fix in the next update cycle.
Again, this is just our own opinion.
Next, we have the findings of review.
So we're still in section one.
This is still for the executives.
We don't need to dive too deep.
So we're just given the vulnerability idea.
And you can see for the first vulnerability, it's critical.
It's an Ezekial injection.
And in many cases, in many reports, they'll actually stop it, saying it's just an ESKIL injection.
We like to actually show the impact in this section because like I said, these guys are not technical.
So if is a injection, they might not know what an ESKIL injection is.
What they care about is the impact of this vulnerability.
Again, they don't have a lot of time, so you need to be straight to the point.
So what we're doing is we're saying it's an natural injection that could lead to authorized database
access.
So now they know with this vulnerability, a hacker can access their database.
This is probably pretty bad.
Another vulnerability that we found is medium and excessive.
SRF again, many reports will stop here, doesn't really explain anything to non-technical people.
So we're saying clients can be forced to submit certain non-critical requests.
That's why it's a media, not non-critical request.
But they can be forced to submit stuff.
And then we have one vulnerability where the HP version is disclosed.
So this is not really very critical because it's not an actual vulnerability that can be exploited to
gain access or expose user data.
But this information could be useful for hackers to chain with other attacks or discover vulnerabilities
for this specific version.
And that's why it's a low.
That's why it doesn't need to be taken care of very urgently, like the critical ones, as we mentioned
above and here.
And feel free to read the text here, you'll see a lot of it is basically just to clear our backs and
make sure that they understand everything that is in the report.
And that would be the end of the summer.
And now we're into the technical details.
So in this section, we're basically having, like I said, a subsection for every single finding that
we have.
And we're diving really deep into the details of this finding.
So you can see this is the actual injection that we mentioned earlier in the summary.
But this time we're actually giving them the URL that is vulnerable.
We're giving them the vulnerable parameter.
We're giving them references to understand what Eskil injection is.
In case they don't understand it, we're giving them the exact request and the exact response that we
got, which made us determined that this particular page is vulnerable to an injection.
Then we're giving them the impact here in details, not just saying that they can access the database.
So we're saying they can access the database.
They can retrieve data that we got access to the user's table.
So you're going to dive in details and you should even include screenshots in here.
If you think they'll be useful in the mitigation section.
We're just giving them a quick recommendation.
Like I said, some companies give detailed recommendations.
This really depends on the engagement as well.
So in this example, we're basically just saying use prepare statements with parameterized queries and
we're giving them a reference to learn how to do that or to understand how it works.
And that's pretty much it.
So you're going to repeat that for every single vulnerability you found?
I'm leaving the rest empty as this is just a sample, but you get the idea.
So you're going to have a subsection for every finding that you have explained everything in details
so they understand the vulnerability and then they can go ahead and fix it.
At the end, many companies would have an appendix and they might have a bigger recommendation section,
like I said, this is our style of writing reports what each company has their own style, if you like.
This may be spent some time going through the sample reports that we have in this repository.
Obviously, I'll include both links for my sample and for the other samples and the resources so you
can go through them yourself and get an idea of what Pennhurst reports look like.
But like I said, in many cases, you'll simply be filling a sample similar to what we have in here.
So you'll never be asked to come up with one from scratch.