Break & Repair：我是如何以最简单的方式测试SQL注入的
当我看到人们讨论SQL注入测试时，我注意到一个普遍现象：很多初学者感到困惑。有些人甚至因为不确定要寻找什么或如何正确测试而难以开始。
在这篇文章中，我想分享我个人测试SQL注入的方法，以非常简单的方式。
第一步：首先了解数据库
在测试之前，你需要对应用程序使用什么类型的数据库有个基本了解。
- 是MySQL吗？
- 是PostgreSQL吗？
- 是Oracle吗？
- 或者它甚至不是基于SQL的，可能是MongoDB（NoSQL）？
为什么这很重要？因为有效载荷是特定于数据库的。MySQL的有效载荷不一定在MongoDB上工作，MongoDB的有效载荷也不在PostgreSQL上工作。
所以，第一条规则：在开始喷洒有效载荷之前，先了解数据库类型。
第二步：不要过早假设任何事
假设你找到一个端点，比如"example.com/user?id=123...
诀窍是在下结论之前先与之交互。
第三步："Break and Repair"技巧
这是我一直在使用的真正宝贵技巧，我称之为"Break and Repair"。
实际上我是从观看Tib3rius在YouTube上的视频中获得这个想法的，但我把它简化成了自己的风格。逻辑很简单：
首先，尝试破坏SQL环境。 然后，尝试修复它。
让我解释一下。
破坏
你取参数并在末尾添加一个单引号（'），即（example.com/user?id=123...
会发生什么？
- 有时，你会看到错误消息（如"SQL语法错误"）。
- 有时，你根本看不到任何响应，它只是变成空白或返回默认错误页面。
两者都是重要的信号。
修复
现在，添加另一个单引号（所以你有两个），（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_，非常感谢你的提示和指导，我在这里分享的很多内容都来自你的想法，加上我自己的研究以及我在此过程中理解事物的方式。