- Owasp Testing Guide v4
- Frontispiece
- 1. Foreword
- 2. Introduction
- 3. The OWASP Testing Framework
-
4.
Web Application Security Testing
- 4.1. Introduction and Objectives
-
4.2.
Information Gathering
- 4.2.1. Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001)
- 4.2.2. Fingerprint Web Server (OTG-INFO-002)
- 4.2.3. Review Webserver Metafiles for Information Leakage (OTG-INFO-003)
- 4.2.4. Enumerate Applications on Webserver (OTG-INFO-004)
- 4.2.5. Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005)
- 4.2.6. Identify application entry points (OTG-INFO-006)
- 4.2.7. Map execution paths through application (OTG-INFO-007)
- 4.2.8. Fingerprint Web Application Framework (OTG-INFO-008)
- 4.2.9. Fingerprint Web Application (OTG-INFO-009)
- 4.2.10. Map Application Architecture (OTG-INFO-010)
-
4.3.
Configuration and Deployment Management Testing
- 4.3.1. Test Network/Infrastructure Configuration (OTG-CONFIG-001)
- 4.3.2. Test Application Platform Configuration (OTG-CONFIG-002)
- 4.3.3. Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)
- 4.3.4. Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)
- 4.3.5. Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)
- 4.3.6. Test HTTP Methods (OTG-CONFIG-006)
- 4.3.7. Test HTTP Strict Transport Security (OTG-CONFIG-007)
- 4.3.8. Test RIA cross domain policy (OTG-CONFIG-008)
-
4.4.
Identity Management Testing
- 4.4.1. Test Role Definitions (OTG-IDENT-001)
- 4.4.2. Test User Registration Process (OTG-IDENT-002)
- 4.4.3. Test Account Provisioning Process (OTG-IDENT-003)
- 4.4.4. Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)
- 4.4.5. Testing for Weak or unenforced username policy (OTG-IDENT-005)
-
4.5.
Authentication Testing
- 4.5.1. Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
- 4.5.2. Testing for default credentials (OTG-AUTHN-002)
- 4.5.3. Testing for Weak lock out mechanism (OTG-AUTHN-003)
- 4.5.4. Testing for bypassing authentication schema (OTG-AUTHN-004)
- 4.5.5. Test remember password functionality (OTG-AUTHN-005)
- 4.5.6. Testing for Browser cache weakness (OTG-AUTHN-006)
- 4.5.7. Testing for Weak password policy (OTG-AUTHN-007)
- 4.5.8. Testing for Weak security question/answer (OTG-AUTHN-008)
- 4.5.9. Testing for weak password change or reset functionalities (OTG-AUTHN-009)
- 4.5.10. Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)
- 4.6. Authorization Testing
-
4.7.
Session Management Testing
- 4.7.1. Testing for Bypassing Session Management Schema (OTG-SESS-001)
- 4.7.2. Testing for Cookies attributes (OTG-SESS-002)
- 4.7.3. Testing for Session Fixation (OTG-SESS-003)
- 4.7.4. Testing for Exposed Session Variables (OTG-SESS-004)
- 4.7.5. Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)
- 4.7.6. Testing for logout functionality (OTG-SESS-006)
- 4.7.7. Test Session Timeout (OTG-SESS-007)
- 4.7.8. Testing for Session puzzling (OTG-SESS-008)
-
4.8.
Input Validation Testing
- 4.8.1. Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)
- 4.8.2. Testing for Stored Cross Site Scripting (OTG-INPVAL-002)
- 4.8.3. Testing for HTTP Verb Tampering (OTG-INPVAL-003)
- 4.8.4. Testing for HTTP Parameter pollution (OTG-INPVAL-004)
- 4.8.5. Testing for SQL Injection (OTG-INPVAL-005)
- 4.8.6. Testing for LDAP Injection (OTG-INPVAL-006)
- 4.8.7. Testing for ORM Injection (OTG-INPVAL-007)
- 4.8.8. Testing for XML Injection (OTG-INPVAL-008)
- 4.8.9. Testing for SSI Injection (OTG-INPVAL-009)
- 4.8.10. Testing for XPath Injection (OTG-INPVAL-010)
- 4.8.11. IMAP/SMTP Injection (OTG-INPVAL-011)
- 4.8.12. Testing for Code Injection (OTG-INPVAL-012)
- 4.8.13. Testing for Command Injection (OTG-INPVAL-013)
- 4.8.14. Testing for Buffer overflow (OTG-INPVAL-014)
- 4.8.15. Testing for incubated vulnerabilities (OTG-INPVAL-015)
- 4.8.16. Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)
- 4.9. Testing for Error Handling
- 4.10. Testing for weak Cryptography
-
4.11.
Business Logic Testing
- 4.11.1. Test Business Logic Data Validation (OTG-BUSLOGIC-001)
- 4.11.2. Test Ability to Forge Requests (OTG-BUSLOGIC-002)
- 4.11.3. Test Integrity Checks (OTG-BUSLOGIC-003)
- 4.11.4. Test for Process Timing (OTG-BUSLOGIC-004)
- 4.11.5. Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)
- 4.11.6. Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)
- 4.11.7. Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)
- 4.11.8. Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)
- 4.11.9. Test Upload of Malicious Files (OTG-BUSLOGIC-009)
-
4.12.
Client Side Testing
- 4.12.1. Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)
- 4.12.2. Testing for JavaScript Execution (OTG-CLIENT-002)
- 4.12.3. Testing for HTML Injection (OTG-CLIENT-003)
- 4.12.4. Testing for Client Side URL Redirect (OTG-CLIENT-004)
- 4.12.5. Testing for CSS Injection (OTG-CLIENT-005)
- 4.12.6. Testing for Client Side Resource Manipulation (OTG-CLIENT-006)
- 4.12.7. Test Cross Origin Resource Sharing (OTG-CLIENT-007)
- 4.12.8. Testing for Cross Site Flashing (OTG-CLIENT-008)
- 4.12.9. Testing for Clickjacking (OTG-CLIENT-009)
- 4.12.10. Testing WebSockets (OTG-CLIENT-010)
- 4.12.11. Test Web Messaging (OTG-CLIENT-011)
- 4.12.12. Test Local Storage (OTG-CLIENT-012)
- 5. Reporting
- 6. Appendix
Map execution paths through application (OTG-INFO-007)
Summary
Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly.
Test Objectives
Map the target application and understand the principal workflows.
How to Test
In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to document what code paths were discovered and tested.
There are several ways to approach the testing and measurement of code coverage:
- Path - test each of the paths through an application that includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.
- Data flow (or taint analysis) - tests the assignment of variables via external interaction (normally users). Focuses on mapping the flow, transformation and use of data throughout an application.
- Race - tests multiple concurrent instances of the application manipulating the same data.
The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the application owner what functions or code sections they are particularly concerned about and how those code segments can be reached.
Black Box Testing
To demonstrate code coverage to the application owner, the tester can start with a spreadsheet and document all the links discovered by spidering the application (either manually or automatically). Then the tester can look more closely at decision points in the application and investigate how many significant code paths are discovered. These should then be documented in the spreadsheet with URLs, prose and screenshot descriptions of the paths discovered.
Gray/White Box testing
Ensuring sufficient code coverage for the application owner is far easier with the gray and white box approach to testing. Information solicited by and provided to the tester will ensure the minimum requirements for code coverage are met.
Example
Automatic Spidering
The automatic spider is a tool used to automatically discover new resources (URLs) on a particular website. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. While there are a lot of Spidering tools, the following example uses the Zed Attack Proxy (ZAP) :
ZAP offers the following automatic spidering features, which can be selected based on the tester's needs:
- Spider Site - The seed list contains all the existing URIs already found for the selected site.
- Spider Subtree - The seed list contains all the existing URIs already found and present in the subtree of the selected node.
- Spider URL - The seed list contains only the URI corresponding to the selected node (in the Site Tree).
- Spider all in Scope - The seed list contains all the URIs the user has selected as being 'In Scope'.
Tools
References
Whitepapers