Back

Article: A Security Checklist for Web-Apps


1. Recon and analysis

This is the first and most important step when pentesting web-applications. The bigger the scope, the higher the possibility for finding a bug resulting in a security vulnerability.

# Description Done
1.1 Map visible content
1.2 Discover hidden & default content
1.3 Identify the technologies used
1.4 Test for debug parameters
1.5 Identify data entry points

2. Test handling of access

I recommend splitting the application into it's authenticated and unauthenticated part and then testing both parts equally. Most vulnerabilities I encountered are features which needs authentication. The most unprotected part is often an administration panel (how ironic).

# Description Done
2.1 Authentication
2.2 Test password quality rules
2.3 Test for username enumeration
2.4 Test resilience to password guessing
2.5 Test any account recovery function
2.6 Test any "remember me" function
2.7 Test username uniqueness
2.8 Check for unsafe distribution of credentials
2.9 Test any multi-stage mechanisms
2.10 Session handling
2.11 Test tokens for meaning and predictability
2.12 Check session termination
2.13 Check for session fixation
2.14 Check for cross-site request forgery
2.15 Check cookie scope
2.16 Access controls
2.17 Test effectiveness of controls, using multiple accounts if possible
2.18 Test for insecure access control methods (request parameters, Referer header, etc)

3. Test handling of input

Fuzzing is the key for breaking an application's logic. The most important indicator here is the Content-Length of the HTTP response. A web-application dropping a 5XX HTTP status code is also a good indicator that something went wrong.

# Description Done
3.1 Fuzz all request parameters
3.2 Test for SQL injection
3.3 Identify all reflected data
3.4 Test for reflected XSS
3.5 Test for HTTP header injection
3.6 Test for arbitrary redirection
3.7 Test for path traversal
3.8 Test for insecure direct object reference

4. Test application logic

Always try to understand what the developer might have thought. Just blindly hammering payloads won't bring good results. Sometimes it's hard to identify the behavior of an application through a blackbox attempt. Developer skills might become very handy here.

# Description Done
4.1 Identify the logic attack surface
4.2 Test transmission of data via the client
4.3 Test for reliance on client-side input validation
4.4 Test multi-stage processes for logic flaws
4.5 Test handling of incomplete input
4.6 Test trust boundaries

5. Assess application hosting

All these steps could be also included in the recon-process described at 1.

# Description Done
5.1 Test for web server vulnerabilities
5.2 Default credentials
5.3 Default content
5.4 Dangerous HTTP methods
5.5 Test handling of incomplete input
5.6 Test trust boundaries

6. Miscellaneous tests

This checklist is really incomplete and lacks a lot of newer attacks like "HTTP Response Splitting". Feel free to improve it by yourself.

# Description Done
6.1 Check for DOM-based attacks
6.2 Check for frame injection
6.3 Check for local privacy vulnerabilities
6.4 Caching
6.5 Sensitive data in URL parameters
6.6 Follow up any information leakage
6.7 Check for weak SSL ciphers