Web Application Penetration Testing: Steps & Test Cases

How secure are your web applications, really? Consider the risk of a malicious actor exploiting hidden vulnerabilities before you have the chance to address them. Web Application Penetration Testing is crucial for discovering these weaknesses. By simulating real-world attacks, it not only identifies potential threats but also provides insights into your application’s resilience. In this blog, we’ll explore everything you need to know about web app pentesting.

What is Web Application Penetration Testing?

Web application penetration testing involves a methodical series of steps aimed at gathering information about the target system, finding vulnerabilities or faults in them, researching for exploits that will succeed against those faults or vulnerabilities and compromise the web application.

1. OWASP Top 10

The Open Web Application Security project (OWASP) is a community that focuses its efforts solely on discovering and reporting on web application security vulnerabilities.

Their reputable list of Top 10 security flaws is updated every year to reflect the global trends in the security of web applications. OWASP also publishes articles and security tools that are most practiced. OWASP’s testing methodology handbooks are recognized by the industry.

2. SANS Top 25

The SANS Top 25 is a list created by the SANS Institute in collaboration with the MITRE Corporation. It identifies the most common and critical security vulnerabilities and programming errors that can lead to serious security issues in software.

The list is periodically updated to reflect new vulnerabilities and trends in the security landscape.

What Steps And Methodologies Are Used To Perform A Web App Pentest?

To distinguish between general applications and web applications, web application penetration testing primarily focuses on the environment and setup of the web app.

In other words, testing the web application focuses on gathering public information about the web app and then continuing to map out the network involved in hosting the web app. Investigating for possible injection tampering attacks and the actual learning and handling of the application comes later.

Step 1: Information Gathering

Information gathering, or the reconnaissance phase, is the most important step in any penetration testing process as it provides you with a wealth of information to identify vulnerabilities easily and exploit them later.

There are two types of reconnaissance depending on the type of interaction you want to achieve with the target system:

1. Passive Reconnaissance
2. Active Reconnaissance

1. Passive Reconnaissance

Gathering information that is already available on the internet and doing so without directly interacting with the target system is called passive reconnaissance.

Most research in this phase is done online using various websites, beginning with Google. The first step often involves using Google syntax, enumerating website subdomains, links and much more.

For example, if subdomains of a certain website are of interest, you can use the following syntax to narrow down the Google search results: “site:*.domain.com”.

You can use Wayback Machine to view how a certain website looked a while back ago, this website can help you interact with the target of the web application without directly coming into contact with it.

You can probe the old version of the website and note down any characteristics that might help you later in the research and exploitation phase.

Phonebook.cz  & Wayback Archive are utilized to find subdomains & URLs of the web applications that are exposed to the internet. In these URLs, the GET API request’s parameters are also cached leading to information leakage about the application or the users.

2. Active Reconnaissance

In contrast to passive reconnaissance, active reconnaissance directly probes the target system and retrieves an output.

Examples of active reconnaissance include fingerprinting the web application, using the Shodan network scanner, performing a DNS forward and reverse lookup, a DNS zone transfer, and more.

• Fingerprinting The Web Application Using Nmap

Fingerprinting a web application involves gathering information about the web app such as the scripting language used, server software and version, along with the OS of the server. Much of this can be done using the Nmap network scanner.

Run the Nmap against the target IP or the target IP range and note down all open ports and services that are running, along with the above-mentioned information regarding the OS version.

• Shodan Network Scanner

Using the Shodan network scanner, you can identify additional information regarding the hosted web app if publicly available to the internet.

Shodan provides vast information regarding any publicly available IP that it scans. Information ranges from geolocation, port numbers opened, server software used and a few other useful details.

• DNS Forward And Reverse Lookup

In order to associate the newly discovered subdomains with their respective IP addresses, you can use forward dns lookup, ping, and even use more advanced tools such as Burp Suite.

• DNS Zone Transfer

To perform DNS zone transfer, use “nslookup” command to identify the DNS servers. Other options are websites specifically made for DNS server identification. After identifying all the DNS servers, use the “dig” command and attempt the DNS zone transfer.

• Identifying Related External Sites

This is an important step in the information gathering stage, as there is usually traffic flowing between external sites and the target site. This is done easiest with Burp Suite, which we will cover in more detail later.

• Inspect HEAD and OPTIONS HTTP requests

Responses from HEAD and OPTION requests will most definitely reveal the web server software and version. Sometimes the responses contain even more valuable data.

You can easily intercept this information by visiting the target website while having Burp Suite’s “intercept on” feature turned on.

• Gather information about the web app through error pages

Error pages can provide a lot of useful feedback regarding the version and type of server the website is ran on. Based on this information you can start visualizing the environment of the web application.

Simply modify the URL of the desired website and try to cause the 404 not found error. In the case below, a website forum not found page reveals the server and its version (ngnix/1.12.2).

• Examining the Source Code

Source code can also provide a lot of useful information that you can later use to find a vulnerability.

By examining the webpage code carefully, you will be able to determine the application environment and the overall workings of the application.

In the screenshot below, we can see that the website is running on IISserver, version 10.0.

• Documenting during the Reconnaissance Phase

It is vital to document everything in an organized manner during reconnaissance phase. This will prepare a baseline from which further exploitation will be done.

Step 2: Vulnerability Assessment

The first step in pentesting involves determining which tools to use for web application penetration testing.

The entire penetration testing process depends deeply on the reconnaissance phase and the discovered vulnerabilities. Finding the right exploit and gaining access into the system is far easier with a thorough investigation.

Popular tools commonly used during website penetration testing include:

• W3af
• Burp Suite
• SQLMap
• Metasploit
• Wfuzz
• WpScan
• Nuclei
• FFUF
• Nikto

For automated web app vulnerability scanning, sniffing and exploitation stages, tools like nikto, nuclei, burp suite etc are used. 

The below list of tools and their capabilities will give you an introduction into what is possible with just a little bit of tampering with a vulnerable web application.

1. Burp Suite

Burp Suite is an open-source web application penetration testing tool that comes in two options. The open-source version is free to be used by anyone but with various features missing from the tool.

The various capabilities within Burp Suite make it an all-around web application security testing tool that can be used throughout the entire penetration testing process. Gathering http traffic with Burp Suite is easy and the possibilities are vast in the area of exploitation.

For the purpose of demonstrating the most useful aspects of Burp Suite, below is a simple example of capturing http traffic with Burp Suite and then performing an SQL injection attack using Sqlmap.

To start, open Burp Suite by navigating to the left side of your Kali Linux desktop and find Burp Suite in the category of “Web Application Analysis” tab. After loading, make sure your “intercept” tab has “intercept is on” selected.

Next, set up Burp Suite to act as your web proxy in your Firefox browser. Open the “preferences” button, go to “advanced settings” > “connection settings” & choose “manual proxy configuration” and fill in the IP address and port numbers: 127.0.0.1 and 8080.

Now that everything is set up, navigate to your target website through your Firefox browser. All the traffic captured using the burp suite’s proxy can be seen in the ‘Http History’ tab of the burp suite.

2. Cross-Site Scripting (XSS)

There are many online scanning tools that can automatically provide a comprehensive security scan of a desired website. This can be used as a quick method to confirm present vulnerabilities.

The same results can be achieved using the W3af framework. To test for this attack, penetration testers usually intercept http communication between client and the server and use this traffic to exploit the target system.

Identify Known 3^rd Party Software Vendors

Sometimes applications use 3^rd party tools for certain functionalities. This exposes the whole application to the same risk the 3^rd party tool has.

We look for publicly available vulnerabilities and exploits in software vendors the application uses and test them out.

There are thousands of possible attacks in the wild that exploit applications, servers and databases altogether.

Other common attacks that need mentioning are: session fixation attacks, session hijacking attacks, and binary attacks.

Step 3: Exploitation 

Here, we transform identified vulnerabilities into real-world attack scenarios to assess their potential impact. By simulating malicious activities, we determine the extent of damage a successful attack could inflict on your system.

This phase involves a meticulous examination of various attack vectors, including but not limited to various test cases.  

What Attack Cases are Tested During Web Application Penetration Testing?

1. Authentication Testing 

1. Bypass of authentication.
   1. SQL Injection
   2. XPATH Injection
   3. LDAP Injection
2. Testing for OAuth Configuration.
   1. Reviewing state parameters or other CSRF protection mechanisms.
   2. Reviewing callback or redirect_url parameter for arbitrary domains, subdomains or directories.
   3. Reviewing referrer leaks.
3. Testing for Rate Limiting by Brute-forcing.
4. Testing the robustness of 2FA/OTP functionality.
   1. Rate limiting
   2. Length
   3. Predictability
5. Bypass of CAPTCHA.
6. Session Fixation.
7. Test account suspension/resumption process.
8. User Enumeration.
9. Username / Password Policy.

2. Testing for Password Reset Functionality 

1. Leakage of password reset link
2. Insecure direct object reference
3. Insecure session management
4. Weakness in life cycle of password reset link
   1. Lifetime of reset link
   2. Re-use of same link
   3. Predictability of token in the reset link
   4. Weak encryption of token
   5. Usage of attacker’s token on victim’s account

3. API Communication 

1. Authorization Header Analysis
   1. Basic
   2. Bearer
   3. None
   4. Custom
2. API keys expiration
3. Unauthenticated/Anonymous Access
4. Use of same authorization token for every user
5. Analysing the predictability of token

4. Testing for Cookie Attacks 

1. Leakage of cookie with sensitive data (validating user session based on userid/username cookie value)
2. Weakness in cookie lifecycle
3. XSS via cookie.
4. Remote cookie tampering
5. Missing HttpOnly Flag
6. Missing Secure Flag
7. CRLF Injection (Carriage Return Line Feed)

5. Sensitive Data Exposure 

1. Insecure error handling
2. Disclosure of sensitive files (example: phpmyadmin or web.config etc)
3. Information disclosure via metadata
4. Insecure communication channel (force browsing)
5. Hidden/sensitive directories & files in robots.txt
6. Return of sensitive information in later responses (example: password, otp, other user’s private/sensitive information)

6. Testing for Cache 

1. Google Caching
2. Cacheable HTTPS responses
3. Sensitive data in URLs
4. Web Cache Deception

7. Headers & Policies Scrutiny 

1. CRLF Injection (Carriage Return Line Feed)
2. Host Header Injection
3. Weak username or unenforced policy
4. Weak password policy
5. Cross Origin Resource Sharing
6. Clickjacking
7. URL Redirection (if response header contains “location:” header)

8. Session Management 

1. Testing insecure logout implementation
2. Cross-Site Request Forgery
   1. Null Token
   2. Tampered Token
   3. Lack of Token
   4. Reuse of attacker’s token
   5. Double CSRF token
   6. CSRF token predictability
   7. Application/JSON bypass using cross-domain.xml
3. Analysing authorization/privileges implementation through cookies

9. Authorization Testing 

1. Testing for horizontal and vertical privilege escalation
2. Testing for Insecure Direct Object Reference
3. Directory Traversal

10. Data Validation 

1. Malicious file upload
   1. File extension
   2. Content-type
   3. File signature manipulation
   4. File size
2. Cross-site Scripting
   1. Reflected
   2. Stored
   3. DOM
   4. Blind XSS (in case of backend management system/CMS or an admin panel)
3. CSV Injection.
4. HTTP Verb Tampering

11. Injections 

1. Remote Code Execution
2. SQL Injection
   1. Boolean-based blind
   2. Error-based
   3. Union query-based
   4. Stacked queries
   5. Time-based blind
   6. Inline queries
3. NoSQL Injection
4. XML Injection 
5. XXE
6. CSV Injection
7. Template Injection
8. ELI (Expression Language Injection)
9. ORM Injection
10. LDAP Injection

12. Testing for Server-Side Issues 

1. Testing for SSRF
2. Server-Side Template Injection

13. Business Logic Issues 

1. Payment Tampering
2. Custom Business Logic bypasses
3. Submit forms without filling in mandatory fields

14. Cloud Misconfigurations 

1. AWS S3 Bucket Permissions
2. Successful generation of signature for other bucket assets

15. Testing for Security Misconfigurations 

1. Outdated Framework/CRM/WordPress
2. Enabled Directory Listing
3. Uploading files to any directory
4. Default accounts with default passwords

16. Testing for DNS Misconfigurations 

1. Looking up for CNAMEs and expired services
2. Looking up for SPF records & configurations
3. Looking up if A record is 127.0.0.1 (same site scripting)

17. Miscellaneous 

1. Reflected File Download.
2. Accessing Default Files (example: phpmyadmin)
3. Verifying window.postmessage value (if it’s set to wildcard *)

Step 4: Reporting And Recommendations

Once the assessment phase is finished, a high-quality report on the findings is drafted to discuss the best mitigations for fixing the vulnerabilities. Our standards ensure the best of security testing practices and provide a brief snapshot on the organization’s security risk levels. 

We make sure that the report is written for the business-oriented people so that both client IT staff and higher management understands the report clearly and to what degree they are exposed to the risk.

To understand in detail what is included in a good pentest report, you can check out this blog – Read here 

Step 5: Remediation And Ongoing Support

Many companies find themselves not able to remediate all the vulnerabilities a penetration test revealed. It is best practice to mitigate critical and high vulnerabilities first and focus on the medium and low afterwards.

Prioritization plays a big role as the likelihood of each vulnerability being exploited varies.

Some vulnerabilities detected are possible but not without previous access to the internal system, and some vulnerabilities carry the risk of remote code execution and should be adequately prioritized to reflect the likelihood and impact.

Strobes offers a re-test as part of contract and will provide you with a secondary penetration test to verify the mitigated vulnerabilities found in the previous test.

This is where our security analysts work closely with your Security and IT teams to resolve all vulnerabilities that were found after the first testing was done.

Strobes Web Application Pentesting

At Strobes, we go beyond traditional pentesting to deliver a robust and adaptable approach:

• Expert-Driven Testing: Our team of seasoned security professionals possesses the knowledge and experience with certifications like CISA, CEH, OSCP, CREST, CISSP  to identify even the most obscure vulnerabilities.
• Continuous Security: We offer a range of testing options, from one-time assessments to ongoing security monitoring, to fit your specific needs.
• Tailored Approach: We customize our testing methodologies to align with your application’s unique architecture and industry regulations.
• Actionable Insights: Our detailed reports not only outline vulnerabilities but also provide clear remediation guidance for effective mitigation.
• Streamlined Communication: Strobes PTaaS platform has 2-way sync with Slack, Teams, wherein you can directly communicate with your team. 

Strobes offers a variety of solutions to cater to your specific requirements:

1. Grey box testing
2. Black box testing
3. White box testing

Conclusion

In conclusion, Web Application Penetration Testing is more than just a routine check. It’s a vital component of your security strategy that helps you stay ahead of potential threats. By identifying vulnerabilities before attackers can exploit them, you’re not just protecting your applications but also reinforcing your organization’s overall security posture. Embrace this proactive approach to ensure that your web applications remain resilient and trustworthy.

Ready to Get Started?

Contact Strobes today to schedule a free consultation and discuss how our app pentesting solutions can help you achieve a robust and secure web application environment.