1 Testing Guide 4.0 Project Leaders: Matteo Meucci and Andrew Muller Creative Commons (CC) Attribution Share-Alike Free version at http://www.owasp.org 2 THE ICONS BELOW REPRESENT WHAT YOU ARE FREE: OTHER VERSIONS ARE AVAILABLE IN PRINT FOR THIS BOOK TITLE. To Share - to copy, distribute and ALPHA: “Alpha Quality” book content is a transmit the work working draft. Content is very rough and in development until the next level of publishing. To Remix - to adapt the work BETA: “Beta Quality” book content is the next highest level. Content is still in development UNDER THE FOLLOWING CONDITIONS: until the next publishing. RELEASE: “Release Quality” book content Attribution. You must attribute the work is the highest level of quality in a book title’s in the manner specified by the author or lifecycle, and is a final product. licensor (but not in any way that suggests that they endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. ALPHA BETA RELEASE The Open Web Application Security Project (OWASP) is a worldwide free and open com- munity focused on improving the security of application software. Our mission is to make application security “visible”, so that people and organizations can make informed decisions about application security risks. Every one is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work. Project Leaders: Matteo Meucci and Andrew Muller 1 Testing Guide Foreword - By Eoin Keary Testing Guide Foreword The problem of insecure software is perhaps the most important technical challenge of our time. The 0 dramatic rise of web applications enabling business, social networking etc has only compounded the requirements to establish a robust approach to writing and securing our Internet, Web Applications and Data. Foreword by Eoin Keary, OWASP Global Board The problem of insecure software is perhaps the most important technical challenge of our time. The dramatic rise of web appli- cations enabling business, social networking etc has only com- pounded the requirements to establish a robust approach to writ- ing and securing our Internet, Web Applications and Data. At The Open Web Application Security Project (OWASP), we’re trying to make the world a place where insecure software is the anomaly, not the norm. The OWASP Testing Guide has an import- ant role to play in solving this serious issue. It is vitally important that our approach to testing software for security issues is based on the principles of engineering and science. We need a consis- tent, repeatable and defined approach to testing web applications. A world without some minimal standards in terms of engineering and technology is a world in chaos. It goes without saying that you can’t build a secure application without performing security testing on it. Testing is part of a wider approach to building a secure system. Many software develop- ment organizations do not include security testing as part of their standard software development process. What is even worse is that many security vendors deliver testing with varying degrees of quality and rigor. Security testing, by itself, isn’t a particularly good stand alone Why OWASP? measure of how secure an application is, because there are an in- finite number of ways that an attacker might be able to make an Creating a guide like this is a huge undertaking, requiring the ex- application break, and it simply isn’t possible to test them all. We pertise of hundreds of people around the world. There are many can’t hack ourselves secure and we only have a limited time to test different ways to test for security flaws and this guide captures and defend where an attacker does not have such constraints. the consensus of the leading experts on how to perform this test- ing quickly, accurately, and efficiently. OWASP gives like minded In conjunction with other OWASP projects such as the Code review security folks the ability to work together and form a leading prac- Guide, the Development Guide and tools such as OWASP ZAP, this tice approach to a security problem. is a great start towards building and maintaining secure applica- tions. The Development Guide will show your project how to archi- The importance of having this guide available in a completely free tect and build a secure application, the Code Review Guide will tell and open way is important for the foundations mission. It gives you how to verify the security of your application’s source code, anyone the ability to understand the techniques used to test for and this Testing Guide will show you how to verify the security of common security issues. Security should not be a black art or your running application. I highly recommend using these guides closed secret that only a few can practice. It should be open to all as part of your application security initiatives. and not exclusive to security practitioners but also QA, Developers 2 Testing Guide Foreword - By Eoin Keary and Technical Managers. The project to build this guide keeps this terms of the application and its use cases. expertise in the hands of the people who need it - you, me and anyone that is involved in building software. This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques This guide must make its way into the hands of developers and are equally important. Try to avoid using the guide as a checklist, software testers. There are not nearly enough application security new vulnerabilities are always manifesting and no guide can be experts in the world to make any significant dent in the overall an exhaustive list of “things to test for”, but rather a great place problem. The initial responsibility for application security must to start. fall on the shoulders of the developers, they write the code. It shouldn’t be a surprise that developers aren’t producing secure The Role of Automated Tools code if they’re not testing for it or consider the types of bugs which introduce vulnerability. There are a number of companies selling automated security anal- ysis and testing tools. Remember the limitations of these tools so that you can use them for what they’re good at. As Michael Keeping this information up to date is a critical aspect of this guide Howard put it at the 2006 OWASP AppSec Conference in Seattle, project. By adopting the wiki approach, the OWASP community “Tools do not make software secure! They help scale the process can evolve and expand the information in this guide to keep pace and help enforce policy.” with the fast moving application security threat landscape. Most importantly, these tools are generic - meaning that they are This Guide is a great testament to the passion and energy our not designed for your custom code, but for applications in general. members and project volunteers have for this subject. It shall cer- That means that while they can find some generic problems, they tainly help change the world a line of code at a time. do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security Tailoring and Prioritizing issues are the ones that are not generic, but deeply intertwined in your business logic and custom application design. You should adopt this guide in your organization. You may need to tailor the information to match your organization’s technologies, These tools can also be seductive, since they do find lots of poten- processes, and organizational structure. tial issues. While running the tools doesn’t take much time, each one of the potential problems takes time to investigate and ver- In general there are several different roles within organizations ify. If the goal is to find and eliminate the most serious flaws as that may use this guide: quickly as possible, consider whether your time is best spent with automated tools or with the techniques described in this guide. • Developers should use this guide to ensure that they are produc- Still, these tools are certainly part of a well-balanced application ing secure code. These tests should be a part of normal code and security program. Used wisely, they can support your overall pro- unit testing procedures. cesses to produce more secure code. • Software testers and QA should use this guide to expand the set Call to Action of test cases they apply to applications. Catching these vulnerabil- ities early saves considerable time and effort later. If you’re building, designing or testing software, I strongly encour- age you to get familiar with the security testing guidance in this • Security specialists should use this guide in combination with document. It is a great road map for testing the most common other techniques as one way to verify that no security holes have issues facing applications today, but it is not exhaustive. If you been missed in an application. find errors, please add a note to the discussion page or make the change yourself. You’ll be helping thousands of others who use • Project Managers should consider the reason this guide exists this guide. and that security issues are manifested via bugs in code and de- sign. Please consider joining us as an individual or corporate member so that we can continue to produce materials like this testing guide The most important thing to remember when performing security and all the other great projects at OWASP.