Introduction
Many developers believe that in 2025, we are too advanced to see simple SQL Injection vulnerabilities anymore. Well, while browsing the functionalities of a well-known TF2 trading site, I discovered that old habits die hard.
How did I find the bug?
On the Item page there is a navigation feature allowing users to jump to a specific page of listings.
Pressing the "..." button triggers a pop-up where you can manually input the page number. Naturally I wondered "Does it trust my input?".
Instead of a number, I inputted the character "e". The application didn't handle it gracefully, instead of a generic 404 or soft error the site threw a Fatal Error exposing massive amount of sensitive information.
What did we get here?
- Database Error Code: "SQLSTATE[42000]"
- Database Type
- Logic Leak: the error showed exactly where the input was processed (-25,25)
- Full Path Disclosure: (var/.../.../...php etc.)
- Internal Functions
This "Information Disclosure" alone is critical. It tells an attacker exactly what technology stack is running and where the files are located. I wanted to see also if the input was actually interacting with the database logic.
The 0xC trick
To confirm if the input was being passed directly to the SQL query without proper sanitization, I tried a classic bypass. "0xC"
The result? The site processed it perfectly and loaded Page 12.
In decimal, 0xC equals 12.
This confirmed that the application was not strictly validating integers. It was accepting strings that "looked" like numbers (type juggling) and passing them straight to the database layer.
Second try, second vulnerability
To understand the scope, I started Burpsuite and tried to manipulate the request further. The request contained parameters that weren't visible in the UI. Changing parameter names I was able to trigger consistent SQL syntax errors across different modules.
While some developers argue that SQL Injection via passing integer values / LIMIT or OFFSET clauses is difficult to exploit, some resources prove otherwise. *check the resources down bellow
"Better be safe than sorry!"
I responsibly disclosed the vulnerability to the site's staff. Interestingly, despite having a Bug Bounty program, I was told the bug was "known" and "low risk". However shortly the issue was patched and the error messages were disabled.
The experience reinforced a valuable lesson: Input validation is non-negotiable, even for something simple, like a page number.
Let me know what do you think, was it exploitable or not?
Resources & References:
Top comments (0)