简介：自动化Web应用漏洞扫描与安全检测的完整项目资源，基于Python与Django框架开发，面向网络安全测试人员、Web开发者和信息安全学习者。系统内置爬虫引擎，可遍历Web应用页面与链接模拟攻击行为，支持静态页面与动态交互应用；自定义规则库支持漏洞规则更新扩展与个性化配置，实现深度安全扫描与风险评估。资源包共202个文件，大小1.16MB。核心逻辑集中在118个Python源码文件中，涵盖爬虫引擎、规则匹配与扫描调度模块；20个HTML页面与JS、CSS文件构成本地可视化操作界面，便于管理扫描任务与查看报告；SQL文件用于规则库与扫描记录存储；另附使用说明DOC文档、Web shell字典及部署配置脚本。目前已有91人浏览学习。通过该项目可掌握Django Web应用架构、爬虫遍历策略、漏洞规则设计等核心思路，获得可直接运行的扫描工具源码和完整目录结构，适合需要构建自有安全检测体系或深入研究Web渗透自动化流程的读者。

1. 自建Web漏洞扫描系统的第一性思考：为什么不直接用现成的AWVS和ZAP

很多团队的自动化漏洞扫描是从现成工具开始的。AWVS、Burp、ZAP覆盖OWASP Top 10的常规漏洞，文档多、社区大，但一旦目标换成本团队自己写的业务系统，问题就出现了：公开扫描器把带租户ID的接口误判成越权漏洞，报了一大堆，而真正存在的支付金额篡改、水平越权、逻辑绕过却一个都没测出来。这也是我后来坚持做基于Python与Django构建的自动化Web应用漏洞扫描与安全检测系统的原因——它的价值不在重新发明检测算法，而在于用爬虫引擎接管全站URL采集，用自定义规则库把团队踩过的业务漏洞特征沉淀成可复现的检测逻辑，再借Django的ORM、Admin和Celery把扫描任务、结果入库和报告输出串成一条完整流水线。这套方案适合需要把安全检测内建到研发流程的后端团队和安全测试人员，也适合拿它做深度扫描实验的进阶开发者。

2. Django工程骨架与任务调度：三张表、一个Celery队列串起扫描生命周期

开始搭这套系统时，我没有先写检测器，而是先把Django工程骨架立住。常见做法是把扫描任务的生命周期放到数据库里，让安全测试人员通过Django Admin直接盯任务状态，而不需要写SQL去查。Django在这套系统里承担的不只是Web展示层，而是整个扫描任务的中枢：ORM保存目标站点、扫描任务、漏洞结果三块核心数据；Admin后台提供可视化的任务管理和结果筛选；Celery负责把耗时的扫描流程切成异步任务。Django项目实战新手最容易犯的毛病是把扫描逻辑直接怼进视图函数里，点一次扫描页面卡住几十秒，看起来像服务挂了，生产环境根本没法用。

2.1 为什么是Django：ORM、Admin和后端生态刚好覆盖扫描器的三个痛点

先说选型逻辑。扫描器最重的三件事是任务状态管理、结果持久化、规则配置维护，Django在这三块都有现成答案。ORM让你用Python对象操作Target、ScanTask、VulnResult三张表，不用手写SQL拼接；Admin基于模型注册自动生成增删改查界面，安全测试人员能自己调整目标配置、查看漏洞证据，不用每次找开发改数据库；第三方库生态里Celery做异步任务、DRF写内部API、Django模板渲染PDF报告，都是成熟方案。相比之下，用Flask或者FastAPI也能做，但任务调度、后台管理、模型迁移这些能力都要重新组装，时间成本高出不少。我的建议很直接：如果不是想练框架，就用Django把这块省下来的时间留给规则库和检测器。

2.2 定义三张核心表：Target、ScanTask、VulnResult

任务模型是整个系统的地基。Target表存扫描目标的基本信息和登录态；ScanTask表记录一次扫描的配置和生命周期；VulnResult表存检测器命中的每一条漏洞证据。字段设计上要提前想清楚两个问题：一次扫描会产生海量检测结果，关联查询会非常频繁；任务状态会被Celery worker并发更新，状态字段要尽量简单。

from django.db import models class Target(models.Model): base_url = models.URLField(unique=True, help_text="入口地址") name = models.CharField(max_length=128) scope_domain = models.CharField(max_length=255, help_text="只允许爬虫在该域名内抓取") auth_cookie = models.TextField(blank=True, help_text="登录态Cookie，发起扫描前从浏览器复制") created_at = models.DateTimeField(auto_now_add=True) class Meta: db_table = "scan_target" class ScanTask(models.Model): target = models.ForeignKey(Target, on_delete=models.CASCADE, related_name="tasks") status = models.CharField(max_length=16, default="pending") depth = models.PositiveIntegerField(default=3, help_text="爬虫最大爬取深度") max_pages = models.PositiveIntegerField(default=500) rate_limit = models.FloatField(default=0.5, help_text="每次HTTP请求之间的间隔(秒)") started_at = models.DateTimeField(null=True) finished_at = models.DateTimeField(null=True) class Meta: db_table = "scan_task" indexes = [models.Index(fields=["status"])] class VulnResult(models.Model): task = models.ForeignKey(ScanTask, on_delete=models.CASCADE, related_name="findings") rule_id = models.CharField(max_length=64) vuln_type = models.CharField(max_length=64) risk_level = models.CharField( max_length=8, choices=[("low", "低"), ("medium", "中"), ("high", "高"), ("critical", "严重")] ) url = models.TextField() parameter = models.CharField(max_length=128, blank=True) evidence = models.TextField(help_text="命中的原始响应片段或请求响应差值") created_at = models.DateTimeField(auto_now_add=True) class Meta: db_table = "scan_vuln_result"

三个字段细节值得说明。status用短字符串而不是Django的choices枚举，是因为Celery worker会频繁动态写入状态，纯字符串在迁移和序列化时更省事；auth_cookie放在Target表而不是ScanTask表，是为了同一目标多次扫描能复用登录态，不用每次扫描都重新从浏览器复制Cookie；VulnResult的evidence字段保存的是命中的原始响应片段或长度差数值，后续人工复核时不需要重新发请求，直接看证据就能判断真伪。表名统一加scan_前缀，避免和其他业务模型混在一起。

2.3 用Celery把扫描管线改成异步任务，别阻塞Django请求线程

扫描流水线是典型的IO密集长任务：爬虫要发大量HTTP请求，检测器要逐个参数测试payload，一次全站扫描轻松跑十几分钟。如果同步执行，用户点击扫描按钮后浏览器连接会一直挂着，代理层超时不说，Django进程也会被占满。所以我用Celery把整条管线包成一个异步任务，web进程只负责把task_id写库并提交给worker。

from celery import shared_task from .models import ScanTask, VulnResult from .spider import WebSpider from .rule_engine import RuleEngine @shared_task(bind=True, time_limit=3600, soft_time_limit=3000) def run_scan_pipeline(self, task_id): task = ScanTask.objects.select_related("target").get(id=task_id) task.status = "scanning" task.save() results = [] try: target = task.target spider = WebSpider( seed_url=target.base_url, depth=task.depth, max_pages=task.max_pages, delay=task.rate_limit, cookie=target.auth_cookie, scope_domain=target.scope_domain, ) urls = spider.crawl() engine = RuleEngine() for url in urls: for vuln in engine.scan_url(url, task): results.append(vuln) VulnResult.objects.bulk_create(results, batch_size=200) except Exception as exc: task.status = "failed" task.save() return {"task_id": task_id, "status": "failed", "error": str(exc)} task.status = "done" task.save() return {"task_id": task_id, "status": "done", "findings": len(results)} def launch_scan(task_id): async_result = run_scan_pipeline.delay(task_id) return async_result.id

这里有个关键点：results列表在try之前初始化，避免异常分支里访问未定义变量。任务状态的更新不在except里做一次就结束，而是依赖每次状态变更都落库，这样Admin页面才能实时刷新出pending、scanning、done、failed的完整轨迹。time_limit和soft_time_limit是一对参数，前者到时间硬杀进程，后者给任务额外的时间做资源清理。VulnResult用bulk_create一次性写入而不是循环save，是因为扫描结果数量可能上千条，逐条插入会产生上千次SQL往返，batch_size=200是比较合适的分批大小。launch_scan函数返回AsyncResult对象的id，web层可以把它存到ScanTask表里，方便后续轮询。

3. 爬虫引擎设计与站点采集：URL归一化、表单解析与登录态注入

爬虫引擎决定了扫描器能看到什么。检测器再强，爬虫漏掉一条URL，那上面的漏洞就等于不存在。我在设计爬虫时踩过不少次坑，最深的一点是：爬虫不是把网页上所有链接都抓一遍那么简单，而是要稳定地产出一份带参数的请求清单，让后面的检测器能针对每个参数做注入测试。这份请求清单的质量，直接决定整个漏洞扫描系统的检出率，所以这一章我会把爬虫的URL归一化、表单解析和登录取证讲透。这里用的Python爬虫方案是最常见的requests加BeautifulSoup，足以覆盖绝大多数服务端渲染的传统业务系统。

3.1 URL归一化与去重：把同一个页面的五种写法合并成一条请求

同一个页面在网站源码里可能有五种不同的URL写法：带不带www、http还是https、query参数顺序不同、末尾多了锚点、跟踪参数utm_source每次都不一样。如果不做归一化，爬虫会把它们当成五个页面去抓，既浪费请求额度，又让检测器重复劳动。我的做法是在URL进入去重集合之前强制做两步处理：去掉fragment，再对query参数按key排序后重新拼接。

import time from collections import deque from urllib.parse import urljoin, urlparse, parse_qsl, urlencode import requests from bs4 import BeautifulSoup class WebSpider: def __init__(self, seed_url, depth=3, max_pages=500, delay=0.5, cookie=None, scope_domain=""): self.seed_url = seed_url self.depth = depth self.max_pages = max_pages self.delay = delay self.scope_domain = scope_domain self.session = requests.Session() self.session.headers.update({ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" }) if cookie: self.session.headers["Cookie"] = cookie self.seen = set() def normalize_url(self, url): url = url.split("#")[0] parsed = urlparse(url) params = sorted(parse_qsl(parsed.query, keep_blank_values=True)) normalized_query = urlencode(params) return parsed._replace(query=normalized_query).geturl() def in_scope(self, url): host = urlparse(url).netloc or "" return host == self.scope_domain or host.endswith("." + self.scope_domain) def crawl(self): queue = deque([(self.seed_url, 0)]) collected = [] while queue and len(collected) < self.max_pages: raw_url, level = queue.popleft() url = self.normalize_url(raw_url) if url in self.seen: continue if level > self.depth: continue try: resp = self.session.get(url, timeout=8, allow_redirects=True) except requests.RequestException: continue self.seen.add(url) collected.append(url) soup = BeautifulSoup(resp.text, "html.parser") for a in soup.find_all("a", href=True): next_url = urljoin(url, a["href"].strip()) if self.in_scope(next_url): queue.append((next_url, level + 1)) time.sleep(self.delay) return collected

normalize_url是这套爬虫里最值得复用的函数。把锚点去掉是因为页面内容不因锚点改变；query参数排序是关键，同一个接口用"id=1&type=2"和"type=2&id=1"两种顺序访问，页面内容完全一样，不排序就会重复爬。in_scope用域名后缀匹配来限制范围，防止爬到外链CDN或第三方统计站点。队列用deque而不是list，原因是list的pop(0)是O(n)复杂度，页面多时会明显变慢，deque的popleft是O(1)。每抓一个响应sleep一次，delay控制对目标站点的请求频率，0.5秒是保守默认值，内测环境可以降到0.1秒，生产站点建议不低于1秒。

3.2 表单参数与Cookie注入：让爬虫把手伸到登录态后面的页面

服务端渲染的网站里，真正有价值的漏洞往往不在静态链接里，而在搜索框、筛选条件、数据提交表单这些带参数的请求中。爬虫必须解析页面里的form标签，把action、method、字段名都提取出来，不然检测器连参数名都拿不到，注入测试无从谈起。这里给出提取表单的代码片段，它和crawl方法配合使用，把每个页面的表单信息挂到对应的请求上下文里。

def extract_form_actions(self, soup, base_url): actions = [] for form in soup.find_all("form"): action = form.get("action") or base_url method = form.get("method", "get").lower() fields = [] for inp in form.find_all(["input", "textarea", "select"]): name = inp.get("name") if name: fields.append((name, inp.get("value") or "")) actions.append({ "action": urljoin(base_url, action), "method": method, "fields": fields, }) return actions

form的action经常写相对路径，必须用urljoin补全成绝对URL。fields里同时保存name和默认value，这个默认值很重要，检测器构造payload时要把原默认值替换掉而不是直接追加参数，否则有些后端接口会因缺少必填参数直接返回400，连测试请求都到达不了业务逻辑。至于登录态后的页面，一种常见做法是让用户把浏览器里的Cookie复制到Target表的auth_cookie字段，爬虫启动时把Cookie塞进Session的Header里，后续所有请求都带登录态访问。对纯JS渲染的现代前端，requests拿不到渲染后的DOM，生产环境我一般会预留一个Playwright爬虫开关，只在这种模式下启用，代价是抓取速度慢很多，适合对重点目标做补充采集。

3.3 爬虫和检测器的数据契约：URL队列里到底要放什么字段

爬虫输出的不能只是一堆URL字符串，检测器需要知道每个请求用什么方法、带哪些参数、以及参数的可注入点在哪里。我在这套系统里定义了一个RequestContext数据类，作为爬虫引擎和规则引擎之间的数据契约：

from dataclasses import dataclass from typing import Dict, List @dataclass class RequestContext: url: str method: str params: Dict[str, str] headers: Dict[str, str] source: str # link / form / js

params是字典类型，key是参数名，value是原始值。检测器遍历这个字典时，把每个value替换成payload去发起测试请求，替换而不是追加这点很关键，前面已经提过。source字段用来记录这个URL是普通链接还是表单提交，后续生成报告时能区分漏洞入口类型。这套契约设计好之后，爬虫和检测器就可以分开演进：爬虫只管把RequestContext填满，检测器只管消费它，互不干扰。我见过一些团队把URL列表和参数信息散落在不同的全局变量里，规则引擎越写越乱，最后连一个参数对应哪个页面都查不清楚，所以一开始就定好数据契约能省掉大量后期返工。

4. 自定义规则库与匹配器：从YAML规则到SQL注入、XSS检测的落地路径

规则库是整个系统区别于现成扫描器的核心卖点。现成工具用的规则是通用的，能扫出教科书式漏洞，但扫不出你们团队代码里特有的那种写法和历史遗留问题。自定义规则库解决的就是这个问题：把已知的漏洞模式沉淀成结构化规则，改一条规则不需要改Python代码，加一条新规则不需要重启服务。规则库我用YAML文件管理，原因很直接：YAML天然支持注释，git diff能看到每次规则变更的上下文，评审规则变更就像评审代码一样。这段实操我会拆成规则结构设计、匹配器分层、热加载三个部分，覆盖从写规则到上线生效的完整路径。

4.1 规则结构设计：规则ID、风险等级、响应指纹与确认载荷

一条规则要能独立回答四个问题：漏洞是什么、风险多高、怎么初步判断、怎么确认。我把这四个维度映射到YAML结构上，用rule_id做唯一标识，用risk定处置优先级，用match定义响应指纹正则，用confirm定义二次确认的参数和阈值范围。写规则的人不需要懂Python，只要会正则和了解业务漏洞特征就行。

rules: - id: RULE-SQLI-001 name: SQL报错注入检测 risk: high match: type: response_regex pattern: "SQL syntax.*MySQL|Warning.*mysql_|ORA-[0-9]{5}" confirm: send_payloads: true payloads: - "' AND 1=1-- -" - "' AND 1=2-- -" diff_threshold: 20 - id: RULE-XSS-001 name: 存储型XSS回显检测 risk: high match: type: response_regex pattern: "<script>|onerror=|<img src=x" confirm: send_payloads: true payloads: - "<script>alert(1)</script>" - "\"><img src=x onerror=alert(1)>" diff_threshold: 10

这里有个容易忽略的设计细节：match和confirm是两个独立阶段，match阶段的正则负责粗筛，confirm阶段才真正发送payload。规则文件里的payload数量控制在2到4个，多了会放大请求量，少了可能漏掉特定过滤逻辑下的绕过写法。diff_threshold表示确认阶段响应长度差的阈值，20字节是个相对保守的数值，能过滤掉大部分正常页面波动。risk字段决定漏洞在报告里的排序和告警级别，critical类规则一定要有confirm阶段，否则误报会把真正的高危漏洞淹没。

4.2 匹配器分两层跑：先从响应正则粗筛，再发送确认请求降误报

规则引擎的执行顺序值得写清楚。对每个RequestContext，先按match阶段的正则扫描响应体，命中的才进入confirm阶段，这样可以避免对每一个参数都发payload产生的大量无关请求。写过布尔盲注爆破Python脚本的人都知道，判断命中的关键不在响应里有没有"error"字样，而在响应长度差和回显特征是否随payload变化，所以confirm阶段我用的正是这一套逻辑。

import re import yaml class RuleEngine: def __init__(self, rules_path="rules.yaml"): self.rules = self._load(rules_path) def _load(self, path): with open(path, encoding="utf-8") as f: return yaml.safe_load(f)["rules"] def scan_url(self, ctx): hits = [] for rule in self.rules: matcher = rule["match"] if re.search(matcher["pattern"], ctx.response_text, re.IGNORECASE): confirmed = self._confirm(rule, ctx) if confirmed: hits.append(confirmed) return hits def _confirm(self, rule, ctx): payloads = rule.get("confirm", {}).get("payloads", []) if not payloads: return {"rule_id": rule["id"], "evidence": ctx.response_text[:200]} for param_name, param_value in ctx.params.items(): base_len = len(ctx.response_text) for payload in payloads: test_params = dict(ctx.params) test_params[param_name] = payload resp = ctx.session.get(ctx.url, params=test_params, timeout=8) diff = abs(len(resp.text) - base_len) if diff > rule["confirm"].get("diff_threshold", 20): return { "rule_id": rule["id"], "evidence": f"{param_name} 注入后响应长度变化 {diff}", } return None

这个长度差判断的阈值需要针对业务页面调参。带随机验证码或动态时间的页面，响应长度本身波动就很大，固定20字节不够稳，我一般会先把阈值调到50再观察误报情况。confirm阶段最大的坑是它本身会产生攻击性请求，所以在payload设计上要克制，不要用能改库写数据的句子，只做无害的布尔判断，比如and 1=2会让SQL结果为空集，响应长度自然变短，这正是判断漏洞存在的依据。RuleEngine加载规则文件时用了utf-8编码，Windows环境跑YAML带中文注释时经常因为编码问题翻车，这个细节建议保持。

4.3 规则热加载与优先级：改规则不该让整个扫描系统重启

规则文件改一次就重启一次服务，规则作者会非常抵触，频率高的时候一天要重启几十次。我做了个简单的热加载模块，用文件修改时间mtime做变更检测，间隔3秒扫一次，比watchdog轻量且不依赖额外的系统库。规则文件一更新，engine里的规则列表自动替换，正在跑的任务继续用旧规则，新任务立即用新规则，不会产生规则集不一致的问题。

import os import time class RuleHotReload: def __init__(self, engine, rules_path, interval=3): self.engine = engine self.path = rules_path self.interval = interval self.last_mtime = os.path.getmtime(rules_path) def watch(self): while True: time.sleep(self.interval) try: mtime = os.path.getmtime(self.path) except OSError: continue if mtime != self.last_mtime: self.last_mtime = mtime self.engine.rules = self.engine._load(self.path)

热加载之外，规则优先级也要有约定。我习惯在规则文件里预留一个enabled字段和override字段，enabled控制规则是否参与本次扫描，override用来在同类型规则冲突时指定高优先级规则覆盖低优先级规则。热加载的轮询间隔不建议小于2秒，否则频繁读写磁盘会造成无谓的IO开销。规则热加载上线后，团队里测试人员自己就能调整规则，不需要开发介入，这也是自定义规则库这项设计带来的最大协作效率提升。

5. 避坑记录：扫描系统上线后最常见的5个翻车现场

这套系统从开发到稳定跑了三个多月，真正的问题不是算法写不出来，而是各种看起来不起眼的工程细节把扫描结果变成一堆废纸。这一章我把遇到过的典型坑按现象、原因、解决的格式整理出来，每条都是花时间换来的血泪经验。这些问题不解决，扫描系统就是个大号的噪声发生器，团队看几周报警就会彻底失去信任。

5.1 现象：爬虫把登出接口扫了一遍，整个会话被打回未登录态

一次目标系统扫描中，爬虫爬到/logout链接并发送请求，之后所有请求都返回302跳转到登录页，检测器拿到的全是空壳页面，扫描报告一片空白，看起来像系统没工作。原因很简单：爬虫不区分会改变会话状态的URL，登出接口对于扫描器来说是"高危动作"。解决方式是在爬虫层内置一个session_killer正则列表，匹配logout、signout、logoff、action=logout这类关键词，命中后直接丢弃不加入请求队列。同时给Target表加一个自定义排除规则字段，允许安全测试人员针对特定系统追加黑名单URL。

SESSION_KILLER_PATTERNS = [ r"logout", r"signout", r"logoff", r"action=logout", ] def is_session_killer(self, url): return any(re.search(pattern, url, re.IGNORECASE) for pattern in SESSION_KILLER_PATTERNS)

这个判断要在normalize_url之后、in_scope判定之后执行，顺序反了会把一些外链的logout也纳入考虑范围。排查这类问题时先看爬虫采集的URL清单里有没有登出相关地址，如果有，就是这一步没做好。

5.2 现象：探测请求没有熔断，把内测环境打到CPU告警

默认rate_limit设为0.5秒，看着很安全，但检测器对每个参数发送多条payload，并发任务一多，同一时间窗口的请求量直接翻几倍，一台8核16G的内测服务器被打到CPU告警。原因不是单次请求频率太高，而是缺少全局的速率控制和熔断机制。解决方式是两层设防：一是给每个目标配每分钟请求数上限，用Redis计数器实现滑动窗口；二是在检测器里统计连续失败次数，连续5次请求超时或连接异常就触发熔断，暂停该目标扫描30秒后自动恢复。

class RateLimiter: def __init__(self, redis_client, domain, max_requests_per_minute=120): self.redis = redis_client self.domain = domain self.limit = max_requests_per_minute def allow(self): key = f"ratelimit:{self.domain}" count = self.redis.incr(key) if count == 1: self.redis.expire(key, 60) return count <= self.limit

熔断阈值要留出余量，不能卡着上限跑，否则一次网络抖动就会触发大面积熔断，扫描任务全部失败。排查这类问题时首先要看worker日志里有没有大量timeout异常，如果有，优先调低全局速率，再审计规则里的payload数量。

5.3 现象：响应体里出现"error"就报警，误报率直奔90%

最初写的规则匹配"error|exception|warning"关键词，结果一天报了400多条漏洞，人工复核发现证据全是页面里的正常业务文案，比如"Please enter your error code"。原因很直接：只做了响应体正则匹配，没有做状态码和回显特征的二次确认。解决方式是把这类弱规则全部降级为low级别，并且强制要求配置confirm阶段才能生效。现在判断一个页面是否真正报错，我先看状态码是否在500到599区间，再在响应体里找SQL片段、Python traceback、Java异常类名这些技术特征，而不是找"error"这个单词。

def is_real_error_response(resp): if resp.status_code < 500: return False error_signatures = [ r"Traceback \(most recent call last\)", r"java\.lang\.[A-Za-z]+Exception", r"SQLSTATE\[[0-9]+\]", r"Warning:\s+\w+", ] return any(re.search(pattern, resp.text, re.IGNORECASE) for pattern in error_signatures)

这条经验的核心是：正则匹配响应词面是第一步，状态码和技术堆栈特征才是分水岭。排查误报时把命中的证据拿出来看，如果evidence里只有一句正常文案，说明confirm阶段没有生效。

5.4 现象：任务状态卡在RUNNING，扫描结果变成黑匣子

扫描任务在Admin后台一直显示scanning，连续几小时不动，worker日志里没有任何报错。原因是Celery任务里状态更新只写在try的成功和异常分支，但worker被系统OOM杀掉时，既没有正常返回也没有抛异常，任务状态永远停在最后一次save的scanning。解决方式是两层兜底：状态更新逻辑放finally块，确保无论任务怎么结束都会把状态改成done或failed；再加一个心跳机制，ScanTask表记录last_heartbeat字段，worker每30秒更新一次，管理脚本每5分钟扫描一次心跳超过10分钟的任务，强制标记为failed并trigger重试。

@shared_task(bind=True) def run_scan_with_heartbeat(self, task_id): task = ScanTask.objects.get(id=task_id) task.status = "scanning" task.save() try: # 实际扫描逻辑 pass finally: task.refresh_from_db() task.status = "failed" if task.status != "done" else task.status task.save()

这里必须用refresh_from_db而不是直接拿之前的task对象，因为worker进程里可能缓存了旧状态。排查这类问题时先看Celery的worker进程是否还活着，再查系统dmesg有没有OOM日志，两个方向能定位大部分卡死场景。

5.5 现象：爬虫只抓到静态链接，登录后的页面一个都没测到

一次扫描跑得非常顺利，爬虫采集了300多个URL，检测器跑完只报了2条低危信息泄露。人工一查，发现目标系统有80%的接口都在登录墙后面，而爬虫是从未登录状态开始的，所有受保护页面都返回302，爬虫根本没拿到里面的链接和表单。这类问题最隐蔽，因为扫描报告没有报错，各项指标看起来都正常，检测不到东西反而无从排查。解决方式是在扫描任务里设计前置预热步骤：扫描启动时先请求首页和profile接口，验证登录态Cookie是否有效，无效直接fail-fast，并在任务错误信息里明确指出"登录态失效"。

def validate_auth(cookie, test_url): headers = {"Cookie": cookie} resp = requests.get(test_url, headers=headers, timeout=8, allow_redirects=False) return resp.status_code != 302

排查这一条时，先确认Target表里auth_cookie字段是否为空，再确认cookie值是否过期。登录态问题是扫描系统里最典型的隐性失败，宁可让任务快速失败也不要让它默默跑完产出垃圾结果。

6. 进阶用法：搭固定靶场做回归基线，把误报率钉在可控范围

扫描系统跑起来之后，真正的体力活是规则迭代。改了一条正则，可能让SQL注入检出率提升，也可能让误报从5%涨到60%。我最后悔的一件事是早期没有把验证环节做成自动化，直到被误报淹没才开始建回归基线。这套做法的核心是准备一组固定用例，每次改规则后跑一遍，用precision和recall两个指标决定规则能不能发布。我把这个过程独立成回归集，明确规则变更的验收标准。

回归集我建议分四类用例：一类是有漏洞必须检出的，一类是无漏洞但容易误报的，一类是登出这类不该请求的URL，一类是静态无漏洞页面。下面这张表是这套系统早期建立的基线用例子集：

每个用例固定RequestContext，不带随机参数，保证每次回归结果可比较。回归脚本实现很轻量，遍历用例，统计四个数字：真阳性、假阳性、真阴性、假阴性。

def run_baseline(baseline_cases): tp = fp = tn = fn = 0 for case in baseline_cases: hits = engine.scan_url(case.ctx) expected = case.should_hit if hits and expected: tp += 1 elif hits and not expected: fp += 1 elif not hits and expected: fn += 1 else: tn += 1 precision = tp / (tp + fp) if tp + fp else 0 recall = tp / (tp + fn) if tp + fn else 0 return precision, recall

回归门槛我一般设precision低于0.8直接阻断规则发布，recall低于0.8则提示需要补用例。把baseline_cases作为固定fixture提交到仓库，规则变更前先跑一次回归，确认精度没掉再合并。更进一步，可以在CI里对变更涉及的接口跑一次最小扫描集，这样每一行规则改动都有客观指标卡关，而不是靠拍脑袋决定能不能上线。

现在每次改规则，我第一件事不是看新报出的漏洞，而是看回归集里有没有新增误报。扫描器这种工具，真正值钱的不是代码量，而是长期维护下来的规则基线和团队对漏洞判断的共识。误报率这种东西，没有基线就是玄学，有了基线才有资格谈优化。希望帮到你。

本文还有配套的精品资源，点击获取