*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#Users_and_Adopters OWASP Top Ten Project - Users and Adopters] and [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=How_Are_Companies.2FProjects.2FVendors_Using_the_OWASP_Top_10.3F How Are Companies/Projects/Vendors Using the OWASP Top_10]

Revision as of 12:30, 7 September 2010

This page captures important references to OWASP in official, or otherwise important, documents. It does not include presentational or educational materials, sales literature, forum messages, blog postings, news stories or press releases.

Hyperlinks have not been added within the text, other than those automatically added by the wiki, to reduce the risk of mis-interpretation. Please read the source documents in full to understand the context. Entries in each each category are ordered by organisation name ascending, then date ascending.

In "3.2 Application security best practices", "... The following elements should be considered as part of the SDLC for application security: ... Adopt and apply secure design and coding practices for web application software development. Guidance is available from numerous sources including ... and the Open Web Application Security Project (OWASP) http://www.owasp.org." and in "5 Resources", "Open Web Application Security Project (OWASP): http://www.owasp.org ... OWASP Testing Guide v2: http://www.owasp.org/images/e/e0/OWASP_Testing_Guide_v2_pdf.zip".

In "Pre-configuration Checklist", "Educated developers about writing secure code ... OWASP Top Ten - http://www.owasp.org/index.php/OWASP_Top_Ten_Project", and in "1.3 ModSecurity Core Rules Overview", "... Description ... You can learn more about the pros and cons of a negative security model in the presentation 'The Core Rule Set: Generic detection of application layer', presented at OWASP Europe 2007 ... Attack Detection ... Generic Attack Detection - Detect application level attacks such as described in the OWASP top 10. These rules employ context based patterns match over normalized fields. Detected attacks include:...", and in "1.15 Implementing Mod_SSL", "... Action ... The openssl command can be very useful in debugging and testing the SSL configurations. See http://www.openssl.org/docs/apps/ciphers.html as well as OWASP testing tips http://www.owasp.org/index.php/SSL/TLS_Testing:_support_of_weak_ciphers ...".

In "Section III. Operating in the Cloud - Domain 10: Incident Response, Notification, and Remediation", "There are other types of incidents that can affect an application in the cloud, which relate to data access, but stand alone as potentially serious for a user, and they are the OWASP Top 10 security vulnerabilities." and "The application framework can also provide components that provide protection against OWASP vulnerabilities.", and in "Domain 11: Application Security", "References... OWASP Top Ten Project, http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project".

In "Security Architecture - Application Security (SA-04)", "Applications shall be designed in accordance with industry accepted security standards (i.e., OWASP for web applications) and complies with applicable regulatory and business requirements.".

In "PaaS - Tools and Services", "Web-based, n-Tier applications have a rich body of knowledge about common types of vulnerabilities and their mitigation through groups such as the Open Web Application Security Project (OWASP), but similar knowledge bases for PaaS environments are scarce and will need time to mature." and in "References" "OWASP Top Ten Project, http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project".

Translation: In "II - Web technologies, essential, but carrying new risks - II.3 - Regulations and responsibilities", "Consequently, the provision of an application service by a company may engage the responsibility [4] ... [4] https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex OWASP Secure Software Contract Annex : This appendix of contract is intended to help the developers of software and their customers to negotiate important contractual conditions relating to the integrity of the software to be developed or deliver. The reason is that nothing is envisaged in most contracts, the parties having often radically different points of view on what was initially indeed agreed. In fact, the clear definition of the responsibilities and limits for each one are the best way of ensuring itself than the parts can make decisions informed on the way of proceeding.", in "IV - The main vulnerabilities of Web applications - IV.3 - The information leakage", "For more details on the vulnerabilities of Web applications, the reader may refer to the Top Ten of the OWASP [6] ... [6] http://www.owasp.org/index.php/OWASP_Top_Ten_Project", in "V - Which good practices for implementing a secure Web application? - V.2 - Identification of needs and risk assessment", "A first costing can be realized at this stage in order to remain coherent with the objectives of the control of work, by using a methodology like OpenSAMM, which makes it possible to estimate costs for the various stages of the development cycle [7] ... [7] http://www.opensamm.org/" and "Methods and modeling tools available threats exist to facilitate this. [8] ... [8] http://www.owasp.org/index.php/Threat_Risk_Modeling", in "V.3 - Design and Implementation", "The teams can also refer to the OWASP Guide to Build and Implement Secure Web Applications [9] ... [9] http://www.owasp.org/index.php/Category:OWASP_Guide_Project", in "VI - Web Application Security checking - VI.2.2 - Code Review", "The OWASP published a Web Applications' code review' handbook [10] ... [10] http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project", in "VI.2.3 - PenTest", "For more information, one can consult the Web Applications Security test' handbook published by the OWASP [11] ... [11] http://www.owasp.org/index.php/Category:OWASP_Testing_Project".

In "Web applications - Guidance", "G#101 3.6.2.14. Agencies are recommended to follow the documentation provided in the Open Web Application Security Project (OWASP) guide to building secure Web applications and Web services.", in "Web applications - Rationale", "Web applications 3.6.2.16. The OWASP guide provides a comprehensive resource to consult when developing Web applications." and in "Web applications - References", "3.6.2.17. Further information on Web application security is available from the OWASP at http://www.owasp.org.".

In '6.1.6 Developer Issues/Browser Vendors', 'There already exists quite a large body of development best-practice and descriptions of common pitfalls so, rather than re-inventing the wheel, we would refer the reader to the following as examples: The OWASP Guide to Building Secure Web Applications (84), ...', in '5.5.1 Fraudulent Pedigree/Provenance - 5.5.1.2 Example 2: Control of Botnets via Mashups', 'Mashups are perfectly suited to massively distributed systems with untraceable control structures and are therefore likely to lead to a variety of related attacks (see Use of Web 2.0 technologies to control botnets (38) and ...' and in '8 References and Links', '38. Use of Web 2.0 technologies to control botnets. http://www.owasp.org/images/0/02/OWASP_Day_Belgium_2007-pdp.ppt ' and '84. The OWASP Guide to Building Secure Web Applications v2. http://www.owasp.org/index.php/Category:OWASP_Guide_Project '.

In "3.2 SQL Injection", "The OWASP Foundation has produced two tools that can be used to learn about and analyse attacks. The WebGoat application has been developed to demonstrate web application security errors, including SQL injection, and educate developers in how to avoid them. A web proxy, such as OWASP’s WebScarab, is needed to complete some of the WebGoat activities. Such a proxy is used to intercept communications between the browser and application, providing a means of changing the data in each message. Where appropriate examples have been taken (with permission) from the WebGoat application and WebScarab proxy output.", extensive use of screen captures from WebGoat and WebScarab, in "6.4 Education", "The key contributors in SQL injection protection are usually the application and web developers and system administrators... There are free resources on the Internet to encourage a better awareness of SQL injection techniques and guides on how to avoid it. Two examples of such free resources are OWASP Foundation’s WebGoat and ...", in "7 Acknowledgements", "Thanks to the OWASP Foundation’s WebGoat Project and WebScarab Project for their permission to use examples from these tools in this paper. They are published under the Creative Commons Licence" and in "8 References", "[i] OWASP WebGoat Project, OWASP Foundation, 15 January 2009, http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project [j] OWASP WebScarab Project, OWASP Foundation, 17 November 2008, http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project".

GovCertUK is the UK Government Emergency Response Team and is part of CESG.

In "Methodologies", "There are a number of open source penetration testing methodologies that can be used as a reference when examining provider methodologies. Examples include... OWASP - Open Web Application Security Project (http://www.owasp.org)".

In "6.4 Smart Grid Cyber Security Strategy", "The initial draft list of vulnerability classes was developed using information from several existing documents and websites, e.g., NIST SP 800-82 and the Open Web Application Security Project (OWASP) vulnerabilities list." and in "8 List of Acronyms", "OWASP Open Web Application Security Project".

In "1.4.2 Performance of a risk assessment of the Smart Grid, including assessing vulnerabilities, threats and impacts.", "The initial draft list of vulnerability classes was developed using information from several existing documents and websites, e.g., NIST SP 800-82 and the Open Web Application Security Project (OWASP) vulnerabilities list.", in "Appendix C - NIST CSCTG Vulnerability Classes", "As input to the classification process, we used many sources of vulnerability information, including NIST 800-82 and 800-53, OWASP vulnerabilities, CWE vulnerabilities, attack documentation from INL, input provided by the NIST CSCTG Bottoms-Up group, and the NERC CIP standards.", in "C.3.1.1. Code Quality Vulnerability", "Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an attacker it provides an opportunity to stress the system in unexpected ways (OWASP page)", in "C.3.1.2. Arbitrary code execution Authentication Vulnerability", "Examples... Enrollment attacks (OWASP page Comprehensive list of Threats to Authentication Procedures and Data)", in "C.3.1.5. Environmental Vulnerability", "This category includes everything that is outside of the source code but is still critical to the security of the product that is being created. Because the issues covered by this kingdom are not directly related to source code, we separated it from the rest of the kingdoms. (OWASP page)", in "C.3.1.11. Path Vulnerability", "This category is for tagging path issues that allow attackers to access files that are not intended to be accessed. Generally, this is due to dynamically construction of a file path using unvalidated user input (OWASP page).", in "C.3.1.14. Sensitive Data Protection Vulnerability", "Please note that this category is intended to be different from access control problems, although they both fail to protect data appropriately. Normally, the goal of access control is to grant data access to some users but not others. In this category, we are instead concerned about protection for sensitive data that are not intended to be revealed to or modified by any application users. Examples of this kind of sensitive data can be cryptographic keys, passwords, security tokens or any information that an application relies on for critical decisions (OWASP page).", in "C.4.1.1. API Abuse", "An API is a contract between a caller and a callee. The most common forms of API abuse are

caused by the caller failing to honor its end of this contract (OWASP page)" and "For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated (OWASP page)." and in "References", "Open Web Application Security Project (OWASP) http://www.owasp.org/index.php/Category:Vulnerability".

"... One well-respected industry source is the Open Web Application Security Project (OWASP), an open community dedicated to application security. OWASP's extensive library and collection of tools is freely available at http://www.owasp.org. A great place to start is the OWASP Top Ten Project (http://www.owasp.org/index.php/OWASP_Top_Ten_Project). The OWASP document provides a list of critical web application security flaws and detailed suggestions for remediation. See inset box for a brief summary" and "... The Open Web Application Security Project (OWASP), an open community dedicated to application security, has developed a list of the top ten web application vulnerabilities. This list serves to educate managers, developers, and administrators to these most common vulnerabilities in the hopes of improving security. The list is summarized below...".

In "What can an Application Programmer do?", "A well-respected source of information on web application security, to include SQL injection issues, is the Open Web Application Security Project (OWASP). At a minimum, implement the following OWASP recommendations: ..." and in "Detecting SQL Injection Vulnerabilities and Attacks", "... Information on how to go about testing for SQL injection vulnerabilities can be found on the OWASP website at http://www.owasp.org/index.php/Testing_for_SQL_Injection.".

This is one of a series of fact sheets from the NSA - see also SOA/Web Services below.

In Requirement 6: Develop and maintain secure systems and applications, "6.3.7 Review of custom code..." mention in "6.3.7b ...Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide...". And "6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.", specifically "6.5.a Obtain and review software development processes for any web-based applications. Verify that processes require training in secure coding techniques for developers, and are based on guidance such as the OWASP guide (http://www.owasp.org)." and the OWASP Top Ten 2007 listed as "6.5.1 Cross-site scripting (XSS), 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws, 6.5.3 Malicious file execution, 6.5.4 Insecure direct object references, 6.5.5 Cross-site request forgery (CSRF), 6.5.6 Information leakage and improper error handling, 6.5.7 Broken authentication and session management, 6.5.8 Insecure cryptographic storage, 6.5.9 Insecure communications, 6.5.10 Failure to restrict URL access".

In "Recommendation 2.6: Implement security based on transparent, trusted and proven solutions", "...Best practice information system development and management processes such as: ... Open Web Application Security Project (OWASP)—an open-source project dedicated to finding and fighting the causes of insecure software. The OWASP Guide provides methodology and processes for..." and in the checklist "Trusted and proven information system development processes such as ITIL, OWASP and CIS (see page 44 for a definition)—are used or considered when developing information systems".

In "Goal to prevent cyber attacks from occurring", "At the national level, implement regulations which require 1. any organisation hosting a commercial web site (as opposed to a web page) to adhere to web application security standards, such as those by OWASP..."

In the section "Industry Review" of "Summary of Investigation", OWASP mentioned in paragraph 344 "we learned that an organization known as the Open Web Application Security Project (OWASP) promotes the development of secure applications and has created several guidelines addressing issues of session management... OWASP recommends to website creators that sessions should timeout after 5 minutes for high-value applications, 10 minutes for medium-value applications, and 20 minutes for low-value applications. Although OWASP has not provided actual definitions for high-, medium-, or low-value data, it does cite ... as examples of high-value data and ... as examples of low-value data." and in paragraph 345 "...our Office's review of how various websites manage sessions indicates that the OWASP guidelines are not widely used in the industry..."

Project Requirements

International, national governmental and other significant specification, invitation to tender (ITT) and request for proposal (RFP) documents.