SQL注入延时攻击的本质是利用数据库查询时间差来逐字节推断数据，攻击者不依赖页面回显，而是通过构造条件语句让数据库在满足特定条件时主动休眠，再根据响应时间判断条件真假。这种攻击方式隐蔽性极强，因为请求本身看起来完全正常，返回状态码也往往是200，传统基于规则匹配的WAF很难发现异常。要识别延时注入，核心思路是建立时间基线并检测偏离，而不是试图匹配攻击载荷。
延时注入的常见触发手法
攻击者最常用的数据库延时函数包括MySQL的SLEEP()、BENCHMARK()，SQL Server的WAITFOR DELAY，PostgreSQL的pg_sleep()，以及Oracle中利用DBMS_LOCK.SLEEP()或重型查询。典型载荷形如：
1' AND SLEEP(5)-- - 1' AND IF(SUBSTRING(user(),1,1)='r',SLEEP(5),0)-- - 1'; WAITFOR DELAY '0:0:5'-- -
这些语句的共同特征是在条件分支中嵌入延时操作。攻击者会先发送一个正常请求测量基准响应时间，再发送带延时函数的请求，如果响应时间显著增加，说明注入点存在。随后攻击者通过二分法逐字符提取数据库名、表名、字段名和敏感数据，整个过程可能持续数小时甚至数天。
识别延时的三个关键维度
第一是响应时间分布异常。正常业务请求的响应时间通常集中在某个稳定区间，比如50毫秒到200毫秒之间，而延时注入请求会突然出现5秒、10秒甚至更长的响应。但单纯看长响应不够，因为慢查询、网络抖动、后端资源竞争也会导致偶发长响应。真正有效的做法是统计同一接口在短时间窗口内的时间分布，如果出现规律性的、与数据库延时函数参数高度吻合的时间峰值，就要高度警惕。
第二是请求参数结构的异常。延时注入载荷往往包含数据库特定的函数名、注释符、字符串拼接符，以及大量重复的括号和引号。即使攻击者使用编码、注释混淆、大小写变换，其参数长度和字符熵值也会与正常输入产生明显差异。对参数进行长度统计和熵值计算，可以捕捉到这类异常。
第三是访问行为模式异常。自动化延时注入工具通常以极高的频率发送请求，且请求之间参数变化呈现系统性的逐位试探特征。例如攻击者在探测数据库名第一个字符时，会连续发送数十个请求，每个请求只改变比较的字符值。这种请求序列在时间上和参数结构上都高度相关，与正常用户的随机访问模式截然不同。
精准防护的第一层：时间基线动态建模
静态阈值无法适应业务变化，必须对每个接口建立动态时间基线。具体做法是：以接口为单位，按小时或分钟粒度统计历史响应时间的分位数，例如P50、P95、P99。当新请求的响应时间超过该接口当前时段P99分位数的一定倍数，比如3倍，且绝对值超过某个下限，比如1秒，就标记为延时异常候选。这个下限很重要，因为如果P99只有100毫秒，3倍也才300毫秒，攻击者用SLEEP(1)就能轻松绕过，所以需要结合绝对阈值。
更精细的做法是引入滑动窗口内的中位数绝对偏差。对于每个接口，维护最近N次正常请求的响应时间集合，计算中位数和MAD值。当新请求的响应时间偏离中位数超过k个MAD时触发告警。这种方法对非正态分布的时间数据更稳健，能自适应业务波动。
精准防护的第二层：载荷语义分析
单纯的时间检测存在误报，需要结合请求内容做语义级判断。将请求参数解码后，提取其中的SQL语法特征。重点检测以下几类模式：数据库延时函数名及其变体，包括大小写混合、注释插入、字符串拼接绕过；条件分支结构，如IF、CASE WHEN、AND、OR与延时函数的组合；时间参数特征，如SLEEP括号内出现的数字，WAITFOR DELAY后的时间字符串。检测时不能只做字符串匹配，需要将参数还原为规范化形式，去除注释、空白和编码干扰后再分析。
一个有效的策略是构建抽象语法树片段。将参数中疑似SQL的部分解析成token序列，识别出函数调用、比较运算、逻辑运算的组合关系。如果发现逻辑运算的结果直接影响延时函数的执行，就可以判定为高置信度的延时注入行为。这种方法误报率极低，但对解析能力要求较高。
精准防护的第三层：响应时间与请求参数的关联验证
当时间异常和载荷特征同时出现时，还需要做关联验证以排除偶发因素。具体做法是：对触发告警的请求，自动构造一个去除延时函数但保留其他结构的对照请求，或者构造一个延时参数不同的变体请求，在受控环境下发送到目标接口。如果对照请求响应时间恢复正常，而变体请求的响应时间随延时参数线性变化，就能确认该接口存在可利用的延时注入点。这种主动验证方式需要谨慎控制频率，避免对业务造成额外负载，并且只应在已经触发高置信度告警时使用。
数据库层的主动防御措施
应用层防护之外，数据库配置同样关键。限制数据库账号的执行权限，确保应用连接数据库的账号不具备执行SLEEP、BENCHMARK、WAITFOR DELAY等函数的权限。在MySQL中，可以通过限制账号的EXECUTE权限或使用存储过程白名单来间接限制。对于必须保留的函数，可以在数据库代理层设置查询超时，例如超过3秒的查询直接终止。但要注意，过短的超时会误杀正常的慢查询，需要结合业务实际调整。
另外，启用数据库的查询日志并实时分析慢查询日志，也能发现延时注入的痕迹。攻击者的延时查询会以异常高的频率出现在慢查询日志中，且SQL文本具有明显的模式特征。将慢查询日志接入SIEM或日志分析平台，设置针对SLEEP、BENCHMARK等关键词的告警规则，可以作为应用层检测的补充。
基于机器学习的异常检测思路
当攻击者使用高度混淆的载荷或分段延时技术时，规则匹配和阈值检测可能失效。此时可以考虑基于机器学习的异常检测。特征工程方面，提取每个请求的以下特征：参数长度、字符种类数、特殊字符占比、SQL关键字出现次数、数字个数、括号嵌套深度、响应时间、请求间隔时间、同一会话内的请求序列相似度。使用孤立森林或自编码器在正常流量上训练模型，检测偏离正常分布的请求。
需要注意的是，机器学习模型需要大量标注数据，且模型可解释性较差。在实际部署中，建议将机器学习模型的输出作为风险评分，与规则引擎的结果融合，而不是直接替代规则。当模型给出高分但规则未命中时，进入人工审核队列，避免误拦截。
响应与处置策略
确认延时注入攻击后，第一时间在WAF或应用网关层对该源IP或会话实施临时封禁，同时记录完整的攻击载荷和请求序列。但封禁IP只是临时措施，攻击者更换代理或IP池后可以继续攻击。更持久的处置是修复注入点，使用参数化查询或预编译语句重写存在漏洞的数据库交互代码。如果无法立即修复，可以在应用层增加输入校验，对包含数据库函数名、注释符、逻辑运算符的参数直接拒绝，但这只是缓解措施，不能替代代码修复。
对于已经发生的延时注入，需要评估数据泄露范围。通过分析攻击载荷中探测的数据库对象和字段，确定攻击者可能已经获取了哪些数据。如果涉及敏感信息，应启动数据泄露应急响应流程，通知相关方并评估合规影响。
防护体系的分层部署建议
有效的延时注入防护需要多层协作。在网络边界部署WAF，配置时间基线和载荷语义检测规则，拦截明显的攻击流量。在应用服务器上部署RASP，监控应用内部的数据库调用，检测异常的查询执行时间和查询结构。在数据库层配置权限最小化和查询超时，阻断延时函数的执行。在日志层集中分析应用日志和数据库慢查询日志，发现绕过边界防护的攻击行为。各层之间通过统一的告警平台关联分析，形成完整的检测和响应闭环。
延时注入攻击的识别与防护不能依赖单一技术，时间基线建模解决“什么时候异常”，载荷语义分析解决“异常是什么”，关联验证解决“异常是否真实”，数据库层防御解决“异常能否执行”。只有将时间维度、内容维度和行为维度结合起来，才能在攻击者完成数据提取之前发现并阻断延时注入。
