OWASP Testing Guide Release 4.0

224 Pages·4·2.081 MB·English

by  OWASP

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
transmit the work
ALPHA: “Alpha Quality” book content is a
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
Testing Guide Foreword - Table of contents
0
3 - 4 Foreword by Eoin Keary
1
5 - 6 Frontispiece
About the OWASP Testing Guide Project
About The Open Web Application Security Project
2
7 - 21 Introduction
The OWASP Testing Project
Principles of Testing
Testing Techniques Explained
Deriving Security Test Requirements
Security Tests Integrated in Development and Testing Workflows
Security Test Data Analysis and Reporting
3
22 - 24 The OWASP Testing Framework
Overview
Phase 1: Before Development Begins
Phase 2: During Definition and Design
Phase 3: During Development
Phase 4: During Deployment
Phase 5: Maintenance and Operations
A Typical SDLC Testing Workflow
4
25 - 207 Web Application Security Testing
Introduction and Objectives
Testing Checklist
Information Gathering
Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001)
Fingerprint Web Server (OTG-INFO-002)
Review Webserver Metafiles for Information Leakage (OTG-INFO-003)
Enumerate Applications on Webserver (OTG-INFO-004)
Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005)
Identify application entry points (OTG-INFO-006)
Map execution paths through application (OTG-INFO-007)
Fingerprint Web Application Framework (OTG-INFO-008)
Fingerprint Web Application (OTG-INFO-009)
Map Application Architecture (OTG-INFO-010)
Configuration and Deployment Management Testing
Test Network/Infrastructure Configuration (OTG-CONFIG-001)
Test Application Platform Configuration (OTG-CONFIG-002)
Testing Guide Foreword - Table of contents
Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)
Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)
Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)
Test HTTP Methods (OTG-CONFIG-006)
Test HTTP Strict Transport Security (OTG-CONFIG-007)
Test RIA cross domain policy (OTG-CONFIG-008)
Identity Management Testing
Test Role Definitions (OTG-IDENT-001)
Test User Registration Process (OTG-IDENT-002)
Test Account Provisioning Process (OTG-IDENT-003)
Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)
Testing for Weak or unenforced username policy (OTG-IDENT-005)
Authentication Testing
Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
Testing for default credentials (OTG-AUTHN-002)
Testing for Weak lock out mechanism (OTG-AUTHN-003)
Testing for bypassing authentication schema (OTG-AUTHN-004)
Test remember password functionality (OTG-AUTHN-005)
Testing for Browser cache weakness (OTG-AUTHN-006)
Testing for Weak password policy (OTG-AUTHN-007)
Testing for Weak security question/answer (OTG-AUTHN-008)
Testing for weak password change or reset functionalities (OTG-AUTHN-009)
Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)
Authorization Testing
Testing Directory traversal/file include (OTG-AUTHZ-001)
Testing for bypassing authorization schema (OTG-AUTHZ-002)
Testing for Privilege Escalation (OTG-AUTHZ-003)
Testing for Insecure Direct Object References (OTG-AUTHZ-004)
Session Management Testing
Testing for Bypassing Session Management Schema (OTG-SESS-001)
Testing for Cookies attributes (OTG-SESS-002)
Testing for Session Fixation (OTG-SESS-003)
Testing for Exposed Session Variables (OTG-SESS-004)
Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)
Testing for logout functionality (OTG-SESS-006)
Test Session Timeout (OTG-SESS-007)
Testing for Session puzzling (OTG-SESS-008)
Input Validation Testing
Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)
Testing for Stored Cross Site Scripting (OTG-INPVAL-002)
Testing for HTTP Verb Tampering (OTG-INPVAL-003)
Testing for HTTP Parameter pollution (OTG-INPVAL-004)
Testing for SQL Injection (OTG-INPVAL-005)
Oracle Testing
MySQL Testing
SQL Server Testing
Testing PostgreSQL (from OWASP BSP)
MS Access Testing
3
Testing Guide Foreword - Table of contents
Testing for NoSQL injection
Testing for LDAP Injection (OTG-INPVAL-006)
Testing for ORM Injection (OTG-INPVAL-007)
Testing for XML Injection (OTG-INPVAL-008)
Testing for SSI Injection (OTG-INPVAL-009)
Testing for XPath Injection (OTG-INPVAL-010)
IMAP/SMTP Injection (OTG-INPVAL-011)
Testing for Code Injection (OTG-INPVAL-012)
Testing for Local File Inclusion
Testing for Remote File Inclusion
Testing for Command Injection (OTG-INPVAL-013)
Testing for Buffer overflow (OTG-INPVAL-014)
Testing for Heap overflow
Testing for Stack overflow
Testing for Format string
Testing for incubated vulnerabilities (OTG-INPVAL-015)
Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)
Testing for Error Handling
Analysis of Error Codes (OTG-ERR-001)
Analysis of Stack Traces (OTG-ERR-002)
Testing for weak Cryptography
Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)
Testing for Padding Oracle (OTG-CRYPST-002)
Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)
Business Logic Testing
Test Business Logic Data Validation (OTG-BUSLOGIC-001)
Test Ability to Forge Requests (OTG-BUSLOGIC-002)
Test Integrity Checks (OTG-BUSLOGIC-003)
Test for Process Timing (OTG-BUSLOGIC-004)
Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)
Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)
Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)
Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)
Test Upload of Malicious Files (OTG-BUSLOGIC-009)
Client Side Testing
Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)
Testing for JavaScript Execution (OTG-CLIENT-002)
Testing for HTML Injection (OTG-CLIENT-003)
Testing for Client Side URL Redirect (OTG-CLIENT-004)
Testing for CSS Injection (OTG-CLIENT-005)
Testing for Client Side Resource Manipulation (OTG-CLIENT-006)
Test Cross Origin Resource Sharing (OTG-CLIENT-007)
Testing for Cross Site Flashing (OTG-CLIENT-008)
Testing for Clickjacking (OTG-CLIENT-009)
Testing WebSockets (OTG-CLIENT-010)
Test Web Messaging (OTG-CLIENT-011)
Test Local Storage (OTG-CLIENT-012)
4
Testing Guide Foreword - Table of contents
5
208 - 222 Reporting
Appendix A: Testing Tools
Black Box Testing Tools
Appendix B: Suggested Reading
Whitepapers
Books
Useful Websites
Appendix C: Fuzz Vectors
Fuzz Categories
Appendix D: Encoded Injection
Input Encoding
Output Encoding
5
Testing Guide Foreword - By Eoin Keary
0 Testing Guide Foreword
The problem of insecure software is perhaps the
most important technical challenge of our time. The
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
6
Testing Guide Foreword - By Eoin Keary
and Technical Managers. The project to build this guide keeps this This guide is best viewed as a set of techniques that you can use
expertise in the hands of the people who need it - you, me and to find different types of security holes. But not all the techniques
anyone that is involved in building software. are equally important. Try to avoid using the guide as a checklist,
new vulnerabilities are always manifesting and no guide can be
This guide must make its way into the hands of developers and an exhaustive list of “things to test for”, but rather a great place
software testers. There are not nearly enough application security to start.
experts in the world to make any significant dent in the overall
problem. The initial responsibility for application security must The Role of Automated Tools
fall on the shoulders of the developers, they write the code. It
shouldn’t be a surprise that developers aren’t producing secure There are a number of companies selling automated security anal-
code if they’re not testing for it or consider the types of bugs ysis and testing tools. Remember the limitations of these tools
which introduce vulnerability. so that you can use them for what they’re good at. As Michael
Howard put it at the 2006 OWASP AppSec Conference in Seattle,
Keeping this information up to date is a critical aspect of this guide “Tools do not make software secure! They help scale the process
project. By adopting the wiki approach, the OWASP community and help enforce policy.”
can evolve and expand the information in this guide to keep pace
with the fast moving application security threat landscape. Most importantly, these tools are generic - meaning that they are
not designed for your custom code, but for applications in general.
This Guide is a great testament to the passion and energy our That means that while they can find some generic problems, they
members and project volunteers have for this subject. It shall cer- do not have enough knowledge of your application to allow them
tainly help change the world a line of code at a time. to detect most flaws. In my experience, the most serious security
issues are the ones that are not generic, but deeply intertwined in
Tailoring and Prioritizing your business logic and custom application design.
You should adopt this guide in your organization. You may need to These tools can also be seductive, since they do find lots of poten-
tailor the information to match your organization’s technologies, tial issues. While running the tools doesn’t take much time, each
processes, and organizational structure. one of the potential problems takes time to investigate and ver-
ify. If the goal is to find and eliminate the most serious flaws as
In general there are several different roles within organizations quickly as possible, consider whether your time is best spent with
that may use this guide: automated tools or with the techniques described in this guide.
Still, these tools are certainly part of a well-balanced application
• Developers should use this guide to ensure that they are produc- security program. Used wisely, they can support your overall pro-
ing secure code. These tests should be a part of normal code and cesses to produce more secure code.
unit testing procedures.
Call to Action
• Software testers and QA should use this guide to expand the set
of test cases they apply to applications. Catching these vulnerabil- If you’re building, designing or testing software, I strongly encour-
ities early saves considerable time and effort later. age you to get familiar with the security testing guidance in this
document. It is a great road map for testing the most common
• Security specialists should use this guide in combination with issues facing applications today, but it is not exhaustive. If you
other techniques as one way to verify that no security holes have find errors, please add a note to the discussion page or make the
been missed in an application. change yourself. You’ll be helping thousands of others who use
this guide.
• Project Managers should consider the reason this guide exists
and that security issues are manifested via bugs in code and de- Please consider joining us as an individual or corporate member so
sign. that we can continue to produce materials like this testing guide
and all the other great projects at OWASP.
The most important thing to remember when performing security
testing is to continuously re-prioritize. There are an infinite num- Thank you to all the past and future contributors to this guide,
ber of possible ways that an application could fail, and organiza- your work will help to make applications worldwide more secure.
tions always have limited testing time and resources. Be sure time
and resources are spent wisely. Try to focus on the security holes
that are a real risk to your business. Try to contextualize risk in
terms of the application and its use cases. Eoin Keary, OWASP Board Member, April 19, 2013
7
Testing Guide Frontispiece
1 Testing Guide Frontispiece
“Open and collaborative knowledge: that is the
OWASP way.”
With V4 we realized a new guide that will be the
standard de-facto guide to perform Web Application
Penetration Testing
“Open and collaborative knowledge: that is the OWASP way.” Revision History
With V4 we realized a new guide that will be the standard de-fac- The Testing Guide v4 will be released in 2014. The Testing guide orig-
to guide to perform Web Application Penetration Testing. - Matteo inated in 2003 with Dan Cuthbert as one of the original editors. It was
Meucci handed over to Eoin Keary in 2005 and transformed into a wiki. Mat-
teo Meucci has taken on the Testing guide and is now the lead of the
OWASP thanks the many authors, reviewers, and editors for their OWASP Testing Guide Project. From 2012 Andrew Muller co-leader-
hard work in bringing this guide to where it is today. If you have any ship the project with Matteo Meucci.
comments or suggestions on the Testing Guide, please e-mail the
2014
Testing Guide mail list: • “OWASP Testing Guide”, Version 4.0
15th September, 2008
http://lists.owasp.org/mailman/listinfo/owasp-testing • “OWASP Testing Guide”, Version 3.0
December 25, 2006
Or drop an e-mail to the project leaders: Andrew Muller and Matteo Meucci • “OWASP Testing Guide”, Version 2.0
Version 4.0 July 14, 2004
The OWASP Testing Guide version 4 improves on version 3 in three ways: • “OWASP Web Application Penetration Checklist”, Version 1.1
[1] This version of the Testing Guide integrates with the two other December 2004
flagship OWASP documentation products: the Developers Guide and • “The OWASP Testing Guide”, Version 1.0
the Code Review Guide. To achieve this we aligned the testing cate-
gories and test numbering with those in other OWASP products. The Project Leaders
aim of the Testing and Code Review Guides is to evaluate the security
controls described by the Developers Guide.
[2] All chapters have been improved and test cases expanded to 87 Matteo Meucci
(64 test cases in v3) including the introduction of four new chapters
and controls:
• Identity Management Testing
• Error Handling
• Cryptography
• Client Side Testing
[3] This version of the Testing Guide encourages the community not
to simply accept the test cases outlined in this guide. We encourage
security testers to integrate with other software testers and devise
Andrew Muller
test cases specific to the target application. As we find test cases that
have wider applicability we encourage the security testing community
to share them and contribute them to the Testing Guide. This will con-
tinue to build the application security body of knowledge and allow
the development of the Testing Guide to be an iterative rather than Andrew Muller: OWASP Testing Guide Lead since 2013.
monolithic process.
Matteo Meucci: OWASP Testing Guide Lead since 2007.
Copyright and License
Copyright (c) 2014 The OWASP Foundation. Eoin Keary: OWASP Testing Guide 2005-2007 Lead.
This document is released under the Creative Commons 2.5 License.
Please read and understand the license and copyright conditions. Daniel Cuthbert: OWASP Testing Guide 2003-2005 Lead.
8
Testing Guide Frontispiece
v4 Authors
• Matteo Meucci • Thomas Ryan • Mike Hryekewicz • Eduardo Castellanos • Babu Arokiadas
• Pavol Luptak • Tim Bertels • Simon Bennetts • Simone Onofri • Rob Barnes
• Marco Morana • Cecil Su • Ray Schippers • Harword Sheen • Ben Walther
• Giorgio Fedon • Aung KhAnt • Raul Siles • Amro AlOlaqi • Anant Shrivastava
• Stefano Di Paola • Norbert Szetei • Jayanta Karmakar • Suhas Desai • Colin Watson
• Gianrico Ingrosso • Michael Boman • Brad Causey • Ryan Dewhurst • Luca Carettoni
• Giuseppe Bonfà • Wagner Elias • Vicente Aguilera • Zaki Akhmad • Eoin Keary
• Andrew Muller • Kevin Horvat • Ismael Gonçalves • Davide Danelon • Jeff Williams
• Robert Winkel • Tom Brennan • David Fern • Alexander Antukh • Juan Manuel Bahamonde
• Roberto Suggi Liverani • Tomas Zatko • Tom Eston • Thomas Kalamaris • Thomas Skora
• Robert Smith • Juan Galiana Lara • Kevin Horvath • Alexander Vavousis • Irene Abezgauz
• Tripurari Rai • Sumit Siddharth • Rick Mitchell • Christian Heinrich • Hugo Costa
v4 Reviewers v3 Authors v3 Reviewers
• Davide Danelon • Anurag Agarwwal • Pavol Luptak • Marco Cova
• Andrea Rosignoli • Daniele Bellucci • Ferruh Mavituna • Kevin Fuller
• Irene Abezgauz • Ariel Coronel • Marco Mella • Matteo Meucci
• Lode Vanstechelman • Stefano Di Paola • Matteo Meucci • Nam Nguyen
• Sebastien Gioria • Giorgio Fedon • Marco Morana • Rick Mitchell
• Yiannis Pavlosoglou • Adam Goodman • Antonio Parata
• Aditya Balapure • Christian Heinrich • Cecil Su
• Kevin Horvath • Harish Skanda Sureddy
• Gianrico Ingrosso • Mark Roxberry
• Roberto Suggi Liverani • Andrew Van der Stock
• Kuza55
v2 Authors
• Vicente Aguilera • Stefano Di Paola • Ralph M. Los • Alberto Revelli
• Mauro Bregolin • David Endler • Claudio Merloni • Mark Roxberry
• Tom Brennan • Giorgio Fedon • Matteo Meucci • Tom Ryan
• Gary Burns • Javier Fernández-Sanguino • Marco Morana • Anush Shetty
• Luca Carettoni • Glyn Geoghegan • Laura Nunez • Larry Shields
• Dan Cornell • Stan Guzik • Gunter Ollmann • Dafydd Studdard
• Mark Curphey • Madhura Halasgikar • Antonio Parata • Andrew van der Stock
• Daniel Cuthbert • Eoin Keary • Yiannis Pavlosoglou • Ariel Waissbein
• Sebastien Deleersnyder • David Litchfield • Carlo Pelliccioni • Jeff Williams
• Stephen DeVries • Andrea Lombardini • Harinath Pudipeddi • Tushar Vartak
Trademarks
v2 Reviewers
• Java, Java Web Server, and JSP are registered trademarks
• Vicente Aguilera • Eoin Keary
of Sun Microsystems, Inc.
• Marco Belotti • James Kist
• Merriam-Webster is a trademark of Merriam-Webster, Inc.
• Mauro Bregolin • Katie McDowell
• Microsoft is a registered trademark of Microsoft Corporation.
• Marco Cova • Marco Mella
• Octave is a service mark of Carnegie Mellon University.
• Daniel Cuthbert • Matteo Meucci
• VeriSign and Thawte are registered trademarks
• Paul Davies • Syed Mohamed
of VeriSign, Inc.
• Stefano Di Paola • Antonio Parata
• Visa is a registered trademark of VISA USA.
• Matteo G.P. Flora • Alberto Revelli
• OWASP is a registered trademark of the OWASP Foundation
• Simona Forti • Mark Roxberry
• Darrell Groundy • Dave Wichers
All other products and company names may be trademarks of their
respective owners. Use of a term in this document should not be
regarded as affecting the validity of any trademark or service mark.