4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
6<br />
Testing Guide Foreword - By Eoin Keary<br />
and Technical Managers. The project to build this guide keeps this<br />
expertise in the hands of the people who need it - you, me and<br />
anyone that is involved in building software.<br />
This guide must make its way into the hands of developers and<br />
software testers. There are not nearly enough application security<br />
experts in the world to make any significant dent in the overall<br />
problem. The initial responsibility for application security must<br />
fall on the shoulders of the developers, they write the code. It<br />
shouldn’t be a surprise that developers aren’t producing secure<br />
code if they’re not testing for it or consider the types of bugs<br />
which introduce vulnerability.<br />
Keeping this information up to date is a critical aspect of this guide<br />
project. By adopting the wiki approach, the OWASP community<br />
can evolve and expand the information in this guide to keep pace<br />
with the fast moving application security threat landscape.<br />
This Guide is a great testament to the passion and energy our<br />
members and project volunteers have for this subject. It shall certainly<br />
help change the world a line of code at a time.<br />
Tailoring and Prioritizing<br />
You should adopt this guide in your organization. You may need to<br />
tailor the information to match your organization’s technologies,<br />
processes, and organizational structure.<br />
In general there are several different roles within organizations<br />
that may use this guide:<br />
• Developers should use this guide to ensure that they are producing<br />
secure code. These tests should be a part of normal code and<br />
unit testing procedures.<br />
• Software testers and QA should use this guide to expand the set<br />
of test cases they apply to applications. Catching these vulnerabilities<br />
early saves considerable time and effort later.<br />
• Security specialists should use this guide in combination with<br />
other techniques as one way to verify that no security holes have<br />
been missed in an application.<br />
• Project Managers should consider the reason this guide exists<br />
and that security issues are manifested via bugs in code and design.<br />
The most important thing to remember when performing security<br />
testing is to continuously re-prioritize. There are an infinite number<br />
of possible ways that an application could fail, and organizations<br />
always have limited testing time and resources. Be sure time<br />
and resources are spent wisely. Try to focus on the security holes<br />
that are a real risk to your business. Try to contextualize risk in<br />
terms of the application and its use cases.<br />
This guide is best viewed as a set of techniques that you can use<br />
to find different types of security holes. But not all the techniques<br />
are equally important. Try to avoid using the guide as a checklist,<br />
new vulnerabilities are always manifesting and no guide can be<br />
an exhaustive list of “things to test for”, but rather a great place<br />
to start.<br />
The Role of Automated Tools<br />
There are a number of companies selling automated security analysis<br />
and testing tools. Remember the limitations of these tools<br />
so that you can use them for what they’re good at. As Michael<br />
Howard put it at the 2006 OWASP AppSec Conference in Seattle,<br />
“Tools do not make software secure! They help scale the process<br />
and help enforce policy.”<br />
Most importantly, these tools are generic - meaning that they are<br />
not designed for your custom code, but for applications in general.<br />
That means that while they can find some generic problems, they<br />
do not have enough knowledge of your application to allow them<br />
to detect most flaws. In my experience, the most serious security<br />
issues are the ones that are not generic, but deeply intertwined in<br />
your business logic and custom application design.<br />
These tools can also be seductive, since they do find lots of potential<br />
issues. While running the tools doesn’t take much time, each<br />
one of the potential problems takes time to investigate and verify.<br />
If the goal is to find and eliminate the most serious flaws as<br />
quickly as possible, consider whether your time is best spent with<br />
automated tools or with the techniques described in this guide.<br />
Still, these tools are certainly part of a well-balanced application<br />
security program. Used wisely, they can support your overall processes<br />
to produce more secure code.<br />
Call to Action<br />
If you’re building, designing or testing software, I strongly encourage<br />
you to get familiar with the security testing guidance in this<br />
document. It is a great road map for testing the most common<br />
issues facing applications today, but it is not exhaustive. If you<br />
find errors, please add a note to the discussion page or make the<br />
change yourself. You’ll be helping thousands of others who use<br />
this guide.<br />
Please consider joining us as an individual or corporate member so<br />
that we can continue to produce materials like this testing guide<br />
and all the other great projects at OWASP.<br />
Thank you to all the past and future contributors to this guide,<br />
your work will help to make applications worldwide more secure.<br />
Eoin Keary, OWASP Board Member, April 19, 2013