SQL注入特征工程的核心陷阱是直接用原始URL训练模型，应先协议解析、按参数切分、提取词法/语法/行为三层结构异常特征，而非关键词统计，并需监控特征漂移与标签噪声。
SQL注入特征工程的核心陷阱：别把URL当SQL语句直接喂给模型
直接用原始HTTP请求（比如 GET /search?q=1%27%20OR%201%3D1--）做文本分类，模型大概率学的是“URL编码风格”而非“注入逻辑”。真实攻击载荷常混在合法字段中，例如 email=user%40domain.com%27%20UNION%20SELECT%20password%20FROM%20users--，这里关键不是%27，而是UNION SELECT与前后文的语义冲突。
实操建议：
- 先做协议解析：用
urllib.parse或requests.utils.requote_uri还原参数值，再对每个value单独处理 - 过滤掉明显白名单内容：如纯数字、邮箱格式、日期字符串等，避免污染特征空间
- 保留上下文边界：不要把整个query string拼成一长串，而是按
key=value切分，每个value独立提取特征
真正有效的SQL注入特征不是关键词，而是结构异常
单纯统计SELECT、UNION出现次数，会被“SELECTED”、“unionized”等误杀。机器学习需要能反映“语法意图违背”的信号。
推荐提取以下三类特征：
-
词法层：N-gram（n=2~4）频次 + 特殊字符密度（
'、"、;、--、/*在value中的占比） -
语法层：用轻量级SQL解析器（如
sqlparse）尝试解析value，记录parse_error标志、嵌套括号深度、子查询数量 - 行为层：对比同key历史请求，当前value长度突增、特殊符号数量翻倍、与常见输入分布（如手机号/邮箱正则）偏离度
训练数据不均衡？别只靠过采样，先检查标签噪声
很多公开数据集（如SQLi-Dataset、OWASP Benchmark）里标注为“恶意”的样本，实际是人工构造的典型Payload，而真实WAF日志里的攻击流量往往更碎片化、更依赖上下文。模型在测试集上AUC高，上线后却漏掉大量盲注和宽字节注入。
关键动作：
- 人工抽检标注样本：重点看
error-based和boolean-based类型是否被统一标为“1”，它们的特征分布差异很大 - 引入弱监督信号：对响应体含
mysql_num_rows、ORA-、psycopg2等错误关键词的请求，自动打上probable_attack辅助标签 - 放弃“全量标注”，改用主动学习：让模型对低置信度样本发起人工复核，优先标注那些
parse_error=True但keyword_count=0的case
模型上线后最常崩的点：特征漂移没监控
业务迭代会悄悄改变输入模式——比如某接口从接收id=123变成id={"type":"user","val":123}，JSON字段里突然出现;和UNION就不再是异常。特征统计量（如单引号密度均值）一个月内偏移超15%，模型准确率可能断崖下跌。
必须部署的监控项：
- 每日计算各特征的
KS检验值，对p-value < 0.01的特征触发告警 - 记录每个预测为攻击的样本中，起决定性作用的前3个特征及其原始值（例如：
bracket_depth=5、semicolon_density=0.12、ngram_3_freq["sel ect"]=0.08） - 对连续两周未触发的高危特征（如
exec、xp_cmdshell），启动特征有效性重评估
