Scope & Ethics
This article documents testing performed only inside an intentionally vulnerable Kali Linux class lab. All activities were authorized and executed in a controlled environment for educational purposes.GitHub Repo with Additional Details:
Black-Box Web Vulnerability Testing
Table of Contents
- Why This Lab Matters
- Lab Environment & Scope
- Methodology (Black‑Box Approach)
- Phase 1: Network & Host Discovery
- Phase 2: Service Enumeration
- Phase 3: Vulnerability Scanning with Nikto
- Phase 4: SQL Injection Testing
- Phase 5: Cross‑Site Scripting (XSS)
- Findings Summary
- Mitigations & Secure Design Takeaways
- Common Beginner Pitfalls
- Conclusion
Why This Lab Matters
Web vulnerabilities are rarely found by jumping straight to exploitation. In practice, testers start with discovery, validate assumptions, and document both positive and negative results. This lab demonstrates that workflow end‑to‑end using three foundational categories:
- Nikto – server misconfiguration and hygiene
- SQL Injection (SQLi) – backend trust and input handling failures
- Cross‑Site Scripting (XSS) – client‑side trust and output encoding failures
The goal is understanding and documentation, not weaponization.
Lab Environment & Scope
Operating System: Kali Linux (class OVA)
Authorization: Testing limited to intentionally vulnerable services inside the lab network.
Discovered Targets (internal network):
- DVWA (Damn Vulnerable Web Application)
- WebGoat
- Additional intentionally vulnerable apps
Beginner note: In real assessments you often don’t know what’s vulnerable. The first win is simply discovering what exists.
Methodology (Black‑Box Approach)
A black‑box test assumes no prior knowledge of the application internals. The workflow used:
- Identify reachable networks and hosts
- Enumerate open services and versions
- Scan for misconfigurations
- Test application behavior
- Document what changed and why it matters
Negative results are documented as carefully as successful ones.
Phase 1: Network & Host Discovery
Goal: Identify live hosts on the internal lab network.
- Determined local IP and routes
- Performed host discovery on the internal bridge network
- Identified multiple intentionally vulnerable services by hostname
Beginner note: Host discovery prevents wasted effort. Testing the wrong IP is common early on.
Phase 2: Service Enumeration
Goal: Identify what each host is running and where to focus.
- Enumerated open ports on discovered hosts
- Identified HTTP services and supporting components (web servers, databases)
- Confirmed which apps were best suited for each vulnerability type
Key takeaway: Enumeration tells you where to test, not how to exploit.
Phase 3: Vulnerability Scanning with Nikto
Target: DVWA web service
Tool: Nikto
What Nikto checks:
- Outdated server software
- Missing security headers
- Exposed directories and default files
Key Findings
- Outdated Apache version
- Missing security headers (X‑Frame‑Options, X‑Content‑Type‑Options)
- Session cookies missing
HttpOnly - Directory indexing enabled
- Authentication endpoint identified
Why this matters: These findings don’t “hack” anything—but they dramatically increase risk and often point directly to deeper vulnerabilities.
Phase 4: SQL Injection Testing
Initial Test (Negative Result)
The login page returned a generic “Login failed” message regardless of input.
- No visible SQL errors
- No behavioral deviation
Why document this? Consistent error handling is a defensive control. Not every endpoint is vulnerable.
Pivot to a Better Target
Using enumeration results, SQL Injection testing moved to a dedicated SQLi module designed to demonstrate unsafe input handling.
Observed Behavior
- User‑supplied input directly influenced backend queries
- Multiple records returned where one was expected
- Unauthorized access to user data and database metadata
Impact Demonstrated
- Exposure of user records
- Disclosure of database schema and version
- Retrieval of password hashes
Beginner note: The vulnerability isn’t “seeing data”—it’s that untrusted input controls database logic.
Supplemental Risk Evidence
A representative unsalted MD5 hash was verified as trivially reversible using a public lookup service, demonstrating how weak hashing compounds SQL Injection risk.
Phase 5: Cross‑Site Scripting (XSS)
Reflected XSS (DVWA)
Baseline test:
- Plain text input reflected directly into the response
- No HTML output encoding observed
Conclusion:
User input is reflected verbatim, confirming a Reflected XSS condition at low security settings.
Beginner note: A popup is not required to prove XSS. Unsafe reflection alone is enough.
Stored XSS (DVWA)
Baseline storage test:
- User comments persisted in the backend
- Content rendered for all users
- Entries remained after page refresh
Why this is critical:
Stored XSS affects every user who views the page, not just the attacker.
Root Cause (from Source Review)
Input was escaped for SQL usage but not encoded for HTML output.
Key lesson: SQL escaping ≠ XSS protection. Output must be encoded for the browser context.
Findings Summary
| Category | Result |
|---|---|
| Nikto | Multiple misconfigurations identified |
| SQL Injection | Backend query manipulation confirmed |
| Reflected XSS | Unsafe reflection detected |
| Stored XSS | Persistent unsafe rendering confirmed |
Mitigations & Secure Design Takeaways
- Use parameterized queries (PDO / MySQLi)
- Apply context‑aware output encoding (
htmlspecialchars) - Set security headers (
HttpOnly,X‑Frame‑Options, CSP) - Avoid weak or unsalted password hashes
- Validate input and encode output
Defense‑in‑depth matters: No single control is sufficient.
Common Beginner Pitfalls
- Expecting every input to be vulnerable
- Skipping enumeration and guessing targets
- Confusing SQL escaping with XSS prevention
- Failing to document negative results
Learning to say “this did not change behavior” is a skill.
Conclusion
This lab demonstrated how a structured black‑box approach uncovers vulnerabilities systematically, not magically. By combining discovery, scanning, behavioral testing, and documentation, it’s possible to explain not just what is vulnerable, but why it matters.
The most important takeaway:
Security testing is about understanding trust boundaries, not memorizing payloads.
Connect
If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.
💬 Feel free to reach out or follow my journey on 👉 LinkedIn
Top comments (0)