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 "How to Write an Application Code Review Finding"
(→Use a positive tone) |
m (Added navigation to facilitate sequential reading online) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | {{LinkBar | |
+ | | useprev=PrevLink | prev=Reviewing Web Services | lblprev= | ||
+ | | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents | ||
+ | | usenext=NextLink | next=Automated Code Review | lblnext= | ||
+ | }} | ||
+ | __TOC__ | ||
An application security "finding" is how an application security team communicates information to a software development organization. Findings may be vulnerabilities, architectural problems, organization problems, failure to follow best practices or standards, or "good" practices that deserve recognition. | An application security "finding" is how an application security team communicates information to a software development organization. Findings may be vulnerabilities, architectural problems, organization problems, failure to follow best practices or standards, or "good" practices that deserve recognition. | ||
Line 38: | Line 43: | ||
==Sample Report== | ==Sample Report== | ||
− | Below is a sample format for a finding report resulting from a secure code review | + | Below is a sample format for a finding report resulting from a secure code review. |
<!-- | <!-- | ||
Line 163: | Line 168: | ||
+ | {{LinkBar | ||
+ | | useprev=PrevLink | prev=Reviewing Web Services | lblprev= | ||
+ | | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents | ||
+ | | usenext=NextLink | next=Automated Code Review | lblnext= | ||
+ | }} | ||
[[Category:How To]] | [[Category:How To]] | ||
[[Category:OWASP Code Review Project]] | [[Category:OWASP Code Review Project]] |
Latest revision as of 16:55, 9 September 2010
An application security "finding" is how an application security team communicates information to a software development organization. Findings may be vulnerabilities, architectural problems, organization problems, failure to follow best practices or standards, or "good" practices that deserve recognition.
Choose a Great Title
When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as “Add access control to business logic” or “Encode output to prevent Cross-site Scripting (XSS)."
Identify the Location of the Vulnerability
The finding should be as specific as possible about the location in both the code and as a URL. If the finding represents a pervasive problem, then the location should provide many examples of actual instances of the problem.
Detail the vulnerability
The finding should provide enough detail about the problem that anyone can:
- understand the vulnerability
- understand possible attack scenarios
- know the key factors driving likelihood and impact
Discuss the Risk
There is value in both assigning a qualitative value to each finding and further discussing why this value was assigned. Some possible risk ratings are:
- Critical
- High
- Moderate
- Low
Justifying the assigned risk ratings is very important. This will allow stakeholders (especially non-technical ones) to gain more of an understanding of the issue at hand. Two key points to identify are:
- Likelihood (ease of discovery and execution)
- Business/Technical impact
You should have a standard methodology for rating risks in your organization. The OWASP Risk Rating Methodology is a comprehensive method that you can tailor for your organization's priorities.
Suggest Remediations
- alternatives
- include effort required
- discuss residual risk
Include References
- Important note: if you use OWASP materials for any reason, you must follow the terms of our license
Sample Report
Below is a sample format for a finding report resulting from a secure code review.
Review /Engagement reference: |
|||
Package/Component/Class Name |
|||
|
|||
Finding description |
Location(S) |
Severity |
Recommendation |
No input validation of the HTTPRequest object.getID() function.
Lack of input validation may make the application vulnerable to many types of injection |
com.inc.dostuff.java Lines 20, 55,106
com.inc.main.java Lines 34, 99 |
Critical ▪
Required □
Recommended □
Informational □
|
It is critical that this be addressed prior to deployment to production |