1BO4r2U

207 208
Web Application Penetration Testing
Web Application Penetration Testing
5 Reporting
Performing the technical side of the assessment is only half
of the overall assessment process. The final product is the
production of a well written and informative report. A report
should be easy to understand and should highlight all the
risks found during the assessment phase.
http:/server/StoragePOC.html#
URL PoC:
Tools
• Firebug - http://getfirebug.com/
• Google Chrome Developer Tools - https://developers.google.com/
chrome-developer-tools/
• OWASP Zed Attack Proxy (ZAP) - https://www.owasp.org/index.
php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding
vulnerabilities in web applications. It is designed to be used by people
with a wide range of security experience and as such is ideal for developers
and functional testers who are new to penetration testing.
ZAP provides automated scanners as well as a set of tools that allow
you to find security vulnerabilities manually.
References
OWASP Resources
• OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/
index.php/HTML5_Security_Cheat_Sheet
Whitepapers
• Web Storage Specification: http://www.w3.org/TR/webstorage/
Performing the technical side of the assessment is only half of the
overall assessment process. The final product is the production
of a well written and informative report. A report should be easy
to understand and should highlight all the risks found during the
assessment phase. The report should appeal to both executive
management and technical staff.
The report needs to have three major sections. It should be created
in a manner that allows each separate section to be printed and
given to the appropriate teams, such as the developers or system
managers. The recommended sections are outlined below.
1. 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. The language
used should be more suited to people who are not technically
aware and should include graphs or other charts which show the
risk level. Keep in mind that executives will likely only have time to
read this summary and will want two questions answered in plain
language: 1) What’s wrong? 2) How do I fix it? You have one page
to answer these questions.
The executive summary should plainly state that the vulnerabilities
and their severity is an input to their organizational risk management
process, not an outcome or remediation. It is safest to
explain that tester does not understand the threats faced by the
organization or business consequences if the vulnerabilities are
exploited. This is the job of the risk professional who calculates
risk levels based on this and other information. Risk management
will typically be part of the organization’s IT Security Governance,
Risk and Compliance (GRC) regime and this report will simply provide
an input to that process.
2. Test Parameters
The Introduction should outline the parameters of the security
testing, the findings and remediation. Some suggested section
headings include:
2.1 Project Objective: This section outlines the project objectives
and the expected outcome of the assessment.
2.2 Project Scope: This section outlines the agreed scope.
2.3 Project Schedule This section outlines when the testing commenced
and when it was completed.
2.4 Targets: This section lists the number of applications or targeted
systems.
2.5 Limitations: This section outlines every limitation which was
faced throughout the assessment. For example, limitations of
project-focused tests, limitation in the security testing methods,
performance or technical issues that the tester come across
during the course of assessment, etc.
2.6 Findings Summary This section outlines the vulnerabilities
that were discovered during testing.
2.7 Remediation Summary This section outlines the action plan
for fixing the vulnerabilities that were discovered during testing.
3. Findings
The last section of the report includes detailed technical information
about the vulnerabilities found and the actions needed to
resolve them. This section is aimed at a technical level and should
include all the necessary information for the technical teams to
understand the issue and resolve it. Each finding should be clear
and concise and give the reader of the report a full understanding
of the issue at hand.
The findings section should include:
• Screenshots and command lines to indicate what tasks were
undertaken during the execution of the test case
• The affected item
• A technical description of the issue and the affected function
or object
• A section on resolving the issue
• The severity rating [1], with vector notation if using CVSS
The following is the list of controls that were tested during the
assessment: