OWASP TESTING GUIDE 3.0 Release

FOREWORD

The problem of insecure software is perhaps the most important technical challenge of our time.Security is now the key limiting factor on what we are able to create with information technology. AtThe Open Web Application Security Project (OWASP), we're trying to make the world a place whereinsecure software is the anomaly, not the norm, and the OWASP Testing Guide is an important pieceof the puzzle.

It goes without saying that you can't build a secure application without performing security testing on it.Yet many software development organizations do not include security testing as part of their standardsoftware development process. Still, security testing, by itself, isn't a particularly good measure of howsecure an application is, because there are an infinite number of ways that an attacker might be ableto make an application break, and it simply isn't possible to test them all. However, security testing hasthe unique power to absolutely convince naysayers that there is a problem. So security testing hasproven itself as a key ingredient in any organization that needs to trust the software it produces oruses.

WHO?

Software developers – you need to use this guide to make sure the code you deliver is notvulnerable to attack. You cannot rely on downstream testers or security groups to do this for you.Those groups will never understand your software as well as you do, and therefore will never be ableto test your software as effectively as you can. The responsibility for the security of your code isemphatically yours!

Software testers – you should use this guide to enhance your testing abilities. While security testinghas been a dark art for a long time, OWASP is working hard to making this knowledge free and openfor everyone. Many of the tests described in this guide are not that complicated, and don’t requirespecial skills or tools. You can help your company and enhance your career by learning about security.

Security specialists – you have a special responsibility to ensure that applications do not go live withvulnerabilities. You can use this guide to help ensure the coverage and rigor of your security testing.Don’t fall victim to the trap of simply looking for a few holes. Your job is to verify the security of theentire application. We strongly recommend using the OWASP Application Security VerificationStandard (ASVS) as a guide as well.

THE OWASP GUIDES

OWASP has produced several Guides that work together to capture the application securityknowledgebase:

OWASP Application Security Desk Reference – The ASDR contains basic definitions anddescriptions of all the important principles, threat agents, attacks, vulnerabilities, countermeasures,technical impacts, and business impacts in application security. This is the foundational reference workfor all the other Guides, and is referred to frequently by these other volumes.

OWASP Developer’s Guide – The Developer’s Guide covers all the security controls that softwaredevelopers should put in place. These are the ‘positive’ protections that developers must build intotheir applications. While there are hundreds of types of software vulnerabilities, they can all beprevented with a handful of strong security controls.

OWASP Testing Guide – The Testing Guide you are reading covers the procedures and tools fortesting the security of applications. The best use of this guide is as part of a comprehensiveapplication security verification.

OWASP Code Review Guide – The Code Review Guide is best used alongside the Testing Guide.Verifying applications with code review is often far more cost-effective than testing, and you canchoose the most effective approach for the application you are working on.

Taken together, OWASP's guides are a great start towards building and maintaining secureapplications. I highly recommend using these guides as part of your application security initiatives.

WHY OWASP?

Creating a guide like this is a massive undertaking, representing the expertise of hundreds of peoplearound the world. There are many different ways to test for security flaws and this guide captures theconsensus of the leading experts on how to perform this testing quickly, accurately, and efficiently.

It's impossible to underestimate the importance of having this guide available in a completely free andopen way. Security should not be a black art that only a few can practice. Much of the availablesecurity guidance is only detailed enough to get people worried about a problem, without providingenough information to find, diagnose, and solve security problems. The project to build this guidekeeps this expertise in the hands of the people who need it.

This guide must make its way into the hands of developers and software testers. There are not nearlyenough application security experts in the world to make any significant dent in the overallproblem.The initial responsibility for application security must fall on the shoulders of the developers. Itshouldn't be a surprise that developers aren't producing secure code if they're not testing for it.

Keeping this information up to date is a critical aspect of this guide project. By adopting the wikiapproach, the OWASP community can evolve and expand the information in this guide to keep pacewith the fast moving application security threat landscape.

PRIORITIZING

This guide is best viewed as a set of techniques that you can use to find different types of securityholes. But not all the techniques are equally important. Try to avoid using the guide as a checklist.

Probably the most important aspect of application security testing to keep in mind is that you will havelimited time and you need to provide as much coverage as possible. I strongly recommend that you donot just flip open this book and start testing. Ideally, you would do some threat modeling to determinewhat the most important security concerns to your enterprise. You should end up with a prioritized listof security requirements to verify.

The next step is to decide how to verify these requirements. There are a number of different options.You can use manual security testing or manual code review. You can also use automated vulnerabilityscanning or automated code scanning (static analysis). You might even use security architecturereview or discussions with developers and architects to verify these requirements. The important thingis to decide which of these techniques will be the most accurate and efficient for your particularapplication.

THE ROLE OF AUTOMATED TOOLS

The automated approaches are seductive. It seems like they will provide reasonable coverage in arelatively short time period. Unfortunately, these assumptions are far less true for application securitythan they are for network security.

First, the coverage isn’t very good because these tools are generic - meaning that they are notdesigned for your custom code. That means that while they can find some generic problems, they donot have enough knowledge of your application to allow them to detect most flaws. Also, in myexperience, the most serious security issues are the ones that are not generic, but deeply intertwinedin your business logic and custom application design.

Second, the automated tools aren’t even necessarily faster than manual methods. Actually running thetools doesn't take much time, but the time before and after can be significant. To setup, you have toteach the tools about all the ins and outs of the application – possibly thousands of fields. Thenafterwards, it can take a significant amount of time to diagnose each of the sometimes thousands ofreported issues, which are frequently non-issues.

If the goal is to find and eliminate the most serious flaws as quickly as possible, choose the mosteffective technique for different types of vulnerabilities. Automated tools can be quite effective oncertain issues. Used wisely, they can support your overall processes to produce more secure code.

CALL TO ACTION

If you're building software, I strongly encourage you to get familiar with the security testing guidance inthis document. If you find errors, please add a note to the discussion page or make the changeyourself. You'll be helping thousands of others who use this guide.

Please consider joining us as an individual or corporate member so that we can continue to producematerials like this testing guide and all the other great projects at OWASP. Thank you to all the pastand future contributors to this guide, your work will help to make applications worldwide more secure.

Jeff WilliamsOWASP Chair

January 18, 2009