Web Application Penetration Tests - Reporting
3 likes13,833 views
The document outlines the process and importance of penetration testing reporting, detailing key elements such as the engagement scope, vulnerability identification, and the structure of the final report. It emphasizes that reporting should begin early in the engagement and be tailored to the audience, providing executive summaries for corporate management and detailed technical reports for developers. Additionally, it discusses the use of tools like Netsparker for organizing and customizing reports based on the target audience's needs.
Web Application Penetration Tests - Reporting
- 2. Reporting In this next section, we will address the following process: • Scope of Engagement • Information Gathering • Vulnerability Identification • Exploitation • Post Exploitation • Reporting 2
- 3. Reporting The Penetration Report is the ultimate deliverable from your engagement. By hiring a penetration tester or a penetration testing firm, a client is usually interested in: • Knowing the status of the security of the assets in scope • Knowing what is vulnerable • Knowing what needs to be fixed first 3
- 4. Reporting Reporting assists the customer in not only understanding the issues with their environment, but it can also help them to budget necessary resources and dollars to the remediation and continued secure development of their software. Many times, reporting can become a collaborative process, as project managers and technical teams may want to close out the high or critical findings very quickly before reports are shared to executive management. 4
- 5. Reporting Project teams can take reporting and ensure that the same coding issues are not occurring in similar projects. Development teams can utilize reports to ensure that their Software Development LifeCycle (SDLC) processes and procedures address the appropriate changes that need to occur to ensure similar issues do not occur in future projects as well. Compliance teams can utilize the report as a checkpoint as to how teams are addressing compliance and regulatory requirements for the organization. 5
- 6. Reporting Knowing that you used a reverse TCP shell once you managed to exploit an RFI may not be of critical importance to the client. The judgment of the overall engagement is based solely upon the final report that you turn over. You will want your report to be: exhaustive, clear, on-time, good looking and adherent to client's goal. 6
- 7. Reporting There is not a prescribed or standard structure to penetration testing reports. However, there are best practices, do’s and don’ts and critical aspects that should be taken care of while writing a report. What follows is a plethora of advice, criteria and rules; the fruit of years of our experience in the field. 7
- 8. Reporting The reporting phase begins at the moment you sign the Rules of Engagement with your client. This is the right time to put together a few pages describing the engagement and the client’s goals. This Engagement Summary is something that is great to have in the Executive Summary section of the report. We will see in a moment what the Executive Summary should look like. 8
- 9. Reporting Reporting is often (mistakenly) believed to be the last chronological step of an engagement. This is both incorrect and dangerous. When you create your report as a last step you will forget important details. Also, if the engagement is big enough or time has run out, you might simply not be allowed to perform anymore tests. Now, you are not able to double-check this software version or that open port. This does not mean that during your tests you have to keep stopping to write your report! 9
- 10. Reporting While you perform your tests you will have to collect and organize your information methodically. This information will be the core of your report. So, by collecting and storing this information in a precise and organized way, you will have already contributed to the reporting phase. At the end, you simply need to gather up and present this information in a readable and professional format. Tools like Netsparker, will help you to keep all the information well organized but also to automatically generate readable reports. 10
- 11. Reporting Once you understand who will read your report and what kind of information they are actually interested in, you can match your target audience groups with the actual report structure. A typical structure is laid out like this: Executive Summary Vulnerability report Remediation Report 11
- 12. Reporting The Executive Summary is where you talk to the corporate types or, in general, give a brief and concise overview about the whole engagement. If you agreed to use metrics meaningful to the organization, make sure that you make the current level of security, according to these metrics, visible in the first two pages of your executive summary. 12
- 13. Reporting The Executive level of a company has zero time to invest in your philosophical approach to security. Nor it is interested in which open source “pwnsauce” tool you used. You should, instead, use graphs, charts, stats and tables. Text should only be used to explain your charts and to give a final estimation on the state of security. 13
- 14. Reporting The Vulnerability Report is often also called the Technical report and is where each vulnerability found in the web application is dealt with in greater detail. This part will be read by technicians (sometimes even managers) and it is used to explain, in specific detail, what is wrong with the organization’s security. You will be able to talk in technical terms about specific vulnerabilities, exploitations, affected hosts (or domains or anything in-scope), attack vectors, etc. 14
- 15. Reporting You have different options about how you want to arrange the information within this section. In web application penetration tests you often have a small number of vulnerabilities affecting a large number of different pages in different domains. 15
- 16. Reporting In other cases, you will have only one target in scope affected by a large number of different vulnerabilities. Be prepared to adjust your layout according to each situation. In the first case you would report vulnerabilities by their type. Reporting on vulnerabilities by type lets you concentrate more on the vulnerability and less on the target IP/Server/Website affected. 16
- 17. Reporting If vulnerabilities are heterogeneous, or the number of targets in scope is little, you can arrange the above information on a per- target basis (instead of reporting vulnerabilities by type). When the scope of the test is a web application with many URLs, you will want to pick the Vulnerability by type model (sec. 2.2.2.3). In this case you will have a section for each vulnerability and then list all the URLs that are affected by that particular vulnerability. 17
- 18. Reporting The Remediation report is the place to talk to the developers in charge of fixing the vulnerabilities that you have proved exploitable in the Vulnerability report. This is where you can prove yourself as a real professional and not just a hacker; you will help the organization to find the right solution to their issues. 18
- 19. Reporting In this section you can work on two different time horizons: short term and long term. In the short term you want the remediation team to address the most important vulnerabilities as soon as possible. You may suggest that your client provides you with an emergency phone number where you can immediately contact a developer, should you discover vulnerabilities that put the organization’s vital assets at risk. 19
- 20. Reporting You can also suggest long-term actions, like: • implementation of SSDLC (Secure Software Development Lifecycle) • the employment of security checks early in the business or development processes • or the use of different platforms, versions or frameworks Long-term actions will bring benefits in the long run, but are generally things the organization will not be accomplish in the next 6-12 months and certainly not without a good chunk of investment of both time and money. 20
- 21. Reporting Providing suggestions on how to remediate common vulnerabilities is usually pretty trivial. If the vulnerability exploited was in a publicly available web application, you will just add references to available patches, upgrades, hotfixes or workarounds. 21
- 22. Reporting You usually find all you need within vulnerability databases or in the official security advisories. If the application is custom-coded, you will have to suggest patches to the code or solutions according to the type of vulnerability and the web application environment. 22
- 23. Reporting How you arrange the information in this section should reflect the approach you used during the vulnerability report. If you have listed your vulnerabilities by type, you would do the same here. You will have to prioritize your remediation plan according to the impact level that you assigned and stuck within the vulnerability report. Make sure that, the first issues on your list are the most important. 23
- 24. Reporting Report structure and content as we have seen in previous slides is very important. If a combined report is required by the customer, there are standard formats that can be followed such as that in the OWASP testing guide. 24
- 25. Reporting Per OWASP, a comprehensive report can contain these elements: • Executive Summary: the executive summary sums up the overall findings of the assessment and gives business managers and system owners a high level view of the vulnerabilities discovered. • Test Parameters: summarize agreed upon testing parameters from the scoping exercise. It include details from the scoping in sections such as Objective, Scope, Schedule, Targets, Limitations, Findings Summary, and Remediation Summary • Findings: detailed technical information regarding all the issues discovered during the tests including supporting information to provide as much information as possible for each issue. 25
- 26. Reporting As said before, Netsparker offers the ability to automatically generate reports. By clicking on the "Reporting" button on the top bar, you will be provided with many different types of reports. Therefore, depending on our target audience, we will select different outputs. 26
- 27. Reporting This is a sample of the Executive Summary report. This report contains only high level reference information with no in-depth details. 27
- 28. Reporting This is a sample of the detailed scan report. The detailed scan report lists all vulnerabilities in detail. Links relate summary and detailed content within the report. 28
- 29. Reporting You can also export the findings in different formats, such as CSV and XML. Thanks to formats like these, you will be able to parse the results and use scripts or external tools to extract, navigate and inspect only the information you want. 29
- 30. Report Policy Another very useful feature that Netsparker offers when creating a report is the Report Policy. Report policy is a list of reporting settings for both the web security scan results and reports. Thanks to this option you can specify which vulnerabilities should Netsparker report in the scan results, edit or the severity level of a vulnerability, add remedy instructions, modify the vulnerability template and much more. 30
- 31. Report Policy These settings may be very useful to customize the reports, depending on who will be the target audience. Moreover, the same vulnerability may have a different security level depending on the application itself. For example, an XSS in a web application that does not require users to authenticate has a lower security level if compared with an XSS on an mission-critical web application like an e-commerce web site. 31
- 32. Report Policy It is important to know that the Report Policy changes only the way the findings are presented in the report. Therefore, if the scanner finds a specific vulnerability, but we don't want to report it, the vulnerability is only hidden from the report. This means that if we select to create a report with the default settings, the vulnerability will be included. 32
- 33. Report Policy Creating a new Report Policy is very simple. We can do it before actually scanning the application, or after the scan completes. 33 BEFORE AFTER
- 34. Report Policy A window like the following will appear. Here we can create a new Report Policy or clone an existing one. 34
- 35. Report Policy In our example we will clone the existing default policy and change its name to "Only critical findings". Then in the bottom-left area we will exclude all the findings that are not critical, by simply unchecking the checkbox next to the vulnerability name. 35
- 36. Report Policy As said before, we can edit the vulnerability template as well as the information in it. To do so we just need to select the vulnerability and click on the section that we want to edit. 36
- 37. Report Policy Notice that all the information can be edited. Therefore, we can modify the security level as well as the classification information. 37
- 38. Report Policy Once you are finished editing a vulnerability template, click on the Save button to save your changes or Discard to undo them. You can use the Restore button to restore the selected vulnerability’s template from the Default Report Policy. Now we can create our report by closing the current window and clicking on Reporting-> Detailed Scan Report: 38
- 39. Report Policy As you can see, this feature is fundamental to the customization of your reports. Depending on who is going to read it you will have different formats containing different information. If you want to read more about Report Policy, please use the following resource. 39