最简单的SQL注入测试方法：Break & Repair技术详解每当看到人们讨论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"。你用一个引号破坏查询，然后用两个引号修复它。如果服务器在两者之间的行为不同，恭喜你，你找到了一个可能的SQLi入口点。
第四步：测试盲SQL注入并非所有SQL注入都会抛出明显的错误消息。很多时候，你什么也看不到，这就是盲SQL注入的用武之地。
在这里，你可以使用以下技巧：
基于布尔的payload（真/假条件）基于时间的payload（响应延迟）例如，如果你正在测试MySQL，你可能会尝试类似（?id=123' AND SLEEP(5)-- -）的东西
如果页面突然多花了5秒加载，那就是你的信号。
再次记住，payload取决于数据库。MySQL的payload在MongoDB上不起作用。
第五步：提取信息（证明影响）在漏洞赏金计划中，找到SQLi很好——但证明影响更好。
大多数公司希望你能证明漏洞是真实的。你不需要转储整个数据库，那没有必要。但你可以展示简单的东西，比如：
数据库名称数据库版本当前用户例如，在MySQL中，你可以提取（SELECT database(); SELECT version();）
这通常足以让公司接受你的报告。
最后思考每当我测试SQLi时，我不会过度思考。我只是记住一个简单的方法，那就是"Break and Repair"。
如果你刚接触漏洞赏金狩猎或渗透测试，不要让SQL注入吓到你。从基础开始，了解数据库，并应用break and repair。随着你的练习，其余的自然而然就会了。
特别感谢我称之为"SQLi大师"的@5hady_，非常感谢你的提示和指导，我在这里分享的很多内容都来自你的想法，加上我自己的一些研究以及我在这个过程中理解问题的方式。