时间盲注与布尔盲注的流量特征识别

在流量侧识别SQL注入攻击时，时间盲注和布尔盲注的区分往往让很多分析师感到棘手。它们不像联合查询注入那样会在响应体里直接返回数据，也不像报错注入那样有明显的数据库错误回显。这两种“隐身”打法完全依赖应用程序对不同逻辑条件的间接反应来窃取数据，一个靠“是否返回不同内容”，一个靠“是否延迟响应”。要精准识别，核心在于抓住布尔盲注的“条件性内容差异”和时间盲注的“主动构造延迟”这两个本质区别。

布尔盲注的本质是攻击者向数据库提出一系列“是或否”的问题，并通过观察HTTP响应中细微但稳定的差异来推断答案。这种攻击在流量层面最显著的特征是同一请求的反复发送，且每次只改变判断条件中的一个字符或数字。

你会在访问日志或流量镜像中看到大量高度相似的HTTP请求。这些请求的URL参数或POST数据体中，往往包含数据库函数和比大小的逻辑。典型的攻击载荷会围绕ASCII码、SUBSTRING、MID等函数构造。例如，攻击者为了判断数据库用户名第一个字符是否为’a’，会发送如下请求：

GET /product?id=1 AND ASCII(SUBSTRING((SELECT database()),1,1))>97 HTTP/1.1

紧接着，他会根据返回页面的大小或特定内容关键字来调整判断逻辑，继续发送：

GET /product?id=1 AND ASCII(SUBSTRING((SELECT database()),1,1))=115 HTTP/1.1

从流量特征来看，布尔盲注的请求有两个决定性特征。第一，参数值中大量出现AND、OR与比较运算符（>、<、=）的组合，且常嵌套SELECT子查询。第二，也是最重要的识别点，服务器对这些连续请求的响应状态码几乎总是200 OK，但响应体存在两种截然不同的形态。一种形态对应“真”条件，可能返回正常的商品信息页面，页面长度较大；另一种形态对应“假”条件，可能返回一个空白的列表或“未找到”提示，页面长度明显偏小。攻击工具如sqlmap在进行布尔盲注时，会通过预设的字符串或正则表达式来严格区分这两种响应，这在流量上就表现为请求的密集发送和对响应长度、特定内容的高度依赖。

当应用程序对所有逻辑条件都返回完全相同的响应页面时，布尔盲注就失效了。这时攻击者会转向时间盲注。时间盲注的核心是向数据库注入一段休眠指令，通过服务器是否真的“卡顿”了指定时间来推断数据。这完全剥离了对响应内容差异的依赖，转而关注响应时间这一侧信道。

在流量中识别时间盲注，首先要看参数中是否包含特定数据库的休眠函数。MySQL的SLEEP()和BENCHMARK()，PostgreSQL的PG_SLEEP()，SQL Server的WAITFOR DELAY，Oracle的DBMS_LOCK.SLEEP()都是强特征。一个典型的攻击请求看起来像这样：

GET /product?id=1 AND IF(ASCII(SUBSTRING((SELECT database()),1,1))=115,SLEEP(5),0) HTTP/1.1

这个请求的逻辑很直白：如果数据库名的第一个字符ASCII码是115（即字母’s’），就让数据库睡5秒，否则直接返回。流量侧最直接的特征就是该请求的响应时间（Time to Last Byte）会异常地达到5000毫秒以上，而正常业务请求的响应时间可能只有几十到几百毫秒。

但高级攻击者会采用更隐蔽的方式。他们可能不会直接使用SLEEP(5)这种长延迟，而是利用重查询来制造可控的短延迟，比如构造复杂的笛卡尔积运算让数据库计算几秒钟。在流量上，这表现为响应时间不再是稳定的5秒或10秒，而是在一个较窄的范围内波动，比如2到3秒。这就需要分析人员建立业务请求的响应时间基线。如果某个参数值的变化能稳定复现出响应时间的增加，即使只增加了500毫秒，也需要高度警惕。另外，时间盲注的攻击流量在并发度上通常很低，因为攻击工具必须串行发送请求，等前一个请求超时或返回后才能根据时间差判断结果并构造下一个请求。因此，在流量图上，你会看到一个源IP以极其规律的间隔（比如每隔5.1秒）发起一个请求，形成一种机械的脉冲节奏。

在实际攻防中，攻击者往往会混合使用这两种技术。比如，先用布尔盲注快速判断字符范围，再用时间盲注做精确验证。自动化工具如sqlmap的特征在流量中非常明显。sqlmap在进行盲注探测时，会发送一些带有明显工具指纹的请求，例如参数中会出现类似SLEEP(5)的硬编码值，或者请求头中的User-Agent默认包含sqlmap字样。更隐蔽的流量特征在于请求参数的构造顺序。sqlmap在进行时间盲注时，其IF判断语句的格式、括号的闭合方式、以及SLEEP函数中参数的取值（通常是5或10这类整数）都有相对固定的模式。如果发现某个参数在短时间内被赋予了包含IF(…,SLEEP(…),…)这种嵌套结构的数十种变体，那几乎可以肯定是自动化盲注攻击。

这是流量分析中最容易误报的地方。网络抖动、服务器瞬时负载过高、或者某些业务逻辑本身就慢（如导出报表），都会导致高响应时间。要区分这些正常延迟和时间盲注，关键在于延迟是否“可被输入控制”。分析人员需要关注延迟与输入参数值的强关联性。如果一个请求因为参数id=1响应慢，id=2响应也慢，那多半是后端性能问题。但如果id=1 AND SLEEP(5)响应慢，而id=1 AND SLEEP(0)响应快，id=2 AND SLEEP(5)响应也慢，这就不是性能问题，而是注入问题。更严谨的做法是分析响应时间的分布。网络延迟通常符合某种随机分布，而时间盲注造成的延迟是人为叠加的固定值，在延迟时间的分布图上会呈现出双峰或多峰特征，其中一个峰紧贴着休眠时间。

要自动化检测这两种盲注，不能只靠正则匹配关键字，那样太容易被绕过。针对布尔盲注，更有效的思路是监控单个参数在短时间窗口内的响应体变化模式。如果一个参数的值在连续变化（比如末尾的数字从1递增到128），而响应体只在两种固定长度或两种固定页面模板之间来回切换，且请求频率很高，这就构成了布尔盲注的行为模型。针对时间盲注，则需要建立响应时间的动态基线。可以计算每个请求的响应时间与历史平均响应时间的标准偏差，当某个参数值的变化导致响应时间稳定地偏离基线数倍以上，且延迟时间与参数中的数值（如SLEEP函数的参数）存在线性关系时，触发告警。同时，要特别关注请求中是否出现了数据库的时间函数或重查询构造语法，并将这些语法特征与响应时间的异常升高进行关联分析，这样才能有效降低误报率，抓住真正隐匿的攻击行为。