Cyber Security DVWA Lab Report

Penetration Testing

This report documents a controlled security assessment performed on the Damn Vulnerable Web Application (DVWA). Objectives: identify common web vulnerabilities, demonstrate exploitation paths in a lab environment, and propose effective remediations. Tools & techniques included Burp Suite, OWASP ZAP, Kali Linux utilities, and manual testing.

Full Project 2

1. SQL Injection (SQLi)

Result

Input fields were vulnerable to SQL injection. Payloads such as ' OR '1'='1 -- bypassed authentication and allowed enumeration of database records and metadata. Error-based responses revealed table/column structure on low/medium security levels.

Solution

  • Use parameterized queries / prepared statements (e.g., PDO, parameterized drivers).
  • Server-side input validation and strict type casting; reject unexpected characters.
  • Implement least-privilege DB accounts; disable verbose SQL error messages in production.
Full Project 2

2. Cross-Site Scripting (XSS)

Result

Reflected and stored XSS identified. Injected scripts (e.g., <script>alert(1)</script>) executed in the victim’s browser, exposing risk of session hijacking and client-side data theft.

Solution

  • Context-aware output encoding (HTML, attribute, JS, URL contexts).
  • Input sanitization and server-side validation; prefer safe templating frameworks.
  • Deploy Content Security Policy (CSP) and HttpOnly/SameSite cookies where applicable.
Full Project 2

3. Command Injection

Result

Parameters were concatenated into shell commands (e.g., ping). Separators like ;&&| allowed arbitrary command execution, demonstrating potential server compromise.

Solution

  • Avoid shell execution; use safe language/system APIs.
  • Strict allowlists for input; reject metacharacters and multi-command operators.
  • Run services with least privileges; enable command execution sandboxing/AppArmor/SELinux.
Full Project 2

4. File Inclusion (LFI / RFI)

Result

Path parameters were injectable, enabling local file retrieval (e.g., /etc/passwd) and, where enabled, remote inclusion of hostile scripts.

Solution

  • Use a strict whitelist of server-side include targets; map IDs to files rather than accepting paths.
  • Disable remote file inclusion and URL wrappers; normalize and validate paths.
  • Keep sensitive files outside the web root; enforce least-privilege filesystem permissions.
Full Project 2

5. Cross-Site Request Forgery (CSRF)

Result

State-changing endpoints lacked CSRF defenses. A crafted third-party page could force authenticated users to perform unintended actions.

Solution

  • Embed and verify unpredictable CSRF tokens per request (synchronized tokens or double-submit cookies).
  • Enable SameSite cookies and enforce re-authentication for critical actions.
  • Validate Origin/Referer headers where feasible.
Full Project 2

6. Brute Force / Weak Passwords

Result

Login endpoints accepted unlimited attempts without rate limiting, and weak credentials were accepted, enabling automated credential guessing.

Solution

  • Enforce rate limiting, exponential backoff, and temporary account lockouts.
  • Adopt strong password policies and breach-password checks; support MFA/2FA.
  • Monitor authentication telemetry; alert on suspicious activity patterns.
Full Project 2

7. File Upload Vulnerability

Result

The upload feature accepted executable payloads (e.g., .php) with permissive MIME/extension checks, enabling remote code execution when accessed.

Solution

  • Whitelist safe types; validate both filename and MIME using server-side checks and content sniffing.
  • Store uploads outside web root; serve via indirection (e.g., ID lookups, not direct paths).
  • Rename files, strip metadata, restrict permissions, and optionally scan with antivirus.