基于机器学习识别SQL注入攻击语句

SQL注入攻击在OWASP十大安全威胁中常年位居前列，不是因为它的技术有多高深，恰恰相反，是因为它的变种太多、绕过手法太灵活，传统基于正则匹配和规则库的WAF已经疲于应对。攻击者只需要在payload里加几个注释符、换一下大小写、用上十六进制编码或者等价函数替换，就能轻松穿透层层设防。这就是为什么机器学习开始成为SQL注入检测领域的关键变量——它不再死记硬背攻击特征，而是学习攻击行为本身的模式。

传统的检测方法主要依赖正则表达式和关键词黑名单。比如检测"union select"、"or 1=1"、"drop table"这类敏感组合。但攻击者可以这样绕过：把"union select"写成"UnIoN//SeLeCt"，把"or 1=1"改写成"or 0x31=0x31"，甚至用科学计数法"or 1.e(1)=1.e(1)"。每出现一种新的绕过技巧，规则库就得跟着更新，永远慢攻击者一步。

机器学习解决这个问题的思路完全不同。它不关心具体的敏感词是什么，而是关心整个输入序列的结构异常。一条正常的查询请求和一条注入payload，在字符分布、语法结构、信息熵等维度上存在本质差异。正常请求通常是规整的SQL语法结构，注入payload则往往包含大量运算符、注释符、编码字符和不对称的引号。这些特征可以被数值化，变成机器学习模型能够理解的向量，然后让模型在海量样本中自动学会区分正常和恶意。

这是整个方案中最关键也最吃经验的环节。原始SQL语句是文本，不能直接喂给模型，需要提取出有区分度的数值特征。经过大量实战验证，以下几类特征在SQL注入检测中表现最为稳定。

第一类是词法特征。把SQL语句按词法规则切分成token序列，统计关键词数量、运算符占比、函数调用次数、注释出现频率等。例如正常查询中SELECT、FROM、WHERE这类关键词占比通常较高且排列有序，而注入payload中逻辑运算符（AND、OR）和比较运算符（=、<、>）的密度会异常升高。

第二类是字符级统计特征。计算字符串长度、特殊字符占比、大小写字母比例、数字占比、非ASCII字符占比。注入payload为了绕过过滤，经常使用大量空格、注释符、换行符和编码字符，这些会导致特殊字符占比明显偏高。

第三类是语法结构特征。可以通过简单的语法解析器提取SQL语句的嵌套深度、子查询数量、UNION出现次数、引号配对情况。正常请求的引号通常是成对出现的，而注入攻击往往需要提前闭合引号，导致引号数量为奇数或者出现不匹配的引号序列。

第四类是信息熵特征。计算SQL语句的字符熵和token熵。正常SQL语句的熵值相对稳定，而经过编码混淆的注入payload熵值往往异常高，因为编码后的字符串看起来更像随机序列。

把这些特征组合起来，一条SQL语句就可以被表示为一个固定长度的特征向量。比如：[长度，特殊字符占比，关键词数量，运算符占比，注释数量，引号不匹配标志，字符熵，token熵，嵌套深度，UNION出现次数]。这个向量就是后续模型训练的输入。

特征向量准备好之后，接下来是选模型。对于SQL注入检测这个具体场景，有几类模型经过了大量实战检验，各有优劣。

随机森林是最常用的基线模型。它的优势在于训练快、可解释性强、对特征缩放不敏感，而且能输出每个特征的重要性排序，这对后续优化特征工程非常有帮助。在样本量在十万级别、特征维度在几十到几百的场景下，随机森林通常能拿到85%到90%的准确率。

XGBoost和LightGBM这类梯度提升树模型效果通常更好。它们对非线性关系的拟合能力更强，能自动处理特征之间的交互。在特征工程做得比较充分的情况下，这类模型可以把准确率推到92%以上，同时误报率控制在较低水平。

如果样本量足够大，比如百万级别以上，深度学习模型会展现出更强的优势。用TextCNN或者LSTM直接处理SQL语句的字符序列，省去人工特征工程的环节，让模型自动学习字符级别的模式。TextCNN通过不同大小的卷积核捕捉局部n-gram模式，对SQL注入中常见的局部混淆手法识别效果很好。LSTM则擅长捕捉长距离依赖关系，对于跨多个子句的注入攻击检测更敏感。

训练样本的构建同样重要。正样本（恶意SQL）可以从公开的SQL注入payload数据集获取，也可以自己用SQLmap等工具生成。负样本（正常SQL）需要从实际业务系统的日志中提取，确保覆盖各种正常的查询模式。正负样本比例一般控制在1:3到1:5之间，避免模型偏向某一类。另外一定要做时间维度的切分验证，用历史数据训练、未来数据测试，模拟真实上线后的效果，防止数据泄露导致评估结果虚高。

模型训练好只是完成了三分之一的工作，真正的挑战在于把它部署到生产环境里稳定运行。以下几个工程化要点决定了方案能不能真正落地。

延迟控制是首要问题。如果检测模型在请求链路中同步调用，那么模型推理时间必须控制在毫秒级。树模型推理速度极快，单次预测通常在微秒级别，对业务延迟几乎无影响。深度学习模型则需要做推理优化，比如用ONNX Runtime或者TensorRT做模型加速，或者把模型蒸馏成更小的网络结构。

模型更新机制需要设计好。SQL注入手法在不断演进，模型必须能够持续学习新样本。比较务实的做法是建立反馈闭环：线上模型持续产出预测结果，安全运营人员定期复核模型判定的高危请求，把确认的漏报和误报样本加入训练集，每月或每季度重新训练一次模型并上线替换。这个过程可以做成半自动化流水线，减少人工介入成本。

可解释性在安全场景下格外重要。当模型拦截了一条请求，安全分析师需要知道为什么拦截，否则没法判断这是真攻击还是误报。树模型天然可以输出特征重要性，告诉分析师是哪个特征触发了拦截。对于深度学习模型，可以用LIME或者SHAP这类事后解释工具，高亮出输入序列中对预测结果贡献最大的字符片段。

还有一个容易被忽略的点是模型鲁棒性。攻击者如果知道你在用机器学习做检测，可能会尝试对抗性攻击，故意在payload中加入一些干扰字符来改变特征分布，让模型误判。对抗训练是一种有效的防御手段，在训练集中加入经过对抗样本生成算法处理过的样本，让模型学会抵抗这类干扰。

下面是一个完整的训练流程示例，使用Python和scikit-learn构建基于随机森林的SQL注入检测模型。

import re
import numpy as np
import pandas as pd
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
import pickle

def extract_features(sql):
    features = {}
    features['length'] = len(sql)
    features['special_char_ratio'] = len(re.findall(r'[^a-zA-Z0-9\s]', sql)) / max(len(sql), 1)
    features['digit_ratio'] = len(re.findall(r'\d', sql)) / max(len(sql), 1)
    features['upper_ratio'] = len(re.findall(r'[A-Z]', sql)) / max(len(sql), 1)
    features['space_ratio'] = len(re.findall(r'\s', sql)) / max(len(sql), 1)
    features['comment_count'] = len(re.findall(r'/\*|\*/|--|#', sql))
    features['union_count'] = len(re.findall(r'(?i)\bunion\b', sql))
    features['select_count'] = len(re.findall(r'(?i)\bselect\b', sql))
    features['or_count'] = len(re.findall(r'(?i)\bor\b', sql))
    features['and_count'] = len(re.findall(r'(?i)\band\b', sql))
    features['quote_count'] = len(re.findall(r"'", sql))
    features['quote_mismatch'] = 1 if features['quote_count'] % 2 != 0 else 0
    features['char_entropy'] = calc_entropy(sql)
    return list(features.values())

def calc_entropy(s):
    if not s:
        return 0
    freq = {}
    for c in s:
        freq[c] = freq.get(c, 0) + 1
    length = len(s)
    entropy = 0
    for count in freq.values():
        p = count / length
        entropy -= p * np.log2(p)
    return entropy

# 假设已有标注数据
# df = pd.read_csv('sql_dataset.csv')  # 包含sql语句和label列
# X = np.array([extract_features(sql) for sql in df['sql']])
# y = df['label'].values
# X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
# model = RandomForestClassifier(n_estimators=100, max_depth=15, random_state=42)
# model.fit(X_train, y_train)
# y_pred = model.predict(X_test)
# print(classification_report(y_test, y_pred))
# with open('sql_injection_model.pkl', 'wb') as f:
#     pickle.dump(model, f)

这段代码定义了一个特征提取函数，涵盖了前面讨论的长度、特殊字符占比、数字占比、大小写比例、注释数量、关键字出现次数、引号配对情况和字符熵。实际使用时需要根据自己的数据集调整特征列表，可能需要加入更多业务相关的特征。

模型上线后需要建立完善的监控体系。核心指标包括检出率（召回率）、误报率、平均检测延迟和模型衰减速度。检出率低于95%说明漏报太多，需要补充新样本重新训练。误报率高于1%会对业务造成明显干扰，需要分析误报样本的特征分布，针对性优化特征工程或者调整分类阈值。

一个值得关注的趋势是把检测从请求级别下沉到参数级别。整条SQL语句作为一个整体输入模型，虽然简单直接，但对于长SQL语句中只有某个参数存在注入的情况，整体特征可能被大量正常内容稀释。把每个参数值单独提取出来做检测，可以大幅提升对局部注入的敏感度。具体做法是先解析SQL语句结构，定位到每个用户输入的参数位置，然后只对参数值部分提取特征并做预测。

另外，多模型融合也是提升整体效果的有效手段。可以同时运行一个树模型和一个深度学习模型，树模型负责快速初筛，深度学习模型对树模型判定为可疑的样本做二次精细判断。这样既保证了整体吞吐量，又在关键样本上获得了更高的准确率。

机器学习应用于SQL注入检测，本质上不是要替代传统的规则引擎，而是和规则引擎形成互补。规则引擎处理那些特征明确、模式固定的攻击，机器学习捕捉那些变形灵活、模式多变的攻击。两者结合起来，才能构建出真正有韧性的SQL注入防御体系。