Testing Guide 4 - OWASP
1Testing Guide 4.0Project Leaders: Matteo Meucci and Andrew MullerCreative Commons (CC) Attribution Share-AlikeFree version at http://www.owasp.org
2THE ICONS BELOW REPRESENT WHATOTHER VERSIONS ARE AVAILABLE IN PRINTFOR THIS BOOK TITLE.ALPHA: “Alpha Quality” book content is aworking draft. Content is very rough and indevelopment until the next level of publishing.BETA: “Beta Quality” book content is the nexthighest level. Content is still in developmentuntil the next publishing.RELEASE: “Release Quality” book contentis the highest level of quality in a book title’slifecycle, and is a final product.YOU ARE FREE:To Share - to copy, distribute andtransmit the workTo Remix - to adapt the workUNDER THE FOLLOWING CONDITIONS:Attribution. You must attribute the workin the manner specified by the author orlicensor (but not in any way that suggeststhat they endorse you or your use of thework).Share Alike. If you alter, transform, orbuild upon this work, you may distributethe resulting work only under the same,similar or a compatible license.ALPHABETARELEASEThe Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to makeapplication security “visible”, so that people and organizations can make informed decisionsabout application security risks. Every one is free to participate in OWASP and all of ourmaterials are available under a free and open software license. The OWASP Foundationis a 501c3 not-for-profit charitable organization that ensures the ongoing availability andsupport for our work.
Testing Guide Foreword - Table of contents3-45-60Foreword by Eoin Keary1FrontispieceAbout the OWASP Testing Guide ProjectAbout The Open Web Application Security Project7 - 212IntroductionThe OWASP Testing ProjectPrinciples of TestingTesting Techniques ExplainedDeriving Security Test RequirementsSecurity Tests Integrated in Development and Testing WorkflowsSecurity Test Data Analysis and Reporting22 - 243The OWASP Testing FrameworkOverviewPhase 1: Before Development BeginsPhase 2: During Definition and DesignPhase 3: During DevelopmentPhase 4: During DeploymentPhase 5: Maintenance and OperationsA Typical SDLC Testing Workflow25 - 2074Web Application Security TestingIntroduction and ObjectivesTesting ChecklistInformation GatheringConduct 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 TestingTest Network/Infrastructure Configuration (OTG-CONFIG-001)Test Application Platform Configuration (OTG-CONFIG-002)
Testing Guide Foreword - Table of contentsTest 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 TestingTest 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 TestingTesting 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 TestingTesting 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 TestingTesting 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 TestingTesting 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 TestingMySQL TestingSQL Server TestingTesting PostgreSQL (from OWASP BSP)MS Access Testing
3Testing Guide Foreword - Table of contentsTesting for NoSQL injectionTesting 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 InclusionTesting for Remote File InclusionTesting for Command Injection (OTG-INPVAL-013)Testing for Buffer overflow (OTG-INPVAL-014)Testing for Heap overflowTesting for Stack overflowTesting for Format stringTesting for incubated vulnerabilities (OTG-INPVAL-015)Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)Testing for Error HandlingAnalysis of Error Codes (OTG-ERR-001)Analysis of Stack Traces (OTG-ERR-002)Testing for weak CryptographyTesting 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 TestingTest 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 TestingTesting 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)
4Testing Guide Foreword - Table of contents208 - 2225ReportingAppendix A: Testing ToolsBlack Box Testing ToolsAppendix B: Suggested ReadingWhitepapersBooksUseful WebsitesAppendix C: Fuzz VectorsFuzz CategoriesAppendix D: Encoded InjectionInput EncodingOutput Encoding
5Testing Guide Foreword - By Eoin Keary0Testing Guide ForewordThe problem of insecure software is perhaps themost important technical challenge of our time. Thedramatic rise of web applications enabling business,social networking etc has only compounded therequirements to establish a robust approach to writingand securing our Internet, Web Applications and Data.Foreword by Eoin Keary, OWASP Global BoardThe problem of insecure software is perhaps the most importanttechnical 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.At The Open Web Application Security Project (OWASP), we’retrying to make the world a place where insecure software is theanomaly, not the norm. The OWASP Testing Guide has an important role to play in solving this serious issue. It is vitally importantthat our approach to testing software for security issues is basedon the principles of engineering and science. We need a consistent, repeatable and defined approach to testing web applications.A world without some minimal standards in terms of engineeringand technology is a world in chaos.It goes without saying that you can’t build a secure applicationwithout performing security testing on it. Testing is part of a widerapproach to building a secure system. Many software development organizations do not include security testing as part of theirstandard software development process. What is even worse isthat many security vendors deliver testing with varying degreesof quality and rigor.Security testing, by itself, isn’t a particularly good stand alonemeasure of how secure an application is, because there are an infinite number of ways that an attacker might be able to make anapplication break, and it simply isn’t possible to test them all. Wecan’t hack ourselves secure and we only have a limited time to testand defend where an attacker does not have such constraints.In conjunction with other OWASP projects such as the Code reviewGuide, the Development Guide and tools such as OWASP ZAP, thisis a great start towards building and maintaining secure applications. The Development Guide will show your project how to architect and build a secure application, the Code Review Guide will tellyou how to verify the security of your application’s source code,and this Testing Guide will show you how to verify the security ofyour running application. I highly recommend using these guidesas part of your application security initiatives.Why OWASP?Creating a guide like this is a huge undertaking, requiring the expertise of hundreds of people around the world. There are manydifferent ways to test for security flaws and this guide capturesthe consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently. OWASP gives like mindedsecurity folks the ability to work together and form a leading practice approach to a security problem.The importance of having this guide available in a completely freeand open way is important for the foundations mission. It givesanyone the ability to understand the techniques used to test forcommon security issues. Security should not be a black art orclosed secret that only a few can practice. It should be open to alland not exclusive to security practitioners but also QA, Developers
6Testing Guide Foreword - By Eoin Kearyand Technical Managers. The project to build this guide keeps thisexpertise in the hands of the people who need it - you, me andanyone that is involved in building software.This guide must make its way into the hands of developers andsoftware testers. There are not nearly enough application securityexperts in the world to make any significant dent in the overallproblem. The initial responsibility for application security mustfall on the shoulders of the developers, they write the code. Itshouldn’t be a surprise that developers aren’t producing securecode if they’re not testing for it or consider the types of bugswhich introduce vulnerability.Keeping this information up to date is a critical aspect of this guideproject. By adopting the wiki approach, the OWASP communitycan evolve and expand the information in this guide to keep pacewith the fast moving application security threat landscape.This Guide is a great testament to the passion and energy ourmembers and project volunteers have for this subject. It shall certainly help change the world a line of code at a time.Tailoring and PrioritizingYou should adopt this guide in your organization. You may need totailor the information to match your organization’s technologies,processes, and organizational structure.In general there are several different roles within organizationsthat may use this guide: Developers should use this guide to ensure that they are producing secure code. These tests should be a part of normal code andunit testing procedures. Software testers and QA should use this guide to expand the setof test cases they apply to applications. Catching these vulnerabilities early saves considerable time and effort later. Security specialists should use this guide in combination withother techniques as one way to verify that no security holes havebeen missed in an application. Project Managers should consider the reason this guide existsand that security issues are manifested via bugs in code and design.The most important thing to remember when performing securitytesting is to continuously re-prioritize. There are an infinite number of possible ways that an application could fail, and organizations always have limited testing time and resources. Be sure timeand resources are spent wisely. Try to focus on the security holesthat are a real risk to your business. Try to contextualize risk interms of the application and its use cases.This guide is best viewed as a set of techniques that you can useto find different types of security holes. But not all the techniquesare equally important. Try to avoid using the guide as a checklist,new vulnerabilities are always manifesting and no guide can bean exhaustive list of “things to test for”, but rather a great placeto start.The Role of Automated ToolsThere are a number of companies selling automated security analysis and testing tools. Remember the limitations of these toolsso that you can use them for what they’re good at. As MichaelHoward put it at the 2006 OWASP AppSec Conference in Seattle,“Tools do not make software secure! They help scale the processand help enforce policy.”Most importantly, these tools are generic - meaning that they arenot designed for your custom code, but for applications in general.That means that while they can find some generic problems, theydo not have enough knowledge of your application to allow themto detect most flaws. In my experience, the most serious securityissues are the ones that are not generic, but deeply intertwined inyour business logic and custom application design.These tools can also be seductive, since they do find lots of potential issues. While running the tools doesn’t take much time, eachone of the potential problems takes time to investigate and verify. If the goal is to find and eliminate the most serious flaws asquickly as possible, consider whether your time is best spent withautomated tools or with the techniques described in this guide.Still, these tools are certainly part of a well-balanced applicationsecurity program. Used wisely, they can support your overall processes to produce more secure code.Call to ActionIf you’re building, designing or testing software, I strongly encourage you to get familiar with the security testing guidance in thisdocument. It is a great road map for testing the most commonissues facing applications today, but it is not exhaustive. If youfind errors, please add a note to the discussion page or make thechange yourself. You’ll be helping thousands of others who usethis guide.Please consider joining us as an individual or corporate member sothat we can continue to produce materials like this testing guideand all the other great projects at OWASP.Thank you to all the past and future contributors to this guide,your work will help to make applications worldwide more secure.Eoin Keary, OWASP Board Member, April 19, 2013
7Testing Guide Frontispiece1Testing Guide Frontispiece“Open and collaborative knowledge: that is theOWASP way.”With V4 we realized a new guide that will be thestandard de-facto guide to perform Web ApplicationPenetration Testing“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. - MatteoMeucciOWASP thanks the many authors, reviewers, and editors for theirhard work in bringing this guide to where it is today. If you have anycomments or suggestions on the Testing Guide, please e-mail theTesting Guide mail -testingOr drop an e-mail to the project leaders: Andrew Muller and Matteo MeucciRevision HistoryThe Testing Guide v4 will be released in 2014. The Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It washanded over to Eoin Keary in 2005 and transformed into a wiki. Matteo Meucci has taken on the Testing guide and is now the lead of theOWASP Testing Guide Project. From 2012 Andrew Muller co-leadership the project with Matteo Meucci.2014 “OWASP Testing Guide”, Version 4.015th September, 2008 “OWASP Testing Guide”, Version 3.0December 25, 2006 “OWASP Testing Guide”, Version 2.0Version 4.0July 14, 2004 “OWASP Web Application Penetration Checklist”, Version 1.1[1] This version of the Testing Guide integrates with the two otherflagship OWASP documentation products: the Developers Guide andthe Code Review Guide. To achieve this we aligned the testing categories and test numbering with those in other OWASP products. Theaim of the Testing and Code Review Guides is to evaluate the securitycontrols described by the Developers Guide.December 2004 “The OWASP Testing Guide”, Version 1.0The OWASP Testing Guide version 4 improves on version 3 in three ways:Project Leaders[2] All chapters have been improved and test cases expanded to 87(64 test cases in v3) including the introduction of four new chaptersand controls: Identity Management Testing Error Handling Cryptography Client Side Testing[3] This version of the Testing Guide encourages the community notto simply accept the test cases outlined in this guide. We encouragesecurity testers to integrate with other software testers and devisetest cases specific to the target application. As we find test cases thathave wider applicability we encourage the security testing communityto share them and contribute them to the Testing Guide. This will continue to build the application security body of knowledge and allowthe development of the Testing Guide to be an iterative rather thanmonolithic process.Copyright and LicenseCopyright (c) 2014 The OWASP Foundation.This document is released under the Creative Commons 2.5 License.Please read and understand the license and copyright conditions.Matteo MeucciAndrew MullerAndrew Muller: OWASP Testing Guide Lead since 2013.Matteo Meucci: OWASP Testing Guide Lead since 2007.Eoin Keary: OWASP Testing Guide 2005-2007 Lead.Daniel Cuthbert: OWASP Testing Guide 2003-2005 Lead.
8Testing Guide Frontispiecev4 Authors Matteo Meucci Pavol Luptak Marco Morana Giorgio Fedon Stefano Di Paola Gianrico Ingrosso Giuseppe Bonfà Andrew Muller Robert Winkel Roberto Suggi Liverani Robert Smith Tripurari Raiv4 Reviewers Davide Danelon Andrea Rosignoli Irene Abezgauz Lode Vanstechelman Sebastien Gioria Yiannis Pavlosoglou Aditya Balapurev2 Authors Vicente Aguilera Mauro Bregolin Tom Brennan Gary Burns Luca Carettoni Dan Cornell Mark Curphey Daniel Cuthbert Sebastien Deleersnyder Stephen DeVriesv2 Reviewers Vicente Aguilera Marco Belotti Mauro Bregolin Marco Cova Daniel Cuthbert Paul Davies Stefano Di Paola Matteo G.P. Flora Sim
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 .
OWASP Code review guide, V1.1 The Ruby on Rails Security Guide v2 OWASP UI Component Verification Project (a.k.a. OWASP JSP Testing Tool) Internationalization Guidelines and OWASP-Spanish Project OWASP Application Security Desk Reference (ASDR) OWASP .NET Project Leader OWASP Education Project
Planning the OWASP Testing Guide v4 Matteo Meucci, Giorgio Fedon, Pavol Luptak Few words about the TG history and adoption by the Companies Why we need the Common Numbering . -"OWASP Testing Guide", Version 2.0 December 16, 2008 -"OWASP Testing Guide", Version 3.0 -Released at the OWASP Summit 08. Project Complexity 0 50 100 .
The OWASP Testing Guide: the standard for verifying the . User enumeration . Testing for HTTP Methods and XST (OWASP-CM-008) 28th May 2010 OWASP Testing for file extensions handling The following file extensions should NEVER be returned by a web server, since they are related to files which may contain sensitive .
work with clients, we also find that the OWASP Top 10 vulnerabilities are some of the most prevalent. This tells us that all companies should at least be looking for the OWASP Top 10 on a regular basis. A1 - Injection OWASP Top 10 -2013 OWASP Top 10 -2017 A2 - Broken Authentication and Session Managament A3 - Cross-Site Scripting (XSS)
Threat Prevention Coverage – OWASP Top 10 Analysis of Check Point Coverage for OWASP Top 10 Website Vulnerability Classes The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. OWASP mission is to make software security visible, so that individuals and
OWASP effort. This shows how much passion the community has for the OWASP Top 10, and thus how critical it is for OWASP to get the Top 10 right for the majority of use cases. Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers, it has become . the. de facto application security .
The OWASP Top 10 Proactive Controls is similar to the OWASP Top 10 but is focused on defensive techniques and controls as opposed to risks. Each technique or control in this document will . OWASP Mobile Application Security Verification Standard (MASVS) OWASP Top Ten .
Application using OWASP Testing Guide Version 4 framework to known there is any security issues on that application. there are ten things that were tested, that is from OTG-INFO-001 until OTG-INFO-010 and the result is seven test get positif value. Keywords : penetration testing, information gathering, OWASP testing guide version 4, cyber
