SQL 注入在 2025 年已经死了吗？在 Item Pagination 中发现关键漏洞
发布: (2025年12月3日 GMT+8 22:41)
3 min read
原文: Dev.to
Source: Dev.to
引言
许多开发者认为，到了 2025 年，我们已经足够先进，已经看不到简单的 SQL 注入漏洞了。在浏览一个知名 TF2 交易站点的功能时，我发现旧习难改。
我是怎么发现这个 bug 的？
在 Item 页面有一个导航功能，允许用户跳转到特定的列表页。点击 “…” 按钮会弹出一个窗口，用户可以手动输入页码。我自然会想，“它会信任我的输入吗？”。
我没有输入数字，而是输入了字符 e。应用没有优雅地处理它；它没有返回通用的 404 或软错误，而是抛出了致命错误，暴露了大量敏感信息。
我们得到了什么？
- 数据库错误代码：
SQLSTATE[42000] - 逻辑泄漏： 错误精确显示了输入被处理的位置（例如
-25,25）。 - 完整路径泄露： 如
var/.../.../...php的文件路径被公开。 - 内部函数信息： 技术栈和文件位置的细节被暴露。
仅凭这些信息泄露就已经非常危急，因为它告诉攻击者到底使用了什么栈以及文件具体位于何处。
0xC 技巧
为了确认输入是否直接传递到 SQL 查询而未经过适当的清理，我尝试了经典的 0xC 绕过。
第二次尝试，第二个漏洞
为了了解影响范围，我启动了 Burp Suite 并进一步操纵请求。请求中包含了 UI 中不可见的参数。通过更改参数名，我能够在不同模块中触发一致的 SQL 语法错误。
虽然有些开发者认为通过整数值、LIMIT 或 OFFSET 子句进行的 SQL 注入难以利用，但多篇资料已经证明并非如此（见下方参考）。
披露
我已负责任地向站点工作人员披露了该漏洞。虽然该站点有漏洞赏金计划，但我被告知该 bug “已知”且 “风险低”。随后不久，问题被修复，错误信息也被关闭。