最简单实用的SQL注入检测方法：Break & Repair技巧详解

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

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

第一步：首先了解数据库在测试之前，你需要对应用程序使用的数据库类型有个基本了解：

是MySQL吗？是PostgreSQL吗？是Oracle吗？或者甚至不是基于SQL的，可能是MongoDB（NoSQL）？为什么这很重要？因为payload是特定于数据库的。MySQL的payload不一定在MongoDB上工作，MongoDB的payload也不在PostgreSQL上工作。

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

第二步：不要过早假设假设你找到一个端点，如"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_大声喊叫，非常感谢你的提示和指导，我在这里分享的很多内容都来自你的想法，加上我自己的研究以及我在此过程中理解问题的方式。