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 "Top 10 2007"
(→Downloadable Versions: Added spanish link) |
(→Aim) |
||
| Line 13: | Line 13: | ||
'''Security is not a one-time event'''. It is insufficient to secure your code just once. By 2008, this Top 10 will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in [[Top_10_2007-Where to Go From Here|Where to Go From Here]] for more information. | '''Security is not a one-time event'''. It is insufficient to secure your code just once. By 2008, this Top 10 will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in [[Top_10_2007-Where to Go From Here|Where to Go From Here]] for more information. | ||
| − | '''A secure coding initiative must deal with all stages of a program’s lifecycle'''. Secure web applications are '''''only''''' possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the [ | + | '''A secure coding initiative must deal with all stages of a program’s lifecycle'''. Secure web applications are '''''only''''' possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the [[OWASP_Guide_Project|OWASP Development Guide]], which is essential reading for anyone developing web applications today. |
'''This document is first and foremost an education piece, not a standard'''. Please do not adopt this document as a policy or standard without [mailto:[email protected] talking to us] first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress. Please consider joining or financially assisting with these efforts. | '''This document is first and foremost an education piece, not a standard'''. Please do not adopt this document as a policy or standard without [mailto:[email protected] talking to us] first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress. Please consider joining or financially assisting with these efforts. | ||
Revision as of 23:42, 20 September 2008
Introduction
Welcome to the OWASP Top 10 2007! This totally re-written edition lists the most serious web application vulnerabilities, discusses how to protect against them, and provides links to more information. The OWASP Top 10 has been translated into French. Click Here for the French Translation!
The OWASP Top 10 for Java Enterprise Edition is available for download here
Aim
The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities – a great start to your secure coding security program.
Security is not a one-time event. It is insufficient to secure your code just once. By 2008, this Top 10 will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in Where to Go From Here for more information.
A secure coding initiative must deal with all stages of a program’s lifecycle. Secure web applications are only possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the OWASP Development Guide, which is essential reading for anyone developing web applications today.
This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress. Please consider joining or financially assisting with these efforts.
Acknowledgements
We thank MITRE for making Vulnerability Type Distribution in CVE data freely available for use. The OWASP Top Ten project is led and sponsored by  .
|
Project Lead: Andrew van der Stock (Executive Director, OWASP Foundation)
Co-authors: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP Foundation)
We’d like to thank our reviewers:
- Raoul Endres for help in getting the Top 10 going again and with his valuable comments.
- Steve Christey(MITRE) for an extensive peer review and adding the MITRE CWE data
- Jeremiah Grossman (WhiteHat Security) for peer reviewing and contributing information about the success (or otherwise) of automated means of detection.
- Neil Smithline (OneStopAppSecurity.com) for comments and producing the Wiki version.
- Sylvan von Stuppe for an exemplary peer review.
- Colin Wong, Nigel Evans and Andre Gironda for e-mailed comments.
Summary
| A1 - Cross Site Scripting (XSS) | XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc. |
| A2 - Injection Flaws | Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data. |
| A3 - Malicious File Execution | Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users. |
| A4 - Insecure Direct Object Reference | A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization. |
| A5 - Cross Site Request Forgery (CSRF) | A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. |
| A6 - Information Leakage and Improper Error Handling | Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks. |
| A7 - Broken Authentication and Session Management | Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities. |
| A8 - Insecure Cryptographic Storage | Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. |
| A9 - Insecure Communications | Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. |
| A10 - Failure to Restrict URL Access | Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. |
There are several pages in this document that are not dedicated to a specific vulnerability and hence are not listed in the table. Here is the list of them.
| Top 10 2007 | The main page for the document (this page). Besides providing an introduction, bookmarking the "Summary" section (this can be done by dragging this link to your browser's bookmarks) gives you quick access to the entire document. |
| Top 10 2007-Methodology | A description of the methodology used to select the vulnerabilities for this document. |
| Top 10 2007-Where to Go From Here | Some advice as to how to proceed once you have read this document. |
| Top 10 2007-References | Recommendations for further reading. |
A Note About The Different Versions
While the only official version of the OWASP Top Ten 2007 list is the downloadable English PDF version, OWASP has put together this Wiki that initially contains the same content as the PDF. But OWASP hopes that will change with your help. OWASP encourages community involvement and wants your help to make the Wiki version even better. To aid in this they have put together a brief tutorial to get you started.
Downloadable Versions
You can download the Top 10 2007 (Final) here:
- Looking for a version in another language? We could use your help translating. Contact Andrew van der Stock (vanderaj ...(@)... owasp.org) to help translating the OWASP Top 10 into your language.
