From Unauthorized Page to Critical SQL Injection: A Bug Hunter’s Deep Dive + Video

Introduction:

In the world of bug bounty hunting, the path from a seemingly harmless unauthorized page to a critical SQL injection is fraught with creativity and technical precision. This article dissects a real-world escalation where an overlooked access control flaw became the gateway to a full database compromise, illustrating how improper input validation and broken access controls can combine to create a high-risk vulnerability. Understanding this chain of exploitation is essential for both hunters and defenders aiming to secure modern web applications.

Learning Objectives:

• Understand how unauthorized access can lead to SQL injection discovery.
• Learn manual and automated techniques to identify and exploit SQL injection flaws.
• Grasp mitigation strategies to prevent such escalations in production environments.

You Should Know:

1. Understanding Unauthorized Access and SQL Injection

Unauthorized access occurs when a user gains access to a page or resource without proper privileges—often due to misconfigured role-based access control (RBAC) or insecure direct object references (IDOR). In the referenced writeup, the hunter encountered a page that should have been restricted but was publicly accessible. Upon examining this page, they noticed that URL parameters were being passed directly to a database query without sanitization, setting the stage for SQL injection.

SQL injection (SQLi) remains one of the OWASP Top 10 risks. It allows an attacker to interfere with the queries an application makes to its database. By injecting malicious SQL statements, an attacker can bypass authentication, extract sensitive data, or even execute operating system commands.

2. Reconnaissance: Identifying Hidden or Unauthorized Pages

The first step is discovering endpoints that shouldn’t be public. Tools like dirb, gobuster, or Burp Suite’s content discovery can reveal hidden directories or files. Manual inspection of JavaScript files and source code may also uncover API routes lacking proper authorization.

Step‑by‑step guide:

• Use `gobuster` to enumerate directories:

  gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt
  

• Analyze responses: look for pages returning 200 OK but requiring authentication; these are candidates.
• For APIs, use `curl` to test endpoints with and without authentication tokens:

  curl -I https://target.com/api/admin/users
  curl -H "Authorization: Bearer <token>" https://target.com/api/admin/users
  

• If the first request returns data without a token, you have found an unauthorized access point.

3. Manual SQL Injection Detection and Exploitation

Once an unauthorized page is found, test its parameters for SQLi. Start by injecting common payloads and observing responses. For the hunter, a simple single quote (') triggered a database error, confirming SQLi.

Step‑by‑step manual testing:

• Inject a single quote into the parameter: `https://target.com/page?id=1’`
  – Look for error messages like “You have an error in your SQL syntax” or unexpected behavior.
• Use boolean-based testing: `id=1 AND 1=1` vs id=1 AND 1=2. If the first returns normal content and the second returns different, it’s likely injectable.
• Extract database version using union-based injection:

  id=1 UNION SELECT 1,2,3,@@version -- -
  

• On Windows targets, use `@@version` to get SQL Server details; on Linux, `version()` works for MySQL.

4. Automating with SQLMap for Deep Exploitation

Manual testing confirmed the vulnerability; now it’s time to automate. SQLMap is the go‑to tool for exploiting SQLi. It can enumerate databases, tables, columns, and even gain a shell if the database has file privileges.

Step‑by‑step SQLMap usage:

• Capture the vulnerable request (e.g., with Burp) and save it as request.txt.
• Run SQLMap to enumerate databases:

  sqlmap -r request.txt --dbs
  

• Once databases are identified, target the one containing sensitive data:

  sqlmap -r request.txt -D database_name --tables
  

• Dump a specific table:

  sqlmap -r request.txt -D database_name -T users --dump
  

• For deeper exploitation, attempt OS shell if privileges allow:

  sqlmap -r request.txt --os-shell
  

• SQLMap will attempt to upload a backdoor and execute commands. On Windows, this might give a `cmd` shell; on Linux, a bash shell.

1. Escalating SQL Injection to Critical Access (e.g., RCE, Privilege Escalation)
   With an OS shell, the hunter can pivot to internal networks, extract password hashes, or escalate privileges. In the writeup, the SQLi led to a shell with database service account privileges, which allowed lateral movement.

Step‑by‑step post-exploitation:

• On a compromised Linux host, enumerate users and services:

  cat /etc/passwd
  ps aux
  netstat -tulpn
  

• Look for stored credentials in configuration files:

  grep -r "password" /var/www/html
  

• On Windows, use `whoami /priv` to check privileges. If `SeImpersonatePrivilege` is enabled, use tools like `JuicyPotato` to escalate to SYSTEM.
• If the database server is separate, use the shell as a pivot to scan internal network:

  for i in {1..254}; do ping -c 1 192.168.1.$i; done
  

• Capture sensitive data like database backups or application source code.

6. Mitigation Strategies and Secure Coding Practices

To prevent such escalations, developers must adopt a defense‑in‑depth approach.

Step‑by‑step mitigation:

• Implement proper access controls: Use framework‑based middleware (e.g., Django’s @login_required, ASP.NET

  </code>) to ensure all pages are protected by default.</li>
  <li>Use parameterized queries/prepared statements: Never concatenate user input directly into SQL. Example in PHP (PDO):
  [bash]
  $stmt = $pdo->prepare('SELECT  FROM users WHERE id = :id');
  $stmt->execute(['id' => $id]);
  

• Employ an input validation whitelist: For numeric IDs, cast to integer.
• Deploy a Web Application Firewall (WAF) like ModSecurity to block SQLi patterns.
• Regularly scan with vulnerability scanners and conduct code reviews.