SQL Injection Practice – OWASP Juice Shop

📌 Overview

This repository documents a hands-on SQL Injection (SQLi) lab performed in a controlled, ethical testing environment using OWASP Juice Shop.
The goal of this exercise was to understand how improper input handling can lead to authentication bypass vulnerabilities, aligned with the OWASP Top 10 – Injection category.

This lab was completed as part of my penetration testing practice and portfolio development.

---

🧪 Lab Environment

• Host OS: Kali Linux (VMware)
• Target Application: OWASP Juice Shop (Docker)
• Tools Used:
  • Docker
  • Web browser (Firefox)
  • Burp Suite (for traffic observation)
• Access: Localhost only (no external targets)

---

⚙️ Environment Setup

Docker Installation & Configuration

Docker was installed and configured to allow non-root usage by adding the current user to the Docker group.

Key verification steps included:

• Confirming Docker service status
• Verifying group membership
• Ensuring the Juice Shop container was running and bound to port 3000

Once running, the application was accessed at:

http://localhost:3000

🔎 Request & Response Analysis

Using Burp Suite, authentication requests to the backend API were intercepted and analyzed.

• Endpoint: /rest/user/login
• Method: POST
• Content-Type: application/json

The server processed user-controlled input directly during authentication.
By influencing the authentication logic through crafted input, the application incorrectly validated the session and issued an authentication token associated with an administrative account.

A successful response returned:

• HTTP 200 OK
• A valid authentication token
• Administrative user context

This confirms that authentication decisions were made based on insecure query handling.

---

🎯 Selected Challenge

Category: Injection
Challenge Name: Login Admin
Objective:

Log in with the administrator’s user account.

This challenge simulates a real-world scenario where authentication logic relies on insecure database query construction.

---

🔍 Testing Methodology

1. Navigated to the Login functionality within the application
2. Reviewed the challenge description from the Juice Shop scoreboard
3. Observed how user input was processed during authentication
4. Identified insufficient input validation within the login mechanism
5. Manipulated authentication logic to bypass credential checks
6. Successfully logged in as an administrative user without valid credentials

⚠️ No real systems were targeted.
All testing was performed locally on intentionally vulnerable software.

---

✅ Result

• Successfully authenticated as the administrator
• Challenge status marked as Solved by OWASP Juice Shop
• Administrative-level access granted within the application

This confirmed the presence of an SQL Injection vulnerability enabling authentication bypass.

---

⚠️ Impact Assessment

If present in a real-world application, this vulnerability could allow attackers to:

• Bypass authentication controls
• Gain administrative access
• Access or modify sensitive data
• Fully compromise the application

---

🛡️ Mitigation Recommendations

To prevent this type of vulnerability:

• Use parameterized queries / prepared statements
• Avoid dynamic SQL query construction
• Implement strict server-side input validation
• Apply the principle of least privilege to database accounts
• Perform regular security testing and code reviews

---

📚 References

• OWASP Top 10 – Injection
• OWASP Juice Shop Project

---

🧠 Skills Demonstrated

• Understanding of SQL Injection vulnerabilities
• Secure lab setup using Docker
• Ethical web application testing
• Vulnerability analysis and impact assessment
• Clear documentation and remediation awareness

---

⚖️ Disclaimer

This project was conducted strictly for educational purposes in a controlled lab environment.
No unauthorized systems were tested.

🧩 OWASP Top 10 Mapping

• Category: A03: Injection
• Vulnerability Type: SQL Injection (Authentication Bypass)

📘 Lessons Learned

• Authentication mechanisms must never rely on dynamically constructed SQL queries
• Input validation alone is insufficient without parameterized queries
• Security testing should include API-level inspection, not only UI interaction