Web App Penetration Testing Checklist

The below are some common checklist for web application penetration testing.

Information Gathering

Spiders, Robots, and Crawlers
- Burpsuite crawler.
- Check robots.txt.
- Check the sitemap.xml file.
Search Engine Discovery/Recon
- Google, Bing, Yahoo, Duckduckgo Dorking.
- Github Dorking.
- Pastebin search.
- Shodan search.
- Gitlab search.
- Wayback machine search.
- Google cache search.
- Stackoverflow check.
Identify application entry points
- Dirsearch:- search the directories and exposed entry points.
- Burpsuite passive scan/crawler.
- Burpsuite > engagement tool > analyze target.
Testing for Web App Fingerprint
- Wapplyzer.
- Whatsruns.
- Check session-id parameter name. For e.g., ci=session_id (ci session is set by CodeIgniter framework).
- Check comments in js and CSS files for framework version or name enumeration.
Application Discovery
- Burp Discovery Content.
- Dirsearch.
- Dirbuster.
Analysis of Error Codes
- Check verbose error message for technology or server/application data leakage.

Configuration Management Testing

SSL/TLS Testing
- Check if application/server is using SSLv2/SSLv3(nmap).
- Check the TLSv 1.1 & TLSv 1.2.
- Check the Renegotiation Check.
- Check Certificate public key size is not less than 2048 bit.
- Check the valid certificate chain (Valid Root CAs).
- SSL certificate expiring date.
- Certificate Signatures.
- Check SSL weak cipher implementation not less than the 256-bit encryption key.
- Avoid RC4 cipher suites.
- Avoid CBC mode in ciphers.
- Check HSTS headers and secure flag in the cookie section, if SSL implemented (Dynamic Web Application).
DB Listener Testing
- Check if the DB listener port is open on the portal and shows a database banner. If you are able to see the banner(DB version and name), then you can try the public available exploits on the specific version.
Testing for File Extensions Handling
- If the Application has a file upload section, then you can try the below test cases
  - Change the file extension to a specific language-based application e.g., if the application in asp.net then use .aspx at the end of the file to check if the application accepting the code file.
  - Use Double file extension if single file extension not accepting like .aspx.jpg, and after successful upload remove the last extension to check if the file gets executed.
  - Change the MIME Type(Content-Type) of a file, and the file extension remains the same as shown below.

Content-Description: fomr-data; name="upload-file_test"; filename="test.jpg"
Content-Type: text/php

Old, backup, and unreferenced files
- Check if an application reveals any old backup files like .log, .bak, etc. This can be check via Dirsearch, or content discovery.

Testing for HTTP Methods and XST
- Check if dangerous HTTP methods are enabled or not like: Trace, Delete, PUT, CONNECT, etc.

Authentication and Session Management Testing

User Enumeration.
Brute force attack.
Auth bypass via SQL injection.
Weak session implementation.
Session Complexity.
Session Fixation attack.
Session Hijack attack.
Cookie without a secure flag.
Parameter Pollution.
Cookie without HTTP Only flag.
Missing CSRF/SSRF token.
Multiple AUTH alert not implement.
The user lockout policy not implemented.
Change the current invalid auth session response to valid previous auth response, for auth bypass with response modification.

Captcha test:-

Remove the captcha parameter to check if the server accepting the request without a captcha.
Use Previous captcha value to check if the captcha value does not validate by the server.
Captcha brute force.

2FA(OTP):-

OTP brute-force attack.
OTP Reuse.
OTP Flooding.
SMS flooding.
Email flooding.
OTP not expired.
Remove the OTP parameter/value to bypass the login.

Social login check:-

Basic flow:-

Site.com requests Facebook/google for AUTH token > Facebook/google verifies user account > Facebook/Google send call-back code > Site.com logs user in.

Testing checklist:-

We can check the call-back code from Google/Facebook to site.com. In the response, if it discloses the user details, like email, userid, etc., tries to change other existing user details for social auth bypass.

Check client-side social login flow in js files, some time developer set some validation on the client-side also.

Note:-
The Authentication flow for every application can differ as per their business requirements. So always check each and every parameter and their value uses and validation.

Authorization Testing

Testing for Path Traversal.
Testing for bypassing authorization schema.
Testing for Privilege Escalation.
Testing for IDOR’s.
Testing for Redirect without Exit.
Testing for Force Browsing.

Business Logic Testing

Business logic testing always depends on application flow and business requirements. We recommend, always check and analyze each and every parameter value and its usage.