This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Reporting"
| Line 1: | Line 1: | ||
{{Template:OWASP Testing Guide v2}} | {{Template:OWASP Testing Guide v2}} | ||
| − | + | Performing the assessment is only half of the overall process; the final product is the production of a well-written, and informative, report. A report should be easy to understand and highlight all the risks found during the assessment phase and appeal to both management and technical staff | |
| − | + | The report needs to have three major sections and be created in a manner that allows each section to be split off and printed and given to the appropriate teams, such as the developers or system managers. | |
| − | The | + | The sections are: |
| + | |||
| + | '''I. Executive Summary''' | ||
| − | + | The executive summary sums up the overall findings of the assessment and gives managers, or system owners, an idea of the overall risk faced. 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. It is recommended that a summary be included, which details when the testing commenced and when it was completed. | |
| − | |||
| − | + | Another section, which is often overlooked, is a paragraph on implications and actions. This allows the system owners to understand what is required to be done in order to ensure the system remains secure. | |
| − | + | '''II. Technical Management Overview''' | |
| − | + | The technical management overview section often appeals to technical managers who require more technical detail than found in the executive summary. This section should include details about the scope of the assessment, the targets included and any caveats, such as system availability etc. | |
| + | This section also needs to include an introduction on the risk rating used throughout the report and then finally a technical summary of the findings. | ||
| − | ''' | + | '''III Assessment Findings''' |
| − | + | The last section of the report is the section, which includes detailed technical detail about the vulnerabilities found, and the approaches needed to ensure they are resolved. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and be able to solve it. | |
| − | + | The findings section should include: | |
| − | + | - A reference number for easy reference with screenshots | |
| + | - The host/application | ||
| + | - The risk rating and impact value | ||
| + | - A technical description of the issue | ||
| + | - A section on resolving the issue | ||
| − | Some may argue that the tools used by other professionals when providing a service (Doctors, Mechanics, Lawyers etc | + | Each finding should be clear and concise and give the reader of the report a full understanding of the issue at hand |
| + | |||
| + | |||
| + | '''IIII Toolbox''' | ||
| + | |||
| + | This section is used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts/code are utilized during the assessment, it should be disclosed in this section or noted as attachment. | ||
| + | |||
| + | Some may argue that the tools used by other professionals when providing a service (Doctors, Mechanics, Lawyers etc.) Are not disclosed so why should we do this as a standard practice? I answer that question with this, the OWASP Testing Guide is FREE and OPEN-SOURCE and all of the sections of this guide provide a manual explanation of how to test. Some will automate the testing process to reach a result but, tools are only 40-60% of the work. We believe this guide is to provide details and best practices in not only in conducting testing but also as a information security professional, full-disclosure of how a result was reached as there are always false positives right ;) | ||
Revision as of 13:05, 17 December 2006
OWASP Testing Guide v2 Table of Contents
Performing the assessment is only half of the overall process; the final product is the production of a well-written, and informative, report. A report should be easy to understand and highlight all the risks found during the assessment phase and appeal to both management and technical staff
The report needs to have three major sections and be created in a manner that allows each section to be split off and printed and given to the appropriate teams, such as the developers or system managers.
The sections are:
I. Executive Summary
The executive summary sums up the overall findings of the assessment and gives managers, or system owners, an idea of the overall risk faced. 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. It is recommended that a summary be included, which details when the testing commenced and when it was completed.
Another section, which is often overlooked, is a paragraph on implications and actions. This allows the system owners to understand what is required to be done in order to ensure the system remains secure.
II. Technical Management Overview
The technical management overview section often appeals to technical managers who require more technical detail than found in the executive summary. This section should include details about the scope of the assessment, the targets included and any caveats, such as system availability etc. This section also needs to include an introduction on the risk rating used throughout the report and then finally a technical summary of the findings.
III Assessment Findings
The last section of the report is the section, which includes detailed technical detail about the vulnerabilities found, and the approaches needed to ensure they are resolved. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and be able to solve it.
The findings section should include:
- A reference number for easy reference with screenshots - The host/application - The risk rating and impact value - A technical description of the issue - A section on resolving the issue
Each finding should be clear and concise and give the reader of the report a full understanding of the issue at hand
IIII Toolbox
This section is used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts/code are utilized during the assessment, it should be disclosed in this section or noted as attachment.
Some may argue that the tools used by other professionals when providing a service (Doctors, Mechanics, Lawyers etc.) Are not disclosed so why should we do this as a standard practice? I answer that question with this, the OWASP Testing Guide is FREE and OPEN-SOURCE and all of the sections of this guide provide a manual explanation of how to test. Some will automate the testing process to reach a result but, tools are only 40-60% of the work. We believe this guide is to provide details and best practices in not only in conducting testing but also as a information security professional, full-disclosure of how a result was reached as there are always false positives right ;)
APPENDIX A
| Category | Ref Number | Name | Finding | Affected Item | Comment/Solution | Risk Value |
| Information Gathering | Application Discovery | |||||
| Spidering and googling | ||||||
| Analisys of error code | ||||||
| SSL/TLS Testing | ||||||
| DB Listener Testing | ||||||
| File extensions handling | ||||||
| Old, backup and unreferenced files | ||||||
| Business logic testing | ||||||
| Authentication Testing | Default or guessable account | |||||
| Brute Force | ||||||
| Bypassing authentication schema | ||||||
| Directory traversal/file include | ||||||
| Vulnerable remember password and pwd reset | ||||||
| Logout and Browser Cache Management Testing | ||||||
| Session Management Testing | Session Management Schema | |||||
| Session Token Manipulation | ||||||
| Exposed Session Variables | ||||||
| Session Riding | ||||||
| HTTP Exploit | ||||||
| Data Validation Testing | Cross site scripting | |||||
| HTTP Methods and XST | ||||||
| SQL Injection | ||||||
| Stored procedure injection | ||||||
| ORM Injection | ||||||
| LDAP Injection | ||||||
| XML Injection | ||||||
| SSI Injection | ||||||
| XPath Injection | ||||||
| IMAP/SMTP Injection | ||||||
| Code Injection | ||||||
| OS Commanding | ||||||
| Buffer overflow | ||||||
| Incubated vulnerability | ||||||
| Denial of Service Testing | Locking Customer Accounts | |||||
| User Specified Object Allocation | ||||||
| User Input as a Loop Counter | ||||||
| Writing User Provided Data to Disk | ||||||
| Failure to Release Resources | ||||||
| Storing too Much Data in Session | ||||||
| Web Services Testing | XML Structural Testing | |||||
| XML content-level Testing | ||||||
| HTTP GET parameters/REST Testing | ||||||
| Naughty SOAP attachments | ||||||
| Replay Testing | ||||||
| AJAX Testing | AJAX Vulnerabilities |
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents
