Web Application Penetration Testing Check List – Based on OWASP Top 10 2017

Web Application Penetration Testing is a security test performed on a web application to make it hack proof. While performing a penetration testing on a web application the security engineer will check if the given web application is vulnerable to vulnerabilities like SQL Injection, Cross Site Scripting (XSS),  IDOR’s etc.

                                 Web Application penetration testing must follow an accepted standard say OWASP Top 10, SANS etc of which OWASP Top 10 is the most widely accepted. This guide follows OWASP Top 10 2017 standard as it is the most widely used and accepted one. OWASP maintains a list of Top 10 vulnerabilities affecting a web application and will release an updated list every 3 years. We here follow the latest revised edition that is OWASP Top 10 2017.

The below-given image shows the difference between OWASP Top 10 2013 and 2017.

A4 IDOR and A7 Missing function level Access control got merged together to form A5 Broken Access Control.  A8 CSRF got removed from the Top 10 list as the occurrence rate of CSRF is very low nowadays. Also, they added A4 XXE, A8 Insecure Deserialization, and A10 Insufficient Logging and Monitoring to the list.

Top 10 Vulnerabilities to check in a Web Application according to OWASP 

1. Injection Vulnerabilities
2. Authentication Vulnerabilities 
3. Sensitive Data Exposure
4. XXE
5. Broken Access control 
6. Misconfiguration 
7. Cross-Site Scripting 
8. Insecure Deserialization 
9. Using Components with known vulnerabilities 
10. Insufficient logging and monitoring

 

Checklist 

 

Information Gathering 

1. If the subdomains are not documented and given use tools like Knockpy to search for subdomains. Check if they have any subdomains pointing to services like Heroku, Github, Shopify etc. If yes check if it is vulnerable to subdomain takeover vulnerability. 
2.  Using DirBuster search for directories and files. It uses brute-force technique using a given set of wordlist to find directories and files. It will give information about few directories and files which crawlers won’t be able to detect.  Check if any configuration files or any files exposing critical data is present in the DirBuster results.
3. Analyze the robot.txt file. It may contain links to some pages which is the site admin doesn’t want search engine robots to crawl.
4. Find the technologies powering the web application. Analysing the Request/Response, Error page information disclosure etc will help us in finding out the technologies powering the website.
5. Identify the CMS (if it uses one) and the CMS version.
6.  Identify the application entry points. Using an intercepting proxy tool like Burpsuite or OWASP Zap intercept the request and note down the parameters getting passed as a GET/POST request also check if anything critical is getting passed through a GET request say a Session ID. Watch out for interesting headers and its values.
7. Crawl the entire application using a crawler. You can use Burp Spider or ZAP Spider to perform the same.
8. Read the source code and see if anything critical is there say a hardcoded password.
9. Do a Nmap scan to see what all services are running on the web server and its version so as to check if it is vulnerable to some exploits.

Injection Vulnerabilities

1. Check if the web application is vulnerable to SQL Injection. Use tools like SQLMap, SQLNinja to check if it is vulnerable to SQL Injection vulnerability. Perform tests to check if it is vulnerable to Inband, Out-of-band and blind SQL Injection attacks.
2. If the web application uses user inputs to construct LDAP statements, perform an LDAP Injection test
3. Check if the web application is vulnerable to Command Injection.
4. If the web application uses any type of template engines, Check if the web application is vulnerable to Template Injection. The impact and severity of this issue depend on the template engine that the website use. 
5. If the web application is using an XML style communication, an attacker can send XML documents to the web application and if the XML Parser fails to validate the data XML injection attacks will occur. So check if the site is vulnerable to XML Injection vulnerability.
6. If the web application is constructing XPath queries from user-supplied data, Test for XPath Injection Vulnerability.
7. Check for Buffer overflow vulnerabilities.

Authentication and Session Management Vulnerabilities

 

1. Check if the session is still active after a logout.
2. Check if the session is still active after a Password Reset.
3. Check if the session is getting expired due to inactivity (If required).
4. Check if the password field is vulnerable to brute-force attacks. The application must lockout the account or implement CAPTCHA mechanism if it detects brute-force attacks.
5. Check if user enumeration is possible. Use password reset option to check if user enumeration is possible or not 
6. Check whether the password reset token is predictable.
7. Check if the password reset token is expiring.
8. Check if the password reset token is reusable.
9. Check whether the old password reset token is expiring after generating a new one.
10. Check if it vulnerable to Session Hijacking.
11. Check if any Tokens are getting passed as a GET parameter.
12. Test for Cross-Site Request Forgery 
13. Check if the 2 Factor Authentications can be bypassed.

Sensitive Data Exposure 

1. Use the Dirbuster result to check if any .config files are exposed to the public.
2. Check if any server-side files are exposed to the public.
3. Check if any error messages disclose sensitive data. If the debug mode is ON, the application will throw out a lot of sensitive data with the error message.
4. Check if Directory listing vulnerabilities are present or not.
5. Check if the Source code contains any sensitive data as comments.
6. Check if the Source code contains any hardcoded passwords with it.
7. Check if the Transport Layer Protection is implemented properly.

XML External Entities (XXE)

1. Check if the web application process XML Inputs.
2. if the web application process XML Inputs check if it is vulnerable to XXE.

 

Broken Access Control 

 

1.  Check if the application is vulnerable to IDOR. 
2. Check if the application is vulnerable to Directory Traversal.
3. Check if privilege escalation is possible or not. ( if a normal user can perform a task which is meant to be performed by the admin only is known as Privilege Escalation).
4.  Check if a particular file can be accessed without authentication.
5.  Check if it is possible to access functions and files which is accessible to users with a different set of privilege.

 

Security Misconfiguration 

1. Check if the Web Application is configured properly.
2. Check if the permission level configuration is proper.
3. Check if any unnecessary HTTP methods are enabled or not (NC www.site.com 80
   OPTIONS).
4. Check if the HSTS Configuration is correct and implemented properly.

 

Cross Site Scripting 

1.  Check if the given site is vulnerable to Cross-Site Scripting. Check for Stored, Reflected and DOM XSS.
2. Check for Blind XSS. Use the website xsshunter to check for Blind XSS. Also one can use the tool knoxss for better detection rate.
3. Check if chaining of vulnerabilities to increase the impact is possible or not.

Insecure Deserialization

 

1. Check if the website is prone to DoS attacks due to Insecure Deserialization.
2. Broken access control?
3. If Authentication bypass is possible.
4. Check for Remote Code execution possibilities.

Using Components with Known Vulnerabilities

1. Check and make sure that all components are up-to-date and no vulnerable components are being used.

 Insufficient logging and monitoring

 

1. Ensure all activities are getting logged properly.