<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Icy</title>
    <description>The latest articles on DEV Community by Icy (@icyyy).</description>
    <link>https://dev.to/icyyy</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3643529%2F13420ad6-9d8e-4713-94ad-b6207641be9c.png</url>
      <title>DEV Community: Icy</title>
      <link>https://dev.to/icyyy</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/icyyy"/>
    <language>en</language>
    <item>
      <title>Is SQL Injection dead in 2025? Finding Critical Bugs in Item Pagination</title>
      <dc:creator>Icy</dc:creator>
      <pubDate>Wed, 03 Dec 2025 14:41:25 +0000</pubDate>
      <link>https://dev.to/icyyy/is-sql-injection-dead-in-2025-finding-critical-bugs-in-item-pagination-1f6a</link>
      <guid>https://dev.to/icyyy/is-sql-injection-dead-in-2025-finding-critical-bugs-in-item-pagination-1f6a</guid>
      <description>&lt;p&gt;&lt;strong&gt;&lt;em&gt;Introduction&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;How did I find the bug?&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;On the Item page there is a navigation feature allowing users to jump to a specific page of listings.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fcwt3elf8ciwbtgle48d9.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fcwt3elf8ciwbtgle48d9.png" alt=" " width="296" height="42"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Pressing the "..."  button triggers a pop-up where you can manually input the page number. Naturally I wondered "Does it trust my input?".&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F6hobcs35ggb1sjzn7jad.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F6hobcs35ggb1sjzn7jad.png" alt=" " width="428" height="134"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fx6o8nbgncnx7sdumiy2y.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fx6o8nbgncnx7sdumiy2y.png" alt=" " width="800" height="30"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What did we get here?&lt;/strong&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Database Error Code: "SQLSTATE[42000]"&lt;/li&gt;
&lt;li&gt;Database Type&lt;/li&gt;
&lt;li&gt;Logic Leak: the error showed exactly where the input was processed (-25,25)&lt;/li&gt;
&lt;li&gt;Full Path Disclosure: (var/.../.../...php etc.)&lt;/li&gt;
&lt;li&gt;Internal Functions&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;The 0xC trick&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;To confirm if the input was being passed directly to the SQL query without proper sanitization, I tried a classic bypass. "0xC"&lt;br&gt;
The result? The site processed it perfectly and loaded Page 12.&lt;br&gt;
In decimal, 0xC equals 12.&lt;br&gt;
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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;Second try, second vulnerability&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F86ive586k4feva6tu2og.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F86ive586k4feva6tu2og.png" alt=" " width="346" height="164"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;"Better be safe than sorry!"&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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. &lt;br&gt;
The experience reinforced a valuable lesson: Input validation is non-negotiable, even for something simple, like a page number.&lt;/p&gt;

&lt;p&gt;Let me know what do you think, was it exploitable or not?&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Resources &amp;amp; References:&lt;/strong&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;a href="https://infosecwriteups.com/exploiting-sql-error-sqlstate-42000-to-own-mariadb-of-a-large-eu-based-online-media-and-cf7396c43bbf" rel="noopener noreferrer"&gt;https://infosecwriteups.com/exploiting-sql-error-sqlstate-42000-to-own-mariadb-of-a-large-eu-based-online-media-and-cf7396c43bbf&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a href="http://www.davidlitchfield.com/Lateral_SQL_Injection_Revisited_Final.pdf" rel="noopener noreferrer"&gt;http://www.davidlitchfield.com/Lateral_SQL_Injection_Revisited_Final.pdf&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a href="https://sechow.com/bricks/docs/content-page-1.html" rel="noopener noreferrer"&gt;https://sechow.com/bricks/docs/content-page-1.html&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

</description>
      <category>sql</category>
      <category>web</category>
      <category>database</category>
      <category>security</category>
    </item>
  </channel>
</rss>
