★ FEATURED ARTICLE 简介这份资源面向网络安全初学者、数据挖掘学习者与Web安全从业者提供一套用机器学习区分SQL注入语句与正常语句的完整实验方案覆盖SVM、Adaboost、决策树、随机森林、逻辑斯蒂回归、KNN、贝叶斯等多种分类算法的对比实践。压缩包共36个文件约1.06MB包含10个csv样本数据、10个Python脚本、8个已训练模型文件以及xml配置、readme说明与iml工程文件分别用于数据存放、特征提取与模型训练、结果测试等环节。其中预处理脚本负责对原始样本提特征各算法脚本分别训练模型测试脚本以准确率度量效果训练好的模型可直接加载复用。目前已有291人学习下载适合希望理解特征工程、多模型对比与安全场景分类落地流程的读者参考也可作为课程设计或安全检测实验的起步模板。1. 从一份「机器学习检测SQL注入.zip」说起这条路到底能不能走通很多人第一次看到「机器学习检测SQL注入」这个标题第一反应是SQL注入不是早就有 WAF 规则、正则匹配、参数化查询兜底了吗为什么还要用机器学习我一开始也这么想直到在 DVWA、sqli-labs、pikachu 靶场里把各种绕过姿势跑了一遍——大小写混写、内联注释、编码变形、等价替换、时间盲注拆包——才发现传统规则库的维护成本高得离谱攻击者改一个字符规则就得跟着改一条。机器学习检测 SQL 注入的核心价值不是替代参数化查询而是在流量层做一层「语义异常兜底」把那些规则没覆盖、但统计特征明显偏离正常请求的样本捞出来。这份「机器学习检测SQL注入.zip」本质上是一个把 HTTP 请求文本转成特征、再喂给分类模型判断是否恶意的完整小项目。它适合三类人一是做安全开发、想给现有 WAF 加一层智能检测的工程师二是学机器学习、想找一个真实二分类场景练手的学生热搜里「机器学习期末」「机器学习项目」「python机器学习入门」这些词背后都是这批人三是做渗透测试、想理解防守方视角的从业者。它解决的不是「有没有漏洞」而是「这条请求像不像攻击」。读完你能自己搭一套从数据采集、特征工程、模型训练到在线推理的最小闭环也能清楚知道它在哪会翻车。2. 数据从哪来把 DVWA 和 sqli-labs 的请求变成训练集2.1 为什么不能直接用现成数据集网上能搜到一些 SQL 注入数据集但直接拿来训练往往效果很差原因有三个一是很多数据集是脱敏后的纯 payload 片段丢掉了 URL 编码、参数位置、Header 这些关键上下文二是正负样本分布和你的真实业务差太远靶场里的攻击流量密度远高于生产环境三是标注口径不统一有的把「含单引号」就算攻击有的要求必须能实际注入成功。我一般会自己在本地靶场造数据这样标签可控、分布可调也方便后续做增量。DVWA 和 sqli-labs 是最常见的两个靶场前者适合快速跑通流程后者关卡多、payload 类型全适合扩充样本多样性。pikachu 靶场里的 SQL 注入模块也可以补充一些变体。采集时不要只抓 payload要抓完整的 HTTP 请求行、Header、Body因为模型需要看到「参数出现在哪个位置、有没有被编码」。2.2 用 Python 采集并落盘请求样本下面这段脚本用 requests 访问靶场把正常请求和注入请求分别打标签存成 JSONL。注意靶场地址换成你自己的本地环境不要对着未授权目标跑。import requests import json import time # 正常请求样本参数是普通业务值 normal_cases [ {id: 1, name: alice}, {id: 2, name: bob}, {id: 10, name: charlie}, ] # 注入请求样本覆盖联合、布尔、时间、报错四类 inject_cases [ {id: 1 OR 11, name: x}, {id: 1 UNION SELECT 1,2,3--, name: x}, {id: 1 AND SLEEP(3), name: x}, {id: 1 AND extractvalue(1,concat(0x7e,version()))--, name: x}, ] def collect(base_url, cases, label, out_file): with open(out_file, a, encodingutf-8) as f: for c in cases: try: # 记录完整请求上下文而不是只存 payload resp requests.get(base_url, paramsc, timeout5) record { method: GET, url: base_url, params: c, status: resp.status_code, len: len(resp.text), label: label, # 1 恶意0 正常 } f.write(json.dumps(record, ensure_asciiFalse) \n) except Exception as e: print(skip, c, e) time.sleep(0.2) # 避免打爆靶场 collect(http://localhost/dvwa/vulnerabilities/sqli/, normal_cases, 0, dataset.jsonl) collect(http://localhost/dvwa/vulnerabilities/sqli/, inject_cases, 1, dataset.jsonl)这段代码的关键点在于params存的是原始字典后续特征工程可以自己决定怎么拼接和编码status和len是廉价但有效的辅助特征时间盲注往往会让响应变长或超时label用 0/1 而不是字符串方便直接喂给 scikit-learn。time.sleep(0.2)是血泪经验靶场虽然本地但并发太高会把 Apache 打挂采集中断反而更费时间。2.3 样本量与类别平衡的实操参数我一般会控制正常样本和恶意样本比例在 3:1 到 5:1 之间因为真实流量里攻击占比极低如果训练集里恶意样本太多模型会过度敏感误报率飙升。每个类别至少 500 条起步少于这个数交叉验证的方差会很大。采集时按 payload 类型分层联合查询、布尔盲注、时间盲注、报错注入、堆叠查询各占一定比例避免模型只学会识别某一种。提示采集脚本里不要写死靶场 IP用配置文件或环境变量传入方便换环境。数据集文件建议按日期分片比如dataset_20240101.jsonl后续做增量训练时好回溯。3. 特征工程把一条 HTTP 请求变成模型能吃的向量3.1 文本特征和统计特征怎么选SQL 注入检测的特征大致分两类一类是字符级/词级文本特征比如是否包含union、select、--、/*、单引号、分号另一类是统计特征比如参数长度、特殊字符占比、大小写切换次数、URL 编码比例、数字与字母比例。纯文本特征容易被绕过大小写、注释、编码纯统计特征又容易误报正常的长参数。我的做法是两者拼接让模型自己学权重。常见做法是用 TF-IDF 把参数值转成向量再拼接手工统计特征。TF-IDF 的ngram_range设成 (1,3)因为 SQL 关键字经常和符号组合出现比如union select、or 11。max_features控制在 5000 以内太大容易过拟合太小会丢信息。手工特征我一般保留 8 到 12 个太多会稀释文本特征的作用。3.2 用 scikit-learn 搭特征流水线下面这段代码把原始 JSONL 读进来做特征提取并输出特征矩阵。注意char_ratio这类函数要处理空字符串否则会除零。import json import numpy as np from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.pipeline import FeatureUnion def load_data(path): X_text, y [], [] with open(path, encodingutf-8) as f: for line in f: r json.loads(line) # 把参数字典拼成一段文本保留键和值 text .join(f{k}{v} for k, v in r[params].items()) X_text.append(text) y.append(r[label]) return X_text, np.array(y) def hand_features(text): length len(text) special sum(text.count(c) for c in \-;/*()) upper sum(1 for c in text if c.isupper()) digit sum(1 for c in text if c.isdigit()) return [ length, special / (length 1), upper / (length 1), digit / (length 1), text.count( ) / (length 1), ] X_text, y load_data(dataset.jsonl) # 文本特征字符级 n-gram对编码变形更鲁棒 tfidf TfidfVectorizer(analyzerchar, ngram_range(1, 3), max_features5000) # 手工统计特征单独算后面用 hstack 拼接 X_hand np.array([hand_features(t) for t in X_text]) X_tfidf tfidf.fit_transform(X_text).toarray() X np.hstack([X_tfidf, X_hand]) print(feature shape:, X.shape)这里用analyzerchar而不是默认的 word是因为 SQL 注入 payload 经常没有正常空格分词字符级 n-gram 能捕捉or、11、--这种片段。max_features5000是我在几千条样本上的经验值样本量上万时可以适当放大。手工特征里special / (length 1)用加一平滑避免除零upper / (length 1)能捕捉大小写混写绕过。拼接后的矩阵直接可以喂给逻辑回归或树模型。3.3 特征维度与训练速度的取舍字符级 TF-IDF 加手工特征后维度大概在 5000 到 6000 之间逻辑回归训练几秒就能完成随机森林会慢一些但通常几十秒内也能跑完。如果维度冲到几万训练时间会明显上升而且小样本下过拟合风险很大。我一般会先跑一版逻辑回归看基线再用随机森林或梯度提升树对比如果提升不明显就保留逻辑回归因为推理速度快、可解释性好线上部署成本低。注意TF-IDF 的fit只能在训练集上做验证集和测试集必须用同一个 vectorizer 做transform否则特征空间不一致评估结果会虚高。这是新手最容易翻车的地方之一。4. 模型训练与评估逻辑回归、随机森林怎么选、阈值怎么定4.1 三个基线模型的对比实验我一般会同时跑逻辑回归、随机森林、梯度提升树三个模型用同一份特征矩阵做 5 折交叉验证看准确率、召回率、F1 和 AUC。安全场景下召回率比准确率更重要因为漏掉一个攻击的代价远大于误报一个正常请求。但召回率不能无限拉高否则误报会把运维拖垮所以要看具体业务能接受多少误报。模型训练速度推理速度可解释性小样本表现逻辑回归快快强稳定随机森林中中中较好梯度提升树慢中弱容易过拟合从这张表能看出来如果样本量只有几千条逻辑回归往往是性价比最高的选择。随机森林适合特征里有大量非线性交互的情况比如编码变形和参数位置的组合。梯度提升树在样本量上万后再考虑否则调参成本高、收益不明显。4.2 训练代码与阈值调整下面这段代码用逻辑回归做基线输出混淆矩阵和不同阈值下的召回率。注意class_weightbalanced在类别不平衡时很有用但会拉高误报需要结合业务调。from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.metrics import confusion_matrix, roc_auc_score, recall_score X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.3, random_state42, stratifyy ) clf LogisticRegression(max_iter1000, class_weightbalanced) clf.fit(X_train, y_train) # 输出概率方便调阈值 proba clf.predict_proba(X_test)[:, 1] print(AUC:, roc_auc_score(y_test, proba)) for th in [0.3, 0.4, 0.5, 0.6, 0.7]: pred (proba th).astype(int) cm confusion_matrix(y_test, pred) rec recall_score(y_test, pred) print(fthreshold{th} recall{rec:.3f} cm{cm.tolist()})max_iter1000是因为字符级 TF-IDF 维度高默认的 100 次迭代经常不收敛。class_weightbalanced会自动按类别频率反比加权适合恶意样本少的情况。输出不同阈值下的混淆矩阵是为了让你看到「召回率提升换来多少误报」。我一般会把阈值定在误报可接受的前提下召回率最高的点而不是默认的 0.5。AUC 只反映排序能力不能直接当阈值用这点很多人会混淆。4.3 评估指标之外还要看什么除了 AUC 和召回率我还会看两个东西一是误报样本的具体内容如果误报集中在某类正常业务参数上说明特征或训练数据有偏二是模型在「未见过的绕过手法」上的表现比如训练时没有内联注释样本测试时加入/*!50000union*/看能不能检出。后者更接近真实对抗场景。如果条件允许做一次时间切分验证用早期数据训练用后期数据测试模拟真实上线后的分布漂移。提示不要用测试集反复调阈值那样测试集就变成了验证集。正确做法是切出训练集、验证集、测试集三份阈值在验证集上定测试集只跑一次。5. 避坑与排查那些让模型指标虚高、上线就翻车的细节5.1 数据泄漏同一条 payload 同时出现在训练和测试集现象交叉验证准确率 0.99上线后召回率不到 0.5。原因采集时同一条 payload 的变体被随机切分到了训练和测试两侧模型记住了具体字符串而不是学到模式。解决按 payload 模板或按采集批次做分组切分用GroupShuffleSplit而不是train_test_split确保同一来源的样本只出现在一侧。5.2 特征穿越用了响应长度做特征却在线拿不到现象离线评估很好在线推理时特征缺失导致报错或精度骤降。原因len(resp.text)这类特征依赖响应而在线检测往往在请求到达时就要判断拿不到响应。解决把特征分成「请求时可得的」和「响应后可得的」两组线上只用请求侧特征响应侧特征留给事后审计模型。5.3 编码不一致训练用原始文本线上传进来的是 URL 编码现象本地测试能检出union select线上同样的攻击却漏报。原因训练数据里参数是解码后的线上 WAF 传过来的是%75nion%20select字符级 n-gram 完全对不上。解决在特征工程前统一做一次解码或者把编码后的形态也加入训练数据让模型同时见过两种形态。5.4 类别极度不平衡下的指标幻觉现象正常样本 10 万条、恶意样本 200 条模型全预测正常准确率 99.8%。原因准确率在不平衡数据上没有意义。解决看召回率、F1、AUC 和 PR 曲线配合class_weight或过采样并且把误报数量换算成「每天多少条」来评估运维成本。5.5 模型更新后旧阈值失效现象重新训练模型后同样的 0.5 阈值误报突然暴涨。原因新模型的概率校准变了输出分布整体偏移。解决每次更新模型都重新在验证集上定阈值并保留一段时间的影子模式新旧模型并行跑对比后再切换。6. 进阶技巧用滑动窗口和在线学习让检测跟上绕过节奏模型训完不是终点。SQL 注入的绕过手法在变今天能检出的 payload下个月可能就被新变体绕过。我一般会加两层机制一是滑动窗口统计对同一个 IP 或同一个参数名在短时间内的请求做聚合特征比如「最近 60 秒内该参数出现特殊字符的次数」这能捕捉单条请求看起来正常、但连续请求异常的慢速注入二是在线学习把线上判定为高置信度恶意的样本自动加入训练池定期增量训练。滑动窗口的实现不复杂用一个字典记录(ip, param)到时间戳列表的映射每次请求时清理过期时间戳并计算统计量。下面是一个最小示例from collections import defaultdict import time window defaultdict(list) def sliding_features(key, nowNone, span60): now now or time.time() # 清理窗口外的记录 window[key] [t for t in window[key] if now - t span] window[key].append(now) count len(window[key]) # 请求频率和窗口内密度密度突增往往是自动化注入 return [count, count / span] # 模拟同一参数连续请求 for _ in range(5): print(sliding_features(192.168.1.10:id)) time.sleep(0.1)这段代码里span60是窗口大小按业务 QPS 调整QPS 高的系统可以缩短到 10 秒。count / span是密度特征比单纯计数更能反映突发。实际部署时这个字典要加过期清理否则内存会涨。在线学习部分我一般用partial_fit配合逻辑回归或者定期用新数据全量重训前者适合流式后者更稳定。要注意的是自动标注的样本可能有噪声最好加一个人工抽检环节否则错误会累积。验证新模型是否真的更好我习惯用「时间外测试」拿最近一周的真实流量做测试集对比新旧模型的召回和误报。如果新模型只在旧测试集上好看在时间外测试集上没提升那大概率是过拟合了。这个习惯帮我省过好几次「上线才发现翻车」的后悔药。做安全检测这件事指标好看不难难的是上线后还能稳住希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
