Antisyphon KB

Web App Checklist from WAHH

Nov 04, 20248 min read

Web Application Penetration Testing Checklist

BHIS methodology reflects a very standard approach which is beautifully captured and expressed in the Web Application Hacker’s Handbook. This is an outline of areas for consideration and is not inclusive of every aspect or feature nor is it followed by rote as every application and implementation has its own unique features and considerations.  This list provides a very useful approach for any testers consideration.

Reconnaissance and Analysis

  • Map visible content
    • Explore the entire application while passively capturing traffic with Burp Suite. Ideally, save one state file for each privilege level. That is, explore all you can without logging in, and save that state file. Then start a new one, log in as a normal user and explore all you can and save that one. Then start a new one, log in as an administrator, etc. This lets Burp help you with privilege escalation tests later.
  • Discover hidden & default content
    • Set Burp Suite’s scope with these two things in mind:
      • Don’t exceed the scope of the assessment. But also be wary of setting scope too soon and missing things on different domains than the logon page.
      • Mark as “out of scope” anything that you may regret sending automated attacks against. (e.g. logout, creating/deleting objects, sending emails)
    • After the scope is defined, open the Target > Site map. Right-click on the root of the server (or a subfolder if you want to limit things) and choose Engagement Tools > Discover Content. The “engagement tools” are only in the Pro version.
    • Configure this so it does not add discovered content to the main site map
      • …because not all discoveries are real, and it can make a mess of your sitemap when the server returns HTTP 200 and a friendly error for content-not-found
    • This step can take a while. Let it run while you do other things. It overlaps a bit with dirbuster (which is now part of OWASP ZAP), but they take different approaches.
    • Run gobuster, too, if you have time.
  • Identify data entry points
    • In Burp’s Target > Site map again, right-click on each in-scope hostname and choose “Enagement Tools > Analyze target”
    • Save the output as HTML for reference.
    • Look for interesting pathnames, parameters, and cookies:
      • Base64-encoded strings
      • Hashes
      • Identify delimited strings, and test each part separately
      • Find parameters that may be Direct Object References
  • Identify the technologies used
    • Look at HTTP response headers, HTML comments, error messages, etc, and use the browser plugin Wappalyzer in order to identify the components.
    • Search for published vulnerabilities in those things.
    • Tailor your manual attacks to the technologies actually in use, to make better use of limited time, but don’t over-configure automated tests.
  • Map the attack surface
    • Decide where to focus your efforts, given the limited time you have, based on risk, and based on the population of potential attackers. For example: anyone can visit the anonymous parts, and the login page is sensitive, so hammer on that before you go looking for CSRF in pages only available to authenticated users.
  • Test for debug parameters
    • Use Burp Intruder to insert common debugging parameters in interesting requests. e.g. “debug=1” or “test=true” or “verbose=yes” or just “&debug”
    • Recognize the naming conventions in the app you are testing. Try to guess parameters and values that follow these conventions.
  • Run the Burp Active Scanner on selected interesting URLs
  • Scanning the entire application can take a long time
  • Be sure to configure session management, too

Test Handling of Access

  • Authentication
    • Understand all the factors that go into authentication (sessions are described below)
    • Usernames and passwords are usually components of authentication, but what else? user-agent? geolocation? historical data? privilege levels?
  • Test/discover password rules:
    • length
    • allowed/required character types?
    • case-sensitive?
    • is the whole thing validated? (e.g. leave the last char off - does it still work?)
  • Test for username enumeration
    • On the login page
    • On the “Forgot My Password” page
    • On the registration/self-enrollment page
  • Test resilience to password guessing
    • How many bad guesses are accepted before users are locked out?
    • How is that counter incremented? Look for client-controllable aspects (e.g. request parameter, source IP, other client “fingerprint” kind of thing)
  • Test any account recovery function
    • Can you steal another user’s account this way?
    • If tokens are used, are they random, short-lived, and expired on first use?
    • Can you harvest usernames this way?
  • Test any “remember me” function
    • Does it allow you to bypass any controls?
    • Does it allow you to impersonate another user?
  • Test any impersonation function
    • Does it clearly show you’re “impersonating” and not actually the other user?
    • Does it log who the actor is (as distinct from the impersonated user)?
    • Does it allow privilege escalation?
  • Test username uniqueness
    • If two users can have the same username, bad things may be possible.
  • Check for unsafe distribution of credentials
  • Test for fail-open conditions
    • Omit important parameters from sensitive requests
  • Test any multi-stage mechanisms
    • Can you bypass a stage?
    • Can you defeat validation by changing some value after it’s originally checked?
  • Session handling
  • Test tokens for meaning
    • Determine which tokens are necessary for session mgt
    • Determine how they are used, and what happens if you modify or forge them
    • See if there’s anything meaningful in them (e.g. a username, privilege level, etc)
      • Burp Sequencer can highlight areas of less entropy - focus on those.
  • Test tokens for predictability
    • Use Burp Sequencer to collect 10,000 tokens for statistical analysis
    • Pay close attention to the configuration, here, particularly around padding and decoding of tokens or token segments.
    • Save your collected tokens as a text file so you can re-do analysis as needed.
  • Check for insecure transmission of tokens
    • In a query string in a URL?
    • Without TLS?
    • In email?
  • Check for disclosure of tokens in logs
  • Check mapping of tokens to sessions
  • Check session termination
    • Log out, then restore the session cookies and re-visit an authenticated page.
    • If you get the page, the server is not destroying the sessions as it should.
  • Check for session fixation
    • Set your own value for the session cookie before logging in & see if it’s accepted
    • Start with one that’s syntactically valid so you don’t get denied based on formatting alone.
  • Check for cross-site request forgery
    • If there’s an anti-csrf token, is it sufficiently random? Is it verified every time?
    • Omit the csrf token & make sure the request fails.
    • Modify the csrf token & make sure the request fails.
    • Use a valid csrf token from another session & make sure the request fails.
  • Check cookie scope
    • The scope of the domain and path should be as narrow as possible.
    • “secure” and “HttpOnly” flags should be set
  • Access controls
    • Understand the access control requirements
    • Test effectiveness of controls, using multiple accounts if possibles
      • Try one user’s internal identifiers when logged in as another user
  • Test for insecure access control methods (request parameters, Referer header, etc)
    • If the method can be modified by a user and is not authenticated, that is a problem.

Test Handling of Input

  • Fuzz all request parameters
  • Test for SQL injection
    • Run sqlmap.py against a selection of URLs & parameters.
  • Identify all reflected data
  • Test for reflected cross-site scripting (XSS)
  • Test for HTTP header injection
  • Test for HTTP parameter pollution
  • Test for arbitrary redirection
  • Test for stored attacks
  • Test for OS command injection
  • Test for directory traversal
  • Test for script injection
  • Test for file inclusion
  • Test for SMTP injection
  • Test for native software flaws (buffer overflow, integer bugs, format strings)
  • Test for SOAP injection
  • Test for LDAP injection
  • Test for XPath injection

Test Handling of Files

  • Can you download what you upload? (looking for web shells)
  • Can you download what others upload? (and is that OK?)
  • Can you upload something the server will treat as code (e.g. PHP or server-side-includes or Python/Perl/Shell scripts?)
  • Can you download other arbitrary files? (like server-side source code or /etc/shadow like that commercial dishwasher allows)
  • Can you upload malware? Will someone open it?
  • Can you use it to share questionable files with your criminal friends?
  • Can you upload a huge file or a bajillion little ones and fill up the disk? Test application logic
  • Identify the logic attack surface
  • Test transmission of data via the client
  • Test for reliance on client-side input validation
  • Test any thick-client components (Java, ActiveX, Flash)
  • Test multi-stage processes for logic flaws
  • Test handling of incomplete input
  • Test trust boundaries
  • Test transaction logic

Assess Application Hosting

  • Test segregation in shared infrastructures
  • For multi-tenant installations, discover the tenant identifier.
  • Submit a different known-good tenant identifier & make sure the request fails
  • Test segregation between ASP-hosted applications
  • Test for web server vulnerabilities
  • Default credentials
  • Default content
  • Check for dangerous HTTP methods (such as DELETE, TRACE)
  • For most sites, GET & POST should be all that’s needed.
  • Send the OPTIONS HTTP header to see what’s advertised
  • Try each advertised verb to see if it’s actually implemented
  • Try a GET as a HEAD and see if authorization is bypassed
  • Try a POST as a GET and see if it works (makes attacks easier)
  • Try a GET as a POST and see if it works (shows lazy validation)
  • Proxy functionality
  • Virtual hosting misconfiguration
  • Bugs in web server software

Miscellaneous Tests

  • Check for DOM-based attacks
  • Check for frame injection
  • Check for local privacy vulnerabilities
  • Persistent cookies
  • Caching
  • Sensitive data in URL parameters
  • Forms with autocomplete enabled (but not for login forms: browsers don’t enforce “autocomplete=‘off’” anymore for login forms, in an effort to encourage use of password managers.)
  • Follow up any information leakage
  • Check for weak SSL ciphers

SAML-based tests

  • Assertion verifications
  • Assertion audience and issuer manipulation
  • Signature wrapping
  • Self-signed assertions and messages
  • Signature removals
  • Time-frame condition manipulation
  • Attribute value manipulation

Graph View

Backlinks