Break & Repair：我是如何以最简单的方式测试 SQL 注入的

当我看到人们讨论 SQL 注入测试时，我注意到一个普遍现象：很多初学者感到困惑。有些人甚至因为不确定要寻找什么或如何正确测试而难以开始。

在这篇文章中，我想分享我个人测试 SQL 注入的方法，以非常简单的方式。

第一步：首先了解数据库

在测试之前，你需要对应用程序使用什么类型的数据库有个基本了解。

• 是 MySQL 吗？

• 是 PostgreSQL 吗？

• 是 Oracle 吗？

• 或者它甚至不是基于 SQL 的，可能是 MongoDB（NoSQL）？

为什么这很重要？因为有效载荷是特定于数据库的。MySQL 的有效载荷不一定在 MongoDB 上工作，MongoDB 的有效载荷也不在 PostgreSQL 上工作。

所以，第一条规则：在开始喷洒有效载荷之前，先了解数据库类型。

第二步：不要过早假设任何事

假设你找到一个端点，比如"https://example.com/user?id=123"。这看起来像是一个可能与数据库交互的参数。但不要只是假设它是易受攻击的。甚至不要假设它是 SQL，它可能是 NoSQL 或者只是一个返回 JSON 的 API。

诀窍是在下结论之前先与之交互。

第三步："Break and Repair"技巧

这是我一直在使用的真正宝贵技巧，我称之为"Break and Repair"。

实际上我是从观看 Tib3rius 在 YouTube 上的视频中获得这个想法的，但我把它简化成了自己的风格。逻辑很简单：

首先，尝试破坏 SQL 环境。然后，尝试修复它。

让我解释一下。

破坏

你取参数并在末尾添加一个单引号（'），即（https://example.com/user?id=123'）

会发生什么？

• 有时，你会看到错误消息（如"SQL 语法错误"）。

• 有时，你根本看不到任何响应，它只是变成空白或返回默认错误页面。

两者都是重要的信号。

修复

现在，添加另一个单引号（所以你有两个），（https://example.com/user?id=123''）

通过这样做，你基本上是在再次正确"关闭"SQL 查询。

如果对 123'（破坏）的响应与 123''（修复）不同，那就是背后有 SQL 在运行的线索。

这就是我所说的"Break and Repair"。你用一个引号破坏查询，然后用两个引号修复它。如果服务器在两者之间表现不同，恭喜你，你找到了一个可能的 SQL 注入入口点。

第四步：测试盲 SQL 注入

并非所有 SQL 注入都会抛出明显的错误消息。很多时候，你什么也看不到，这就是盲 SQL 注入的用武之地。

在这里，你可以使用诸如：

• 基于布尔的 payload（真/假条件）

• 基于时间的 payload（响应延迟）

例如，如果你正在测试 MySQL，你可能会尝试类似（?id=123' AND SLEEP(5)-- -）的东西

如果页面突然多花 5 秒加载，那就是你的信号。

再次记住，payload 取决于数据库。MySQL 的 payload 在 MongoDB 上不起作用。

第五步：提取信息（证明影响）

在漏洞赏金计划中，找到 SQL 注入很棒——但证明影响更重要。

大多数公司希望你能证明漏洞是真实的。你不需要转储整个数据库，那没有必要。但你可以展示简单的东西，比如：

• 数据库名称

• 数据库版本

• 当前用户

例如，在 MySQL 中，你可以提取（SELECT database(); SELECT version();）

这通常足以让公司接受你的报告。

最后思考

每当我测试 SQLi 时，我不会过度思考。我只是记住一个简单的方法，那就是"Break and Repair"。

如果你刚接触漏洞赏金狩猎或渗透测试，不要让 SQL 注入吓到你。从基础开始，了解数据库，并应用 break and repair。随着你的练习，其余的自然而然就会了。

特别感谢我称之为"SQLi 大师"的 @5hady_，非常感谢你的提示和指导，我在这里分享的很多内容都来自你的想法，加上我自己的研究以及我在此过程中理解事物的方式。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享