Zero Web App Security: A Web Application Penetration Testing Writeup (OWASP Top 10-2025)

1. INTRODUCTION

The Zero Web App Security application is a deliberately vulnerable web application developed by Micro Focus Fortify to demonstrate the capabilities of its web application security testing products. The application simulates an online banking environment and contains various security vulnerabilities and misconfigurations designed for educational and training purposes. It is not a real banking application, and any resemblance to actual financial institutions or third-party services is purely coincidental.

In this writeup, I document my approach to assessing the application using a combination of manual and automated web application security testing techniques. The objective of this assessment was to identify potential vulnerabilities, validate findings, and gain practical experience with common web application security testing methodologies and tools. This exercise was conducted in a controlled and authorized environment for educational and portfolio purposes.

Disclaimer:_ This writeup documents security testing performed against a deliberately vulnerable training application in a controlled environment for educational and portfolio purposes only. No real-world systems, applications, organizations, or financial institutions were targeted. The information presented in this article is intended solely to demonstrate cybersecurity concepts, methodologies, and testing techniques. The author does not endorse or encourage unauthorized access, testing, or exploitation of any systems. Any actions taken by readers based on the information provided are solely their own responsibility._

Target: http://zero.webappsecurity.com/

2. Tools Used

The assessment was conducted using the following tools:

• OWASP ZAP
• Gobuster
• Burp Suite Community Edition
• Browser Developer Tools (Inspect)

OS: Windows and Kali Linux Virtual Machine

3. Initial Reconnaissance

I began by manually exploring the application to understand its functionality and identify potential attack surfaces. During this phase, I examined the available pages, forms, and user functionalities to understand the application.

4. Content Discovery

After manually exploring the application, I performed directory enumeration to identify hidden endpoints and resources that were not accessible through normal navigation.

I used Gobuster with a common wordlist:

gobuster dir -u http://<target> -w /usr/share/wordlists/dirb/common.txt

gobuster dir -u http://<target> -w /usr/share/wordlists/dirb/common.txt

The scan identified several directories and files of interest.

5. Automated Scanning with OWASP ZAP

After completing reconnaissance and enumeration, I used OWASP ZAP to perform an automated scan of the application. The scan identified several potential vulnerabilities and security misconfigurations that required further investigation.

6. Manual Validation

After completing the automated scan using OWASP ZAP, I proceeded with manual validation to verify the identified alerts and eliminate potential false positives.

Browser Developer Tools were utilized to inspect the HTTP response headers returned by the application. Through the Network tab, the response headers were manually reviewed to verify the implementation of recommended security controls.

The inspection confirmed the absence of several security headers, including:

• Content-Security-Policy (CSP)
• X-Frame-Options
• X-Content-Type-Options

The absence of these headers validated the security misconfiguration alerts previously identified by OWASP ZAP.

The browser's Developer Tools were also used to inspect the cookies set by the application. Examination of the cookie attributes confirmed the absence of the SameSite attribute, which may increase the application's exposure to cross-site request forgery attacks.

Burp Suite's Site Map functionality was used to identify JavaScript resources loaded by the application. The identified library versions were reviewed to determine whether they contained publicly known vulnerabilities.

7. Findings

Finding 1: Missing HTTP Security Headers

OWASP Top 10 Category: A02 — Security Misconfiguration

During manual validation, several recommended HTTP security headers were found to be absent from the application's HTTP responses. These included:

• Content-Security-Policy (CSP)
• X-Frame-Options
• X-Content-Type-Options

Evidence

The absence of these headers was confirmed through inspection of the HTTP response headers using Browser Developer Tools.

Finding 2: Clickjacking Vulnerability

OWASP Top 10 Category: A02 — Security Misconfiguration

During the manual validation phase, the absence of clickjacking protection mechanisms (X-Frame-Options header) identified by OWASP ZAP was further investigated.

Evidence

To verify the impact of this misconfiguration, a clickjacking proof-of-concept (PoC) page containing an HTML iframe was created. The target application successfully rendered within the iframe, confirming that the application was vulnerable to clickjacking attacks.

The following simple HTML code was used to construct the clickjacking PoC:

<!DOCTYPE html>
<html>
<head>
  <title>Clickjacking Test</title>
</head>
<body>

<h2>Click this button</h2>
<button style="font-size:20px;">Fake Button</button>

<!-- Target website -->
<iframe src="https://target.com"
        style="
        position:absolute;
        top:0;
        left:0;
        width:100%;
        height:100%;
        opacity:0.1;
        z-index:999;">
</iframe>

</body>
</html>

<!DOCTYPE html>
<html>
<head>
  <title>Clickjacking Test</title>
</head>
<body>

<h2>Click this button</h2>
<button style="font-size:20px;">Fake Button</button>

<!-- Target website -->
<iframe src="https://target.com"
        style="
        position:absolute;
        top:0;
        left:0;
        width:100%;
        height:100%;
        opacity:0.1;
        z-index:999;">
</iframe>

</body>
</html>

The application successfully rendered within the iframe without any restrictions, demonstrating the absence of clickjacking protections.

Finding 3: Admin Panel Accessible Without Authentication

OWASP Top 10 Category: A01 — Broken Access Control

During manual testing and exploration of the application's functionality, an admin interface was identified that could be accessed directly without requiring authentication or authorization checks.

By navigating to the admin panel endpoint, unrestricted access to administrative functionality was successfully obtained. This indicates a lack of access control enforcement on sensitive administrative resources, allowing unauthorized users to access functionality intended for privileged users.

Evidence

The following screenshot demonstrates successful access to the admin panel without prior authentication or authorization.

Finding 4: Exposure of Default Credentials

OWASP Top 10 Category: A02 — Security Misconfiguration

During the reconnaissance phase, the application's authentication interface was manually inspected to identify potential authentication weaknesses. I observed that valid username and password credentials were disclosed directly through the application's user interface when hovering over the login page.

Evidence

The following screenshot demonstrates the disclosure of the default credentials through the application's login interface.

The disclosed credentials were successfully used to authenticate to the application.

Finding 5: Stored Cross-Site Scripting (XSS)

OWASP Top 10 Category: A05 — Injection

While exploring the admin panel, I noticed that administrators could add new currencies through the Currencies section. To test whether the application properly sanitized user input, I created a new currency entry and intercepted the request using Burp Suite.

I then modified the currency parameter to include a simple JavaScript payload:

<script>alert('XSS')</script>

<script>alert('XSS')</script>

After forwarding the request, the payload was successfully executed in the browser. Additionally, the payload remained stored within the application confirming the presence of a Stored Cross-Site Scripting (XSS) vulnerability.

Evidence

The following screenshot shows the modified request intercepted in Burp Suite.

Finding 6: Vulnerable JavaScript Library

OWASP Top 10 Category: A03 — Software Supply Chain Failures

While reviewing the application's resources through Browser Developer Tools, I identified that the application was using jquery-1.8.2.min.js.

Since this version was released in 2012, additional research was conducted to determine whether the library contained publicly disclosed vulnerabilities. The investigation confirmed that the identified version is outdated and affected by multiple known security issues.

Evidence

Finding 7: Information Disclosure

OWASP Top 10 Category: A02 — Security Misconfiguration

Evidence

During the reconnaissance phase, I used Browser Developer Tools to inspect the application's HTTP responses and identify technologies used by the application. Inspection of the response headers revealed that the application was utilizing Apache-Coyote/1.1.

To further enumerate the application's attack surface, I performed content discovery using Gobuster. While testing several discovered endpoints that resulted in redirects or access restrictions, I observed that the server-generated responses disclosed additional information regarding the underlying web server, including the Apache Tomcat version (7.0.70).

Finding 8: Cross-Site Request Forgery (CSRF) in Bill Payment Functionality

OWASP Top 10 Category: A01 —Broken Access Control

Evidence

While testing the application's bill payment functionality, I inspected the HTTP requests using Burp Suite to determine whether anti-CSRF protections were implemented. The analysis revealed that the application did not utilize anti-CSRF tokens or other request validation mechanisms.

To verify the impact of this observation, I created a proof-of-concept HTML page containing a malicious form that replicated the legitimate bill payment request. When the HTML file was opened in a browser while authenticated to the application, the payment request was automatically submitted and successfully processed.

Finding 9: Insecure Direct Object Reference (IDOR) in Account Activity

OWASP Top 10 Category: A01— Broken Access Control

Evidence

While testing the account activity functionality, I observed that account information was referenced using the accountId parameter in the URL.

I manually modified the accountId parameter to reference different account identifiers. The web returned transactions from another account.

Finding 10: Business Logic Flaws in Funds Transfer Functionality

OWASP Top 10 Category: A06 — Insecure Design

While testing the funds transfer functionality, I evaluated whether the application properly enforced business rules related to financial transactions. By intercepting requests using Burp Suite and modifying transaction parameters, I identified multiple business logic weaknesses.

Evidence

After intercepting a legitimate transfer request, I modified the transfer amount to a negative value before forwarding it to the server. The application accepted and processed the request, indicating that the application failed to validate transaction amounts appropriately.

Further testing revealed that the application allowed transfers where the source and destination accounts were identical. By selecting the same account as both the sender and recipient, the transaction was processed successfully without any validation checks.

Finding 11: Weak SSL/TLS Configuration and Deprecated Cryptographic Protocols

OWASP Top 10 Category: A04 — Cryptographic Failures

During the assessment, the SSL/TLS configuration of the application was evaluated using SSL scanning tools. The analysis revealed that the server supports multiple deprecated and insecure cryptographic protocols and cipher suites.

Evidence

The server was found to support SSLv2, SSLv3, and TLS 1.0, as well as several weak cipher suites.

Finding 12: Plaintext Storage of Credentials n Client-Side Cookies

OWASP Top 10 Category: A04 — Cryptographic Failures

While analyzing the application's authentication and session management mechanisms using Burp Suite and Browser Developer Tools, I observed that the application stored user credentials directly within client-side cookies.

After authenticating using the disclosed default credentials, subsequent HTTP requests contained the username and password in plaintext format alongside the session identifier (JSESSIONID).

Evidence

During authenticated testing, the HTTP request headers were inspected using Burp Suite. The intercepted requests revealed that the application stored authentication credentials directly within cookies.

8. Lessons Learnt

Throughout this assessment, I gained practical experience in:

• Performing reconnaissance and content discovery using Gobuster.
• Validating automated scanner findings through manual testing.
• Identifying and exploiting access control vulnerabilities such as IDOR and unrestricted administrative access.
• Developing PoC exploits for vulnerabilities such as XSS, Clickjacking, and CSRF.
• Investigating third-party components and researching publicly disclosed vulnerabilities.
• Assessing authentication, session management, and cryptographic configurations.

9. Conclusion

This assessment demonstrated that effective web application penetration testing goes beyond running automated scanners. While tools such as OWASP ZAP and Gobuster helped identify potential attack surfaces, many of the most impactful findings including IDOR, CSRF, business logic flaws, and stored XSS required manual analysis and validation. Overall, this exercise strengthened my understanding of web application testing the importance of combining technical knowledge with critical thinking during security assessments.