The methodology is based on the Web Application Hacker’s Handbook 2nd Edition with some additional modification and adjustment. It is intended for grey-box testing of a web application for 2 weeks of engagement. You can use it for your testing, however, I would recommend creating sth similar for yourself just to establish the defined methodology for the web pentest. Let’s get started:

Day 1:

To complete:

I. Mapping Application

  1. Explore Visible Content with passive spidering
  2. Review the webroot dump for the public resources, review the docs, and design diagrams.
  3. Enumerate API endpoints/function for the testing
  4. Test for Debug enabled. Check for debug=true, use any of the common values such as - debug, test, hide, a source with the common values such as - true, yes, on 1. Use those values in parameter, header, and body.

II. Analyze the Application

  1. Identify Functionalities (in scope)
  2. Identify Data Entry Points
  3. Identify Technologies Used.
  4. Map the attack surface
  5. For each functionality identify the kinds of vulnerabilities associated with it.
  6. Create the plan of the attack with prioritization for a given time.

Update to the team:

  • Completed actions,
  • Possible issues identified,
  • Possible blockers,
  • Plan for the attack,

Day 2:

To Complete

III. Client-Side Controls

  1. Identify all hidden forms, fields, cookies, parameters. Determine the purpose and logic of the hidden value.
  2. Modify the hidden values according to there purpose.
  3. Attempt to decipher, deobfuscate hidden values.
  4. Verify that client limitation are also in place. Confirm whether the application relies on client-side controls for the input check.
  5. If you find disabled HTML input, try to send them in the repeater.
  6. If browser extension is required, apply additional testing for that.
  7. For the identified endpoint identify if different HTTP methods can be used. Identify if HTTP methods can be overwritten.

IV. Test Authentication Mechanism

  1. Locate all authentication-related mechanisms (login, registration, recovery)
  2. Test password quality (rules of the password, test if the password validation is complete). Determine the probability of success in the brute-force attacks.
  3. Test for Username Enumeration. Where the application expects the username, submit one valid and one invalid, and observe the differences.
  4. Check for account lock-down policy
  5. Test account recovery function. Check how it works, if there is a challenge as a secret question, harvest the list of questions and check for predictable answers. If it involves sending an email, check it is possible to control any of the parameter (SMTP part, URL parameters)
  6. Test remember me function. Inspect all persistent cookie - try to tamper the cookie, compare the results of remembering several accounts.
  7. Test any impersonation function. Try to use the functionality for privilege escalation.
  8. Test username uniqueness. It may allow enumerating valid usernames. If the collision is allowed, try to hijack other user’s accounts.
  9. Test the credential transmission (non-TLS, URL parameters, leakage by the Referer, if the credentials are stored in cookies)
  10. Check for credentials distribution ( if confirm URL must be clicked, register few accounts and check if the token is predictable)
  11. Test for fail-open when it is possible to edit password and log in.
  12. If the multistage mechanism in place, test it, proceed with all stages in a different sequence. Proceed directly to each stage and then continue the normal flow. Try skipping some stages. Think for further cases to push the staging to its limits.
  13. For multi staging, check if the parameter is submitted in different stages. Example username. Try to modify it, if that is possible to authorize as other users.
  14. For multi staging, if the application requires the challenge on any stage test the two common defects:
    • If the challenge is sent with the user’s response with the same request try to set your challenge.
    • Try submitting again the request generating the challenge, if it varies with every response you can set your challenge by repeatedly requesting the challenge.

V. Session Management Mechanism

  1. Analyze the mechanism used for session management, identify the item used to represent the user’s session. Check if the whole token is validated by modifying the single bytes.
  2. Analyze the token itself, entropy, correlation with username, different encoding.
  3. Check if the token appears to be CBC encrypted - use Bit Flip Burp Intruder
  4. Check for insecure transmission of the token - cookie without secure flag, non-TLS, URL param
  5. Login and logout several times to determine if the session token is dynamic
  6. If the JWT is used, try JWT vulns.
  7. If the cookie consists of any user part, try tampering it.
  8. Check if the application supports concurrent session by login in two different web browsers
  9. Check the session expiration ( Burp Intruder increment the time)
  10. Check if the logout function is effective. Attempt to reuse the old token.
  11. Check for session fixation. If the new token is generated after login or is it reused.
  12. Check for CSRF - missing anti-CSRF, also if exploit possible through a simple HTTP request.
  13. Check cookie scope’ing - if the parent domain is specified for authentication cookie.

Update to the team:

  • Tests performed,
  • Findings,
  • Blockers

Day 3-4:

To complete:

VI. Access Control Testing:

  1. Build an understanding of the possible horizontal and vertical priv escalation.
  2. If there are vertical priv escalation possible, identified endpoints/functionalities accessible only to those privileged accounts. The use of the less privileged account to try to access those resources.
  3. For each user privilege, review resources available to a user. Attempt to access those resources from an unauthorized user account by replaying the request using the unauthorized user’s session token.
  4. Check if a user with the same privilege can access or modify the data belonging to other users with the same privileges.
  5. In multistage functionalities, check if other stages of the functionality correctly implement the access control.
  6. Test for insecure access control methods:
    • Look for parameters such as edit=false or access=read in any key requests, and modify these in line with their apparent role to try to interfere with the application’s access control logic.
    • Check if the Referer or Origin header is used for access control.
    • In case some specific HTTP methods are blocked for a specific role for URL try the - X-Original-URL or different method of URL rewrite. Try the HEAD HTTP method if it is allowed by the webserver.
  7. Check for IDOR - Insecure direct object reference

Update to the team:

  • Tests performed,
  • Findings,
  • Blockers

Day 5-6:

To complete:

VII. Input-Based Vulns

  1. If possible try to fuzz all parameters for:
    • SQLi
    • XSS and Other Response Injection (XSS Reflected/Stored, Header Injection, Open Redirection)
    • Command Injection
    • Path Traversal
    • Script Injection
    • File Inclusion
    • Template Injection
    • SSRF
  2. Use the Grep Burp function to look for specific values in the response or second-order page.
  3. Exploit the vulnerability of proofs.
  4. If fuzzing is not possible e.g. the application has the flow that cannot be abused.
  5. Identify the parameters/functionalities that may be specific to the vulnerability e.g. parameter “path” should be tested for File inclusion, SSRF, Path traversal.
  6. Once identify try the payloads specific to the “possible vulnerabilities” for the functionality.
  7. Exploit the vulnerability.

VIII. Test for Function-Specific Input Vulnerabilities

  1. Depending on the application mapping there are specific vulnerabilities that may exist in the web application.
  2. Test for those vulnerabilities:
    • SMTP Injection
    • Overflows and format string (for custom C/C++ web servers)
    • SOAP Injection
    • LDAP Injection
    • XPath Injection
    • SSRF
    • XXE
    • Test File upload (Upload web shell, upload EICAR, try extension blacklist/whitelist bypasses, try path traversal and XSS through filename, try XSS through uploading HTML file)

Update to the team:

  • Tests performed,
  • Findings,
  • Blockers

Day 7-8:

To complete:

IX. Logic Flaws

  1. Identify the following features in the web application:
    • Multistage process,
    • Critical Security Functions e.g. login, password reset,
    • Trust Boundaries ( from anonymous to self-registered to logged in)
    • Context-based functionality e.g. withdrawing money
    • Adjustment to fees, quantities, etc.
  2. Multistage process:
    • Attempt to submit requests out of sequence. Try to skip some stages.
    • Try to take parameters from the previous stage and send them in the next stage to interfere with the process and maybe modify some values.
    • If the process involves the different users to submit something, try to submit the request as the current user.
    • Try to determine the assumptions made by the developers in context-based function, try to abuse those,
  3. Test Handling Incomplete Input.
    • For critical functions, test the application resilience on the incomplete request e.g. remove the parameter or value.
  4. Trust Boundaries:
    • Check specific cases that would normally not occur when trust boundaries are changed: e.g. when performing the password reset, do not complete it but move directly to the auth user context.
    • Try to determine if you could harness directly or indirectly higher privilege function
  5. Transaction Logic:
    • Test negative values in the transaction, check how the application reacts.
    • Identify if any fees can be manipulated by the user.

Update to the team:

  • Tests performed,
  • Findings,
  • Blockers

Day 9:

To complete:

X. Misc Testing

  1. Find Vulnerable Components e.g. Burp Vulnerability Scanner.
  2. Examine Webserver Config e.g. Weak Tomcat creds.
  3. Examine Default Content on the webserver e.g. phpinfo
  4. Check for CORS Misconfiguration.
  5. Test TLS Config.
  6. If Websockets are being used, test for websocket hijacking.
  7. Test for HTTP Req Smuggling.
  8. Test for Web Cache Poisoning.
  9. Identify Cross-site leaks.
  10. If you have time, analyze statically JS files for DOM-based attacks.
    • Identify all uses of the following APIS, which can be used to access DOM data via crafted URL: document.location, document.URL, document.URLUnencoded, document.referrer, window.location
    • Check if the data from the user is passed to one of the following functions for DOM XSS: document.write(), document.wirteln(), eval(), window.execScript(), window.setInterval(), window.setTimeout()
    • Check if the user data is passed to one of the following functions for redirections: document.location, document.URL, document.open(), window.location.href, window.navigate(), window.open()
    • Check for postMessages() related XSS.

Update to the team:

  • Tests performed,
  • Findings,
  • Blockers

Day 10:

To complete:

  1. Reporting
  2. Final call with the Development Team.