简介：在Web安全领域，传统WAF依赖正则和签名规则，面对编码混淆、变种攻击时容易漏报。机器学习通过分析HTTP请求的结构、内容与统计特征，能够学习正常流量与恶意流量的分布差异，从而识别未知攻击。特征工程是模型效果的核心，从URL熵、参数个数、特殊字符占比等维度提取有效信息，结合随机森林等算法训练分类器，可实现高召回率的攻击检测。基于FastAPI构建推理服务，将模型部署为实时检测API，能够在毫秒级响应并支持水平扩展。本文从项目实战角度，系统梳理了数据准备、特征提取、模型训练、阈值调优与线上部署的完整流程，为构建智能Web应用防火墙提供了可落地的参考方案。 上半年做了一件事：把基于机器学习的Web攻击检测系统从0到1完整撸了一遍，源码和配套的详细文档说明都已归档，文档整理成了Word版，里面包含需求说明、数据说明、特征说明、训练过程记录和部署手册。今天抽空把整个项目的核心思路和实战细节拆开聊聊，希望能给正在做Web安全、AI安全，或者准备相关毕业设计的同学一些参考。
这个系统解决的是传统WAF规则覆盖不住的长尾问题。规则引擎靠正则和签名匹配，遇到攻击payload稍微换个编码、加个注释符、拆成大小写混合就漏了；而机器学习模型不依赖固定签名，它学的是正常流量和攻击流量在统计分布上的差异，所以能抓到一些“没见过但行为模式类似”的请求。整套东西做下来，数据清洗和特征工程占了大概六成时间，真正训练模型反而很快。
1. 项目定位与整体设计思路
1.1 传统WAF漏报背后的核心痛点
先聊聊为什么需要机器学习来做Web攻击检测。传统WAF的核心是规则引擎，本质是一堆正则表达式和签名库，每个规则描述一种攻击特征。这种方式有很明显的天花板：
- 攻击者可以通过编码、大小写变换、注释符插入、URL编码二次编码等方式绕成正则匹配；
- 规则越写越严，正常业务请求的误报就越来越高，运营同学一天要处理几百条无效告警；
- 规则库需要人工持续维护，新攻击手法出来之后，必须等规则更新才能检测。
我在项目里拿了一批真实Nginx日志做过测试，传统规则引擎在SQL注入和XSS变种上的漏报率比较高，尤其是有参数编码和特殊字符混淆的请求。而机器学习模型只要特征做得足够细，能从请求长度分布、字符构成、信息熵、参数个数这些维度去区分正常请求和恶意请求，对“变异攻击”的容忍度明显更高。这套系统的定位不是替代WAF，而是做第二道检测引擎，规则引擎负责快速拦截确定恶意的请求，ML模型负责处理规则拿不准的部分。
1.2 技术选型：为什么用Scikit-learn搭检测引擎
技术栈上我选了Python 3.8 + Scikit-learn + FastAPI，没有上PyTorch或者TensorFlow。有些人一听到机器学习就默认要搞深度学习，但其实在这个场景里没必要。
Web攻击检测的核心输入是HTTP请求，特征维度可能就几十维，数据集量级通常在几万到几十万条。在这种规模和可解释性要求下，树模型和线性模型完全够用。随机森林和XGBoost都能输出特征重要性，安全运营同学可以明白“这个请求为什么被判恶意”，是URL熵太高还是参数长度异常。换成深度神经网络，性能未必差，但解释性很差，出了问题很难向业务方说明。
部署成本也要考虑。sklearn模型不需要GPU，一台2核4G的云主机就能跑，单条请求推理时间在1到3毫秒；FastAPI原生支持异步，自带Pydantic数据校验和OpenAPI文档，比Flask更适合做这种轻量级推理服务。
1.3 项目目录结构与文档内容规划
源码目录结构我建议这样划分，方便后续维护：
web_attack_detector/ ├── README.md ├── docs/ │ └── 详细设计说明.docx ├── data/ │ ├── raw/ # 原始日志和公开数据集 │ ├── processed/ # 清洗后的标准化样本 │ └── features/ # 特征化后的向量 ├── src/ │ ├── feature_extractor.py │ ├── train_model.py │ ├── predict_api.py │ └── utils.py ├── models/ │ ├── rf_model_v1.2.0.joblib │ └── feature_names.json └── tests/ └── test_api.py配套的Word详细文档我写了七章：项目背景、需求分析、数据说明、特征工程说明、模型训练与评估、接口部署说明、测试与维护。写文档最耗时的其实是特征工程说明那一章，因为后续排查线上误报时，唯一能依赖的就是特征定义是否清晰。每个特征叫什么、怎么算的、取值范围是什么，全部要写清楚，否则三个月后自己回来都看不懂当时为什么这么设计。
2. 数据集准备与特征工程：模型效果的半壁江山
2.1 数据集来源与清洗标注：别让脏数据毁掉整个模型
准备数据是整条链路里最枯燥但也最关键的环节。我最终用了公开数据集叠加自采日志的方式。
公开数据集主要用了CSIC 2010和CICIDS2017中的Web相关流量。CSIC 2010专门针对Web攻击，包含正常请求和注入、XSS、路径遍历等攻击请求，格式是HTTP请求原文，拿来练手很合适。CICIDS2017是更全面的流量数据集，可以从中抽取HTTP部分。这两份数据在安全社区都可以获取，网上搜名称就有。
自采日志这块，我拿自己的测试站点的Nginx访问日志补了一批正常流量。原始日志字段很多，但建模只需要关心的字段是：请求方法、URL路径、查询参数、请求体、User-Agent、状态码。真正建特征时，状态码和UA我暂时没用，因为攻击请求和正常请求在这两个字段上的区分度不稳定。
数据清洗有几件必须做的事：去重，去掉监控探针和健康检查产生的噪音请求，过滤掉超大响应（那是响应侧的问题，不是请求侧），把URL解码一次并统一大小写。数据标注是另一个坑。公开数据集自带标签还好，自采日志没有标签，我的处理方式是用开源的WAF规则集先跑一遍，把命中的标为恶意，剩下的大部分标为正常，然后人工抽检10%确认标注质量。标注有争议的样本直接剔除，宁缺毋滥。
从我整理完的样本看，训练集6万条，测试集1.5万条，恶意样本占比约12%。这个比例已经算比较接近真实线上情况了，真实场景里恶意流量通常连5%都不到。
2.2 特征提取方案：把HTTP请求变成模型看得懂的向量
特征工程是整个系统的灵魂。我的做法是提取三类特征，总共28维。
第一类是结构特征。包括请求方法（做One-Hot编码）、URL长度、请求总长度、参数个数、参数名最大长度、参数值最大长度、是否包含请求体。这类特征能区分大量自动化攻击脚本和正常浏览器请求，因为自动化脚本构造的URL往往比正常页面更长，参数更多。
第二类是内容特征。包括URL和请求体中是否包含可疑关键词，以及可疑关键词命中的个数。但这里要注意，不要简单用“是否包含select、union、script”这种布尔特征，攻击者一编码就绕过。更有效的是加上关键词变种统计，比如对URL做一次URL解码和一次HTML实体解码后再匹配，同时记录解码前后长度的变化值。
第三类是统计特征。这是最核心、最不容易被绕过的部分。包括URL中各字符类别的占比：数字占比、字母占比、特殊字符占比；连续字母最大长度；连续数字最大长度；URL字符串的信息熵；请求体信息熵；参数值中最长连续非字母数字子串的长度。正常URL的信息熵通常在3到4.5之间，而大量注入攻击的URL经过编码和特殊字符堆叠后，熵值会明显偏高。模型能学到这类分布差异，是它比正则强的地方。
最终特征列表整理成表格就是下面这样：
| 特征名 | 类型 | 说明 |
|---|---|---|
| method_GET / method_POST | 类别 | One-Hot编码 |
| url_length | 数值 | URL路径+查询串总长度 |
| param_count | 数值 | 查询参数个数 |
| param_max_len | 数值 | 参数值最大长度 |
| body_length | 数值 | 请求体长度 |
| special_char_ratio_url | 数值 | URL中特殊字符占比 |
| digit_ratio_url | 数值 | URL中数字占比 |
| url_entropy | 数值 | URL字符串信息熵 |
| body_entropy | 数值 | 请求体信息熵 |
| suspicious_keyword_hits | 数值 | 可疑关键词命中数 |
| decoded_len_diff | 数值 | URL解码前后长度差值 |
所有数值特征在训练前用StandardScaler做Z-score归一化。注意scaler只能在训练集上fit，然后同时用来转换训练集和测试集，这个细节极其重要，搞反了就是数据泄漏。
3. 核心模块实现：源码里最关键的三块
3.1 特征提取与持久化实现
特征提取模块是整个项目的地基。我把它封装成了一个独立的类FeatureExtractor，保证训练时和推理时走的是同一套代码，避免两边逻辑不一致。
import re import math from urllib.parse import urlparse, parse_qs class FeatureExtractor: def __init__(self): self.suspicious_keywords = re.compile( r"select|union|insert|drop|script|alert|eval|exec|" r"\.\./|/etc/passwd|base64|char\(|concat|0x", re.I ) self.url_decode_pattern = re.compile(r"(%[0-9a-fA-F]{2})+") def _entropy(self, s: str) -> float: if not s: return 0.0 prob = [float(s.count(c)) / len(s) for c in set(s)] return -sum(p * math.log2(p) for p in prob) def extract(self, method: str, url: str, body: str) -> list: parsed = urlparse(url) params = parse_qs(parsed.query, keep_blank_values=True) decoded_url = self.url_decode_pattern.sub(lambda m: "", url) features = [ 1.0 if method == "GET" else 0.0, 1.0 if method == "POST" else 0.0, len(url), len(params), max((len(v) for v in params.values()), default=0), len(body or ""), self._special_char_ratio(url), self._digit_ratio(url), self._entropy(url), self._entropy(body or ""), len(self.suspicious_keywords.findall(url + (body or ""))), abs(len(url) - len(decoded_url)), ] return features这段代码有几个细节。第一，正则一定要用预编译，不要每次extract的时候重新compile，不然后面做性能优化时会被这个拖死。第二，熵的计算直接用了Python自带的set和count，字符串长度在几千字符以内性能完全没问题。第三，suspicious_keywords匹配时把URL和body拼在一起，简单直接，虽然可能产生少量跨字段误匹配，但模型会自己学习权重，影响不大。实际项目里我还把feature_names.json保存了一份，记录每个下标对应的特征名，这是后面排查特征顺序错乱问题的关键。
3.2 模型训练Pipeline实现
训练脚本我写成了可复跑的形式，数据处理好之后，一条命令就能完成训练、评估和模型导出。
import joblib import pandas as pd from sklearn.model_selection import train_test_split from sklearn.preprocessing import StandardScaler from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report, confusion_matrix df = pd.read_csv("data/features/train_features.csv") X = df.drop("label", axis=1).values y = df["label"].values X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y ) scaler = StandardScaler().fit(X_train) X_train_scaled = scaler.transform(X_train) X_test_scaled = scaler.transform(X_test) clf = RandomForestClassifier( n_estimators=300, max_depth=20, min_samples_leaf=2, class_weight="balanced", n_jobs=-1, random_state=42, ) clf.fit(X_train_scaled, y_train) y_pred = clf.predict(X_test_scaled) print(classification_report(y_test, y_pred)) print(confusion_matrix(y_test, y_pred)) joblib.dump(clf, "models/rf_model_v1.2.0.joblib") joblib.dump(scaler, "models/scaler_v1.2.0.joblib")train_test_split里stratify=y这个参数我特意加上了，它可以保证切分后训练集和测试集里恶意样本的比例一致。样本不均衡的场景下，不做分层抽样，很可能切出来某个子集恶意样本特别少，模型评估结果就会很不稳定。
保存模型时我用了joblib而不是pickle。joblib对numpy数组和大量参数的模型对象序列化效率更高，加载速度也更快。模型文件名带版本号是习惯，v1.2.0这样的命名方便回滚。
3.3 在线推理接口实现（FastAPI实战）
模型训练好了，最终要暴露成HTTP接口给业务侧调用。FastAPI写的推理服务很简洁。
from fastapi import FastAPI, HTTPException from pydantic import BaseModel import joblib import numpy as np from feature_extractor import FeatureExtractor app = FastAPI() class DetectRequest(BaseModel): method: str url: str body: str = "" class DetectResponse(BaseModel): is_attack: bool attack_score: float features: list extractor = FeatureExtractor() clf = joblib.load("models/rf_model_v1.2.0.joblib") scaler = joblib.load("models/scaler_v1.2.0.joblib") @app.post("/api/detect", response_model=DetectResponse) async def detect(req: DetectRequest): try: features = extractor.extract(req.method, req.url, req.body) features_scaled = scaler.transform([features]) score = clf.predict_proba(features_scaled)[0][1] return DetectResponse( is_attack=bool(score >= 0.3), attack_score=float(score), features=features, ) except Exception as e: raise HTTPException(status_code=400, detail=str(e))有几个实践细节想强调。模型和scaler一定要在模块加载时就初始化，也就是模块顶部的全局变量，不要在请求处理函数里反复加载，磁盘IO和反序列化的开销会直接拖垮接口性能。预测分数threshold我设成0.3而不是默认的0.5，目的是提高召回率，安全场景下宁可多一点误报，也不能漏掉攻击，这个阈值怎么来的，下一章详细说。
Pydantic的BaseModel帮我们把输入格式校验做了，method、url、body三个字段缺哪个都会直接返回400错误，省了很多手工校验代码。
4. 模型训练与调参实录
4.1 多算法对比实验：别一上来就无脑XGBoost
同一个特征集上，我对比了四种常见机器学习算法：逻辑回归、随机森林、XGBoost、RBF核的SVM。评估指标不是只看准确率，重点看精确率、召回率、F1和推理耗时。
| 算法 | 精确率 | 召回率 | F1 | 单条推理耗时(ms) |
|---|---|---|---|---|
| Logistic Regression | 0.93 | 0.88 | 0.90 | 0.2 |
| Random Forest | 0.96 | 0.94 | 0.95 | 1.8 |
| XGBoost | 0.97 | 0.95 | 0.96 | 2.5 |
| SVM(RBF) | 0.95 | 0.90 | 0.92 | 3.1 |
逻辑回归胜在快，但召回率明显不够，只能用来做baseline。SVM在这个数据量级上没有优势，训练耗时还特别长。随机森林和XGBoost效果接近，但我最终选了随机森林，原因很简单：它不需要太多调参就能达到稳定效果，对类别不均衡的鲁棒性更好，特征重要性也很直观，适合第一个上线版本。
从随机森林输出的特征重要性看，排在前五的分别是URL信息熵、参数个数、参数值最大长度、URL特殊字符占比、请求体长度。这印证了做特征时的一个判断：结构化统计特征比关键词匹配特征更能帮助模型区分攻击流量。
4.2 阈值调整与样本不均衡处理：召回率优先的调参思路
安全检测场景和推荐系统不一样。推荐系统预测错了顶多推荐不精准，攻击检测漏掉一个请求可能造成实际损失。所以我在调参上做了两个处理。
第一个是样本不均衡。恶意样本只有12%，如果不处理，模型会倾向于把所有样本都预测为正常，准确率也可能很高，但没有任何意义。RandomForest里直接用class_weight="balanced"是最省事的方法，它会自动加大少数类的权重。
第二个是阈值调整。模型默认用0.5作为正负样本分界线，但在类别不均衡时这个阈值并不合适。我的做法是用验证集跑出precision_recall_curve，然后选一个满足“召回率>=0.95”时精确率最高的阈值。实测下来阈值0.3时，召回率能从0.90提高到0.95，精确率只下降了几个点，完全值得。阈值0.2时召回率能到0.98，但误报会明显变多，线上手动处理不过来。
这里也提醒一下：千万不要只看accuracy。在9:1的类别分布下，模型把所有样本都判为正常都有90%的准确率，但这个模型一点用都没有。一定要看混淆矩阵和PR曲线。
5. 落地部署：从离线脚本到实时检测服务
5.1 服务化部署要点：启动加载模型与并发优化
推理服务写完之后，部署上线还有一堆工程细节。我的部署方案是gunicorn + uvicorn worker跑FastAPI，启动命令大致是这样的：
gunicorn -w 4 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000 predict_api:appworker数我设成了4，机器是4核CPU。sklearn的predict是CPU密集型操作，理论上每个worker是独立进程，天然利用多核。worker数不是越多越好，因为进程间切换也有成本，2倍CPU核数是我习惯的起点，压测后再微调。
上线前一定要做一次压测。我压测时发现单worker的QPS大约在150左右，4个worker合计500多一点，延迟p95在8到12毫秒，完全满足中小流量的检测需求。如果流量更大，部署多副本加负载均衡就行，服务是无状态的，扩展非常方便。
5.2 性能与稳定性监控：推理耗时、日志和模型版本管理
服务上线之后，稳定性比功能本身更重要。我做了一个简单的性能中间件，记录每次请求的处理耗时，超过阈值的打印警告日志。同时把每次请求的检测结果、特征向量、模型打分一起写进JSON日志。这个设计后来救了我很多次，线上误报排查全靠这些历史日志。比如运营同学说“某个请求被判攻击了”，我直接grep日志，把这个请求的特征和得分拉出来，和训练集里的正常样本对比，很快就能定位问题。
模型版本管理也要认真做。模型文件必须带版本号，服务启动时从配置文件读取模型路径，这样发布新模型时不需要改代码，只需要改配置然后重启服务。历史模型文件保留至少三个版本，方便出问题时快速回滚。
6. 常见问题与排查技巧实录
6.1 训练和预测特征不一致，模型等于白训
这是最常见也最致命的问题。训练时特征和推理时特征顺序不一致，或者特征含义不一致，模型还在跑，但结果已经废了。我踩过一次坑：训练代码里自己手拼了一个特征列表，线上推理时又写了一个函数，两个函数的特征顺序差了两位，结果线上模型判别能力暴跌。
现在我强制要求用同一个FeatureExtractor类跑训练和推理，并且在服务启动时加载feature_names.json做一次校验，比对文件里的特征名列表和模型训练时的记录是否完全一致。排查时还有一个技巧：拿训练集中的一条样本，分别走训练特征流程和线上特征流程，打印输出向量对比，任何一位不同都说明哪里有问题。
6.2 误报率偏高怎么查
误报的排查思路其实就三步。第一步，把线上误报的请求收集起来，看它们的模型打分分布和被命中的特征。第二步，对比误报样本和训练集中的正常样本，看差异在哪里，通常会发现线上有些合法的长参数、带特殊字符的业务请求，训练集里根本没有。第三步，补充同类正常样本到训练集，或者调整阈值。如果补充数据不方便，可以在规则层加白名单，但要非常克制，白名单条件尽量严格，否则攻击者很容易伪装成白名单请求绕过检测。
6.3 实测踩坑速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 模型全部预测为正常 | 训练集没有恶意样本或class_weight未设置 | 检查标签分布，设置class_weight |
| API偶发超时 | 特征提取里正则表达式回溯 | 改用预编译正则，限制输入长度 |
| 线上结果和压测差距大 | 阈值配置不一致 | 阈值统一从配置文件读取 |
| 模型文件加载失败 | joblib跨版本不兼容 | 训练和部署环境锁定sklearn版本 |
| 请求体超大导致延迟暴增 | 没有限制body大小 | 在FastAPI层限制请求体重，超过直接返回413 |
| 特征向量为全零 | 输入字段为空或解析逻辑异常 | 增加输入校验和特征值范围检查 |
另外还有一个常见问题，字符编码。HTTP请求里经常有各种编码，URL编码、HTML实体编码、Unicode编码混合在一起。如果特征提取前不做统一标准化，同一个攻击的不同编码形态在特征空间里会离得很远，模型就很难学到一个统一的边界。我的做法是：所有URL和body在进模型之前先做一次URL解码和一次HTML实体解码，再把这两个解码结果同时交给特征提取，让模型自己决定用哪部分的信息更有效。
整套系统跑下来，我的一个核心体会是：做这类项目，最大的难点不在模型，而在数据准确性和工程稳定性。模型高分并不难拿到，难的是把数据处理干净、特征定义清晰、部署后能稳定运行。如果对这套基于机器学习的Web攻击检测系统还不太熟悉，建议先按源码里的说明跑通离线批次检测，把所有样本过一遍模型，看看误报和漏报长什么样，再考虑上实时接口。等对整个流程心里有数了，再谈调优和扩展也不迟。
本文还有配套的精品资源，点击获取
