Introduction

Injection vulnerabilities continue to be one of the most critical risks in web applications. In this blog post, I'll share a Blind SQL Injection vulnerability identified in an Expense Management module during a bug bounty program, how it can be exploited, and how it can be mitigated.

Vulnerability Overview

The vulnerability exists in the ManageUser endpoint of the Expense Management module. Specifically, the id parameter is not properly validated or sanitized, allowing an attacker to inject malicious SQL queries.

Since the application does not return direct database errors or output, this is a Blind SQL Injection, where the attacker confirms exploitation through indirect methods such as response delays.

Affected Endpoint

https://example.com/expensemanagement/Admin/ManageUser?id=<user_id>

Steps to Reproduce

  1. Open a browser and log in to the in-scope application: https://example.com
  2. Authenticate using a valid account (e.g., Administrator). Navigate to: Pay → Expense Management. You will be redirected to the Expense Management dashboard.
None

3. Go to: Users Select any user and intercept the request using a proxy tool like Burp Suite. Capture the request to the following endpoint: /expensemanagement/Admin/ManageUser?id=<user_id>

None

4. Modify the id parameter by injecting the following payload: ' waitfor delay Ɔ:0:1' —

None
None

5. Update the payload with time delay of 10 seconds then forward the request and observe the response time.

None
None

Proof of Concept

When the payload is injected, the application introduces a deliberate delay (e.g., 1 second and 10 seconds) in the response. This confirms that the SQL query is being executed on the backend, validating the presence of Blind SQL Injection.

Impact

This vulnerability can have severe consequences, including:

  • Unauthorized data extraction from the database
  • Enumeration of database structure (tables, columns, users)
  • Potential authentication bypass
  • Full database compromise in advanced exploitation scenarios

Even though it is "blind," attackers can automate data extraction using time-based techniques.

Root Cause

  • Lack of input validation on the id parameter
  • Direct inclusion of user input in backend SQL queries
  • Absence of parameterized queries / prepared statements
  • Insufficient security testing for injection flaws

Recommended Mitigation

1. Use Parameterized Queries

Always use prepared statements instead of dynamic SQL queries:

SELECT * FROM users WHERE id = ?

2. Input Validation

  • Enforce strict validation (e.g., UUID format for id)
  • Reject unexpected input patterns

3. Use ORM Frameworks

Leverage secure ORM libraries that automatically handle query parameterization.

4. Implement Web Application Firewall (WAF)

  • Detect and block SQL injection payloads

5. Security Testing

  • Include SQL Injection checks in SAST/DAST pipelines
  • Perform regular penetration testing

Severity Assessment

  • Vulnerability Type: Blind SQL Injection
  • Attack Vector: Authenticated
  • Impact: Critical
  • Risk Level: High

Conclusion

Blind SQL Injection vulnerabilities can be harder to detect but are equally dangerous as traditional SQL injection flaws. This case highlights the importance of secure coding practices and robust input validation, especially in sensitive modules like expense and user management.

Final Thoughts

If you're working in AppSec or bug bounty hunting, always test ID-based parameters carefully — especially in admin or configuration modules. These are often overlooked but can lead to critical findings like this one.