Black‑Box Web Vulnerability Testing (Nikto, SQL Injection, XSS)

Source: Dev.to

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 end‑to‑end workflow using three foundational categories:

The goal is understanding and documentation, not weaponisation.

Lab Environment & Scope

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:

1. Identify reachable networks and hosts.
2. Enumerate open services and versions.
3. Scan for misconfigurations.
4. Test application behaviour.

Document what changed and why it matters. Negative results are recorded with the same rigor as successful findings.

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 (e.g., nmap -sn 10.0.0.0/24).
• Identified multiple intentionally vulnerable services by hostname.

Beginner note: Host discovery prevents wasted effort. Testing the wrong IP is a common early mistake.

Phase 2: Service Enumeration

Goal: Identify what each host is running and where to focus.

• Enumerated open ports on discovered hosts (e.g., nmap -sV -p-).
• 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

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 behavioural 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 (e.g., DVWA’s “SQL Injection” page) designed to demonstrate unsafe input handling.

Observed Behaviour

• 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 SQLi 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

Mitigations & Secure Design Takeaways

1. Patch & Update – Keep web servers, frameworks, and libraries up to date.
2. Security Headers – Deploy X‑Frame‑Options, X‑Content‑Type‑Options, Content‑Security‑Policy, and Strict‑Transport‑Security.
3. Cookie Hardening – Set HttpOnly and Secure flags on session cookies.
4. Input Validation & Output Encoding –
   • Validate input against a whitelist of allowed characters.
   • Encode output based on context (HTML, JavaScript, URL, etc.).
5. Parameterized Queries / Prepared Statements – Eliminate concatenated SQL strings.
6. Strong Password Storage – Use salted, adaptive hashing algorithms (e.g., bcrypt, Argon2).
7. Least Privilege – Restrict database accounts to only the permissions required.

Common Beginner Pitfalls

Conclusion

This lab walks through a disciplined, black‑box approach to discovering and documenting web‑application weaknesses in a safe, authorized environment. By starting with network discovery, moving through service enumeration, and then applying focused tools (Nikto, manual SQLi tests, XSS checks), we illustrate how systematic methodology yields reliable results while keeping the scope ethical and educational.

The findings underscore that misconfigurations, weak hashing, and lack of proper output encoding are often as dangerous as classic code‑level bugs. Remediation should therefore address both secure configuration and secure coding practices to build resilient web applications.

# QL 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](https://linkedin.com/in/ldwit)