Troubleshooting OWASP Broken Web Apps Environment

Project: Web Application Penetration Testing Lab Setup

Junior Penetration Tester (Learning Journey) Environment: Kali Linux + OWASP Broken Web Apps VM Hypervisor: VirtualBox | Virtual Machine Workstation Objective: Build a vulnerable web application testing environment for practicing web penetration testing.

Lab Overview

As part of my continuous cybersecurity learning journey, I built a dedicated web application penetration testing lab from OWASP to gain practical experience in identifying, analyzing, and understanding common web vulnerabilities. The objective is to complement theoretical knowledge with hands-on practice while developing structured troubleshooting and security assessment skills.

Objective

The goal was to access the OWASP Broken Web Apps dashboard from Kali Linux which servers as the attacking machine.

The expected result was opening the OWASP application launcher with an ip address of http://10.0.2.15/ containing vulnerable applications such as:

Damn Vulnerable Web Application (DVWA)
bWAPP
Mutillidae
WebGoat
OWASP Bricks
Vicnum
Peruggia
Hackxor
WordPress
Joomla
Other vulnerable applications

Lab Environment Overview

Attacker Machine -> Operating System: -> Kali Linux

Purpose:

Running penetration testing tools
Performing reconnaissance
Interacting with vulnerable applications

Beginner friendly tools to be used for testing:

Nmap
Burp Suite
Nikto
Gobuster
OWASP ZAP
Browser developer tools

Issue Encountered

When accessing http://10.0.2.15/ , the browser displayed the Apache default page instead of the OWASP Broken Web Apps dashboard. That got me overwhelmed and pause to ask myself a question what did I do wrong?? what step did I missed during the configuration set up or Apache may be pointing to the wrong directory ..

Initial Assumption

My first assumption was Apache was incorrectly configured or the OWASP VM installation was incomplete.

This was a reasonable assumption because:

The web server was responding.
The IP address worked.
The wrong page was displayed.

However, assumptions must be tested before changing configurations.

Troubleshooting Methodology

A professional troubleshooting process checks from the lowest layer upward.

Test 1

Is the machine running? Verify Apache Service

First, I checked whether Apache was running.

Command: service apache2 status

Observation: Apache was active, so the problem was not that the web server was stopped.

Test 2

Is the network working? Verified Network Connectivity

Checked the OWASP vm IP: 10.0.2.15

From Kali: ping 10.0.2.15

Result: 64 bytes from 10.0.2.15 | 0% packet loss

Test 3

Checked Apache Configuration

Viewed the default Apache virtual host; Is the service running?

cat /etc/apache2/sites-enabled/000-default

Test 4

Is the application configured correctly?

Investigated the Web Directory

Checked: ls -la /var/www

Found the OWASP applications:

dvwa ;bWAPP ;mutillidae ;webgoat.net ;owaspbricks ;wordpress

Test 5

Found the OWASP Dashboard

Is the client/browser causing the issue? Opened: http://10.0.2.15/vuln_list.html

However, the desired behavior was http://10.0.2.15/ opening the dashboard automatically.

Result: The OWASP application list opened successfully.

Conclusion: Apache is serving OWASP content correctly. The problem was not the server.

Test 6

Verified the Main Index File

Checked: cat /var/www/index.html | head -30

This revealed that the OWASP dashboard was already configured.

Root Cause

The issue was caused by the browser displaying an older cached version of the page.

The Apache server was correctly serving the OWASP dashboard, but the browser had stored the previous Apache default page locally.

Understanding Browser Cache

Browser cache is temporary storage used to save website files locally.

Browsers cache:

HTML pages
CSS files
JavaScript files
Images
Website resources

The purpose is to make websites load faster.

Example: First visit: Browser → Server → Download page → Save copy locally

Later visit: Browser → Use saved copy

The problem occurs when:

Server has changed
        |
        v
Browser still displays old saved copy

Server has changed
        |
        v
Browser still displays old saved copy

Solution

Perform a hard refresh on the cache memory :CTRL + SHIFT + R

This forces the browser to request a fresh copy from the server. After refreshing: http://10.0.2.15/

Important Lessons Learned

1. Do not immediately change configurations

Before modifying Apache settings, verify whether the application is already working.

2. Troubleshoot in layers

A good troubleshooting sequence:

1. Is the service running?
        |
        v
2. Is the network reachable?
        |
        v
3. Is the server configured correctly?
        |
        v
4. Is the client/browser showing old data?

1. Is the service running?
        |
        v
2. Is the network reachable?
        |
        v
3. Is the server configured correctly?
        |
        v
4. Is the client/browser showing old data?

3. Use command-line verification

Browsers can hide problems because of caching.

Useful commands:

Check HTTP response: curl http://10.0.2.15/

Check services: service apache2 status

Check files: ls -la /var/www

Final Lab Status

The OWASP Broken Web Apps environment was successfully configured.

Dashboard finally work with the default ip http://10.0.2.15/

Available training applications:

DVWA
bWAPP
Mutillidae
WebGoat
OWASP Bricks
Vicnum
Peruggia
Hackxor
Joomla
WordPress
Many more

The lab is now ready for web application penetration testing practice. Thank you for reading #CISO Goal here I come

Contents