企业官网建设流程全解析

简介：项目基于Python Flask框架开发，是一套Web漏洞扫描系统毕业设计源码，面向计算机、通信、人工智能、自动化等专业学生与开发者，适用于课程设计、大作业或毕业设计支撑项目。系统涵盖信息搜集与漏洞扫描两大核心模块，代码经过调试可直接运行，答辩评审分98分，具备一定完整性和参考价值。压缩包共156个文件，大小2.88MB，以43个Python文件构成后端核心逻辑，19个CSS、18个JS与14个HTML实现前端管理界面，另有7个Markdown说明、Dockerfile与YAML部署配置、SQL数据库脚本以及DOCX使用文档，方便对照代码与文档快速理解项目结构。资源内提供完整源码包、可视化页面和多类型辅助文件，从登录认证到扫描任务执行均有对应代码模块，配合使用文档可快速上手，也便于毕业设计答辩演示。目前已有34人学习下载，适合需要系统掌握Flask Web开发、安全扫描流程的读者，可在现有基础上修改扩展，自由补充扫描规则或界面功能。

1. 基于 Python Flask 的 Web 漏洞扫描系统：毕设里最难的不是 Flask，是这两条链路

很多人选“基于 Python Flask 的 Web 漏洞扫描系统”当毕设，是因为觉得“Web 漏洞扫描”听起来比“图书管理系统”有分量。但实际动手你会发现，Flask 只是最不费劲的部分：路由、表单、数据库读写，一周能写完。真正让这个题目值钱、也让大部分人卡到崩溃的，是信息搜集怎么做得全、漏洞扫描怎么测得准——这两条链路才是系统的核心。这篇笔记按“源码怎么拆、怎么跑、怎么改”的视角，把模块拆分、信息搜集、漏洞扫描、踩坑记录和验证技巧一次讲透。适合正在做毕设的学生，也适合想用 Flask 搭一个最小可用扫描器的后端开发。

2. 系统拆分与模块选型：把信息搜集和漏洞扫描分开，代码才写得下去

大多数人的第一个错误，是把所有逻辑塞进 Flask 路由里：用户在前端点“开始扫描”，后端函数里既做 DNS 解析又发 HTTP 请求又写数据库。这种做法在演示时能跑，但答辩时被问“某一个环节挂了怎么办”“想加一种新漏洞怎么加”就答不上。常见的做法是拆成三个独立模块：Web 层负责接收任务和展示结果，信息搜集模块和漏洞扫描模块各自独立运行，模块之间只通过数据库表和任务状态通信。

2.1 模块划分：信息搜集、漏洞扫描、任务管理三层

先看一下整个系统的数据流，再决定代码放哪里。用户提交一个域名或 URL，系统先进入信息搜集阶段：枚举子域名、探测端口、识别 Web 指纹。这些都是网络请求操作，互相之间没有依赖，适合拆成独立的函数组。信息搜集结束后，系统拿到一串“看起来像 Web 服务”的 URL，把这些 URL 交给漏洞扫描模块。扫描模块再逐个请求，投递 payload，比对响应。

我在做这个题目时采用的目录结构如下，这个结构也是毕设答辩时最容易讲清楚的结构。每个模块一个文件，不要把一个模块拆到十几个文件里。

vulnscanner/ ├── app.py # Flask 入口：注册蓝图、初始化数据库 ├── config.py # 路径、超时、并发、payload 文件路径 ├── requirements.txt ├── modules/ │ ├── __init__.py │ ├── models.py # SQLAlchemy ORM 模型 │ ├── recon.py # 信息搜集：子域名、端口、指纹 │ ├── scanner.py # 漏洞扫描：SQLi 和 XSS 检测器 │ └── utils.py # 公共请求会话、日志、超时工具 ├── templates/ # Jinja2 页面 ├── static/ # 前端静态资源 └── scans/ # 扫描报告输出目录

逻辑说明：app.py 里不写任何检测逻辑，只做三件事：读取 config、注册蓝图、调 create_all 建表。recon.py 和 scanner.py 互不 import，两者都通过 models.py 里的任务表判断自己该做什么。这样的好处是，你单独跑python modules/recon.py example.com也能用，不需要启动 Flask。我在调试信息搜集模块时就是这么干的，比每次都从浏览器点按钮快得多。

参数说明：scans/ 目录建议放在项目根目录而不是 static 下，避免扫描报告被当成静态文件直接对外暴露。毕业设计答辩现场经常有人现场演示，报告路径暴露会让你的系统看起来很不专业。config.py 里所有超时和并发参数都集中管理，后文讲到的 timeout、线程数、payload 路径都在这里改，不要散落在各个函数里写死数字。

2.2 Flask 只当壳：真正干活的是 requests、socket 和 BeautifulSoup

Flask 在系统里的角色是任务分发和结果展示。一个常见的误解是“用 Flask 写扫描器”，实际上扫描器部分跟 Flask 没有任何关系，把 Flask 换成 Django 或者换成命令行脚本，扫描逻辑一行都不用改。我在实现时用 Flask 的 Blueprint 把 API 和页面分成两组：页面走/，API 走/api/scan，这样前后端可以分开改。

# app.py 中的蓝图注册片段 from flask import Flask from modules.api import api_bp from modules.views import view_bp def create_app(): app = Flask(__name__) app.config.from_pyfile("config.py") app.register_blueprint(view_bp) # 页面路由 app.register_blueprint(api_bp, url_prefix="/api") # 接口路由 return app

逻辑说明：scan 任务的提交、查询、删除全部走 /api 前缀，页面模板只通过 fetch 调接口，不直接操作任务表。这是 Flask Web 开发里比较常见的做法，后期加报告导出功能时只需要在 api_bp 里加一个路由，不会碰到页面代码。视图层和接口层分开之后，你甚至可以先用 Postman 把接口全部调通，再做页面，调错时更容易定位是前端问题还是后端问题。

技术选型上，信息搜集部分我用的是 requests 加 socket，页面解析用 BeautifulSoup，这三个库是 python 环境里最基础的依赖，不需要额外装扫描框架。为什么不直接调用现成的扫描框架？因为毕设的核心评价点在“你理解不了解漏洞检测原理”，用框架等于把最有分量的部分外包了。答辩时老师问一句“这个漏洞是怎么发现的”，如果你只会说“框架自动扫的”，这一题就已经扣分了。自己实现检测逻辑，哪怕实现得简单，也至少能讲清楚请求和响应的比对过程。

2.3 数据库设计与任务状态机：给每个扫描任务一个状态

扫描系统必须要回答三个问题：当前任务跑到哪一步了、发现了什么、结果存在哪。所以数据库至少要有四张表：targets 存目标信息，scan_tasks 存任务状态，subdomains 存子域名枚举结果，vulns 存漏洞结果。下面是 models.py 的核心部分。

from flask_sqlalchemy import SQLAlchemy from datetime import datetime db = SQLAlchemy() class ScanTask(db.Model): __tablename__ = "scan_tasks" id = db.Column(db.Integer, primary_key=True) target = db.Column(db.String(255), nullable=False) # 用户提交的域名或 URL status = db.Column(db.String(16), default="pending") # pending/running/finished/failed created_at = db.Column(db.DateTime, default=datetime.now) finished_at = db.Column(db.DateTime, nullable=True) class VulnResult(db.Model): __tablename__ = "vulns" id = db.Column(db.Integer, primary_key=True) task_id = db.Column(db.Integer, db.ForeignKey("scan_tasks.id")) url = db.Column(db.String(500), nullable=False) # 漏洞所在 URL vuln_type = db.Column(db.String(32)) # sqli / xss param = db.Column(db.String(64)) # 漏洞参数名 payload = db.Column(db.Text) # 触发漏洞的 payload detail = db.Column(db.Text) # 响应特征描述

说明：status 字段是任务调度的核心。前端轮询 /api/scan/status 时只查这个字段，后端线程在处理时把 pending 改成 running，全部测完改成 finished，异常则改成 failed。状态机是毕设答辩的加分项，比把“扫描中”写死在页面上要专业得多。参数说明：url 字段必须存完整 URL，不要只存域名，因为漏洞报告里每个条目都要能单独点击跳转。如果只存域名，报告页就要靠拼接去猜原始路径，很容易拼错。

初始化数据库的步骤放在 app 启动时执行。第一次跑之前先装依赖再建库：

python -m venv venv source venv/bin/activate # Windows 下为 venv\Scripts\activate pip install -r requirements.txt python -c "from app import create_app; app=create_app(); app.app_context().push(); from modules.models import db; db.create_all()"

逻辑说明：这里用 app_context 推入上下文是因为建表操作依赖 Flask 的配置，直接 import db 然后 create_all 会因为缺少 app 上下文报错。这一步经常有人漏掉，后面的避坑章节会再补一个它的连带坑。参数说明：venv 是 python 项目的基本隔离手段，不要用系统 python 直接装依赖，否则后期装新库时很容易把环境弄乱。这个教训在 python 新手里极其常见，装了一堆全局包之后，项目和系统库互相踩版本，最后只能重装 python 环境。

3. 信息搜集模块：子域名枚举、端口探测和指纹识别的可跑代码

信息搜集的目的是生成一份“目标资产清单”。对毕设来说不需要做到企业级资产测绘，但至少要做到三件事：知道目标的子域名，知道哪些端口开着，知道 Web 服务用的什么框架。这三件事分别对应三个独立函数，全部放在 modules/recon.py 里，扫描模块在后面直接引用它们的结果。三个函数的输入都统一为目标域名，输出分别是列表或字典，方便后续模块读取。

3.1 子域名枚举：字典加 DNS 解析，二十多行就能跑

子域名枚举的常见做法是用一个字典跑穷举，对每个候选子域名做 DNS 解析，解析出 IP 就认为存在。这种方法在高校毕设里足够用了。不要一上来就接搜索引擎接口和证书透明日志，先把正向枚举做通，再作为扩展点提一句即可。

import socket from concurrent.futures import ThreadPoolExecutor def enum_subdomains(domain, dict_path="./dict/subnames.txt", concurrency=20): with open(dict_path, encoding="utf-8") as f: words = [line.strip() for line in f if line.strip()] found = set() def check(word): sub = f"{word}.{domain}" try: ip = socket.gethostbyname(sub) found.add((sub, ip)) except socket.gaierror: pass # 解析失败表示子域不存在，忽略 with ThreadPoolExecutor(max_workers=concurrency) as pool: pool.map(check, words) return sorted(found)

逻辑说明：socket.gethostbyname 是阻塞调用，单个解析通常几毫秒，但遇到不存在的域名要等系统 DNS 超时，所以必须用线程池并发跑。pool.map 会等待所有任务完成，所以函数返回时 found 已经收集完整。参数说明：concurrency 设在 20 左右比较合适，太高容易让本机 DNS 查询队列溢出丢结果，太低则几千词的字典要跑好几分钟；dict_path 指向一个每行一个单词的纯文本字典，字典里可以包含 www、api、admin、test 这类常见前缀，前缀文件可以从网上找现成的，也可以自己按毕设目标积累。

注意：gethostbyname 返回的是第一个 IP，对有多 IP 的域名拿不到完整 A 记录。想做得细一点可以用 dnspython 库解析 A 记录，但毕设场景用内置库已经够讲清楚“解析成功即存在”的判断逻辑。另一个小细节：有些靶场环境 DNS 解析会超时很长，如果跑完一批字典发现结果异常少，先检查系统 DNS 是不是被改过，用nslookup手动解析一个确定存在的子域名验证。

3.2 Web 指纹识别：用响应头和页面特征做多规则匹配

指纹识别的本质是“看到什么特征，猜它是什么框架”。特征来源有三个：响应头里的 Server、X-Powered-By，页面里的 meta generator，还有特定路径的文件（如 /wp-login.php 存在说明是 WordPress）。最省事的实现是维护一个规则列表，每条规则带一个 judge 函数。

import requests import re FINGERPRINT_RULES = [ { "name": "WordPress", "headers": {"X-Powered-By": "php"}, "body_regex": r"wp-content|wordpress", "path": "/wp-login.php", }, { "name": "ThinkPHP", "headers": {"X-Powered-By": "PHP"}, "body_regex": r"ThinkPHP|thinkphp", "path": "/index.php", }, ] def fingerprint(url, session=None): if session is None: session = requests.Session() try: resp = session.get(url, timeout=(5, 10), allow_redirects=True) except requests.RequestException: return [] text = resp.text[:200000] hits = [] for rule in FINGERPRINT_RULES: score = 0 for k, v in rule["headers"].items(): if resp.headers.get(k, "").lower() == v.lower(): score += 1 if rule["body_regex"] and re.search(rule["body_regex"], text, re.I): score += 1 if rule["path"]: try: p = session.get(url.rstrip("/") + rule["path"], timeout=(3, 5)) if p.status_code == 200: score += 1 except requests.RequestException: pass if score >= 2: hits.append(rule["name"]) return hits

逻辑说明：评分逻辑是每个命中的特征加 1 分，score 大于等于 2 才输出指纹。为什么不用单特征命中？因为 X-Powered-By 为 PHP 的站点一半以上是普通 PHP 页面，不是 ThinkPHP，单靠响应头会把误报率拉高到没法看。path 探针的作用是二次确认，比如 WordPress 的 /wp-login.php 返回 200 时权重很高。参数说明：text 截断到 200000 字符是防止目标首页是超大文件或者流式响应，匹配这么多内容已经足够覆盖绝大多数框架特征；allow_redirects=True 是为了拿到最终真实页面的响应头，很多站点会把根路径重定向到 /index.php，不跟随重定向就拿不到最终的指纹。

3.3 端口探测：TCP connect 就够了，别碰 SYN 扫描

端口探测在毕设里的定位是“为漏洞扫描提供端口层面的入口提示”，不需要扫全端口。常见做法是只扫一个常见端口列表，用 socket 的 connect_ex 发一个 TCP 连接尝试，连接成功就认为端口开着。SYN 半开扫描需要构造原始数据包，在 Windows 下还需要 Npcap 驱动，纯 Python 实现还要用 scapy，这些对毕设来说都是不必要的复杂度。

COMMON_PORTS = [21, 22, 23, 25, 53, 80, 443, 3306, 3389, 6379, 8080, 8443] def scan_ports(host, ports=None, timeout=1.0): ports = ports or COMMON_PORTS open_ports = [] for port in ports: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) result = s.connect_ex((host, port)) s.close() if result == 0: open_ports.append(port) return open_ports

逻辑说明：connect_ex 的返回值是错误码，0 表示连接成功。这个函数逐个端口串行探测，COMMON_PORTS 只有 12 个端口，最坏情况等 12 秒，演示时可以接受。参数说明：timeout=1.0 是连接超时，目标主机不可达时每个端口要等 1 秒，所以想再快可以把 timeout 降到 0.5，但内网环境丢包率稍高时误报率也会上升。需要并发时可以用线程池包一层，但毕设串行已经够用，串行的好处是打印日志时顺序清晰，答辩演示时能一条条看到探测进度。

端口探测的结果还要跟 HTTP 服务识别联动：对 80、443、8080、8443 这几个端口直接请求 http 或 https 的根路径，把响应状态码和 Server 头存下来，供漏洞扫描模块选择目标。这一步本质上就是 python 爬虫的请求逻辑，在信息搜集模块里复用一个带 Session 的 utils 函数即可，不用重复写请求代码。这样信息搜集模块算下来只有三个函数、两个数据文件（字典和规则），维护成本很低。

4. 漏洞扫描模块：SQL 注入与 XSS 的检测逻辑、判定参数和调度

漏洞扫描模块是整个系统的核心，也是答辩时老师追问最多的地方。不要想着把 OWASP Top 10 全做一遍，毕设能讲清楚两个漏洞的完整检测闭环已经很扎实：SQL 注入和 XSS。这两个漏洞的检测思路有本质区别，放在一起恰好能展示你对检测原理的理解。扫描器的输入是信息搜集阶段得到的 URL 列表和指纹结果，输出直接写进 vulns 表。

4.1 检测流程：参数从哪里来，payload 往哪里投

拿到 URL 后第一件事是解析参数：带问号的 URL 直接拆参数名，不带参数的页面要解析页面里的<a>链接和<form>表单。这一步用 BeautifulSoup 就能做，逻辑不复杂但决定了扫描覆盖率。如果参数提取不全，后面检测器再厉害也扫不到那些入口。

from urllib.parse import urlparse, parse_qsl from bs4 import BeautifulSoup def extract_params(url, html=None): params = [] parsed = urlparse(url) if parsed.query: params.extend([k for k, _ in parse_qsl(parsed.query)]) if html: soup = BeautifulSoup(html, "html.parser") for a in soup.find_all("a", href=True): p = urlparse(a["href"]) if p.query: params.extend([k for k, _ in parse_qsl(p.query)]) for form in soup.find_all("form"): for inp in form.find_all("input", {"name": True}): params.append(inp["name"]) return list(set(params))

逻辑说明：parse_qsl 会把 URL 里的 k=v 拆成元组列表，我们只取参数名。从 HTML 提取时同时看 a 标签和 input 标签，这是最常见的两个参数入口。参数说明：返回的是去重后的参数名列表，同一个参数在多个 URL 出现时只测一次，避免重复请求浪费扫描时间；如果页面有分页参数 page=1&size=20，两个参数都会被提取，但实际扫描时建议只测 page 和 size 这种业务参数，跳过 token 和 session 这类明显不参与 SQL 拼接的字段，可以在 extract_params 里加一个过滤名单。

扫描调度采用线程池加任务队列，每个 URL 一个任务，线程池大小限制在 5 到 8 之间，这样不会把个人电脑跑满，也不会对目标站点产生太大压力。每个任务内部依次执行 SQL 注入检测和 XSS 检测，两个检测器共用同一个 requests.Session，保持 Cookie 上下文一致，避免因为会话断开导致误报。任务结束把状态改为 finished，整个流程通过 scan_tasks 表串起来。

4.2 SQL 注入检测：报错特征和时间差两种判定

SQL 注入的检测思路是给参数塞入 SQL 语法片段，观察目标数据库的响应有没有异常。报错注入适用于开了错误回显的站点，时间盲注适用于页面无任何报错信息但对数据库查询耗时敏感的站点。两种判法互为补充，一个都不能少。

import time import re SQLI_PAYLOADS = [ {"payload": "'", "keyword": "sql syntax|SQL syntax|mysql_|ORA-|sqlite"}, {"payload": "') OR '1'='1", "keyword": "sql syntax|ORA-|syntax error"}, {"payload": "' AND SLEEP(3)-- -", "type": "time", "sleep": 3}, ] def detect_sqli(base_url, param, session, timeout=8): for item in SQLI_PAYLOADS: params = {param: item["payload"]} if item.get("type") == "time": start = time.time() session.get(base_url, params=params, timeout=timeout) cost = time.time() - start if cost >= item["sleep"] - 0.5: return {"param": param, "payload": item["payload"], "type": "time", "detail": f"cost={cost:.2f}s"} else: r = session.get(base_url, params=params, timeout=timeout) if re.search(item["keyword"], r.text, re.I): return {"param": param, "payload": item["payload"], "type": "error", "detail": r.text[:200]} return None

逻辑说明：时间盲注判定的阈值写作cost >= sleep - 0.5，比如 sleep 是 3，那么只要请求耗时超过 2.5 秒就判定疑似命中，留 0.5 秒给网络延迟误差。为什么不直接大于 3？因为 SLEEP(3) 在实际查询里可能因为多行记录串联执行而略微超过 3 秒，但几乎不可能低于 2.5 秒。参数说明：timeout=8 必须大于 sleep 值，否则请求会在 sleep 完成前被超时中断，永远测不出时间差；这个 8 是“请求最迟 8 秒返回”的兜底，不是期望耗时。timeout 和 sleep 的差值至少要留 3 秒以上，网络差的场景甚至要留 5 秒。

报错注入的关键字匹配用的是正则，覆盖 MySQL、Oracle、SQLite 三类报错特征。“sql syntax|SQL syntax|mysql_|ORA-|sqlite”这组特征在误报和漏报之间比较平衡。注意这里的请求用的是 GET 参数拼接，如果目标站点的参数是 POST，需要改成 session.post 并把参数放进 data，检测逻辑完全一样。还应该注意：报错注入的响应文本量很大时，正则匹配不要用贪婪跨行，用 re.I 忽略大小写就够了。

4.3 XSS 检测：反射点判定和编码绕过的处理

反射型 XSS 的判定标准是“payload 或 payload 的关键特征出现在响应里”，说明输入被原样输出了。但也有站点会做转义，把 < 转成 <，所以判断时要区分“原样反射”和“转义后反射”。毕设里可以只对原样反射报高危，转义后的作为低危忽略，这样误报率比较低。

XSS_PAYLOADS = [ "<script>alert(1)</script>", "<img src=x onerror=alert(1)>", "<svg/onload=alert(1)>", "<ScRiPt>alert(1)</ScRiPt>", ] def detect_xss(base_url, param, session, timeout=8): for payload in XSS_PAYLOADS: r = session.get(base_url, params={param: payload}, timeout=timeout) ctype = r.headers.get("Content-Type", "") if "text/html" not in ctype.lower(): continue if payload in r.text: return {"param": param, "payload": payload, "type": "reflected"} return None

逻辑说明：Content-Type 的判断是为了排除 JSON 接口和纯文本接口，它们反射字符串不算 XSS。payload 列表里大小写混写的那条，是为了覆盖“只做小写转义”的低水平过滤逻辑。参数说明：<ScRiPt>这条在现实站点里命中率不高，因为很多过滤规则是区分大小写的，浏览器却能识别，把它放进去的目的是展示你理解编码绕过，答辩时可以讲清楚为什么要保留这条。

一个容易忽略的点：requests 会自动做 gzip 解码，resp.text 拿到的是解码后的文本。如果你自己用 socket 裸发 HTTP 请求，必须手动处理 Content-Encoding: gzip，否则 payload 在压缩流里怎么都匹配不到。用 requests 就避开了这个坑，这也是扫描器里所有请求都走 Session 而不是直接开 socket 的原因。写完后把 detect_sqli 和 detect_xss 的返回结果统一写入 vulns 表，再更新 scan_tasks 的状态字段，整个扫描闭环就完成了。

5. 避坑：源码跑通时最容易翻车的五个地方

这一章的每一条都是实际跑这类毕设源码时常见的坑，按“现象→原因→解决”写。如果你是基于别人的源码二次开发，先对照这一章把坑填了再动功能；如果你自己从零写，也能省下大量调试时间。这些问题在本地环境和答辩演示时出现的概率都很高，值得逐条过一遍。

5.1 数据库表建好了，数据却写不进去

现象：启动时 db.create_all() 没报错，页面也能打开，但提交扫描任务后列表一直是空的，刷新后数据消失。

原因：SQLite 的数据库文件路径用的是相对路径，Flask 的当前工作目录跟启动位置不一致时，文件会被创建在不同目录。更隐蔽的是，扫描线程和 Flask 主进程同时写同一个 SQLite 文件，会触发 database is locked 报错，表现同样是数据写不进去。

解决：config.py 里用绝对路径拼数据库文件位置，把SQLALCHEMY_DATABASE_URI改成sqlite:///加os.path.join(BASE_DIR, "vulnscan.db")。并发写入问题给连接加check_same_thread=False，并把扫描逻辑里的 session 改为每次独立创建，不要跨线程共享同一个 session 对象。判断路径对不对有个小技巧：打印db.engine.url看数据库文件实际落在哪，然后对比项目的 BASE_DIR，一眼就能看出是不是路径漂移了。改完之后删掉旧的 db 文件重新建一次表，别在旧文件上迁移，毕设阶段不值得花时间在迁移上。

5.2 扫描任务永远停留在 running，卡死不动

现象：点击开始扫描后，任务状态一直是 running，等五分钟也不变，日志没有异常输出，CPU 占用也很低。

原因：requests 请求没有设 timeout，或者 timeout 设得比目标服务器响应时间短。还有一个常见原因是 socket 端口探测的 timeout 设成 0，等于无限等待。扫描线程被一个永不返回的请求占满，线程池里的其他任务全部排队，看起来就像是死锁。

解决：所有网络请求统一收口到 utils.py 里的一个函数，强制设置timeout=(5, 10)，连接 5 秒、读取 10 秒；socket 操作逐个settimeout(1.0)。然后给扫描线程池加一个总任务时长上限，单个 URL 超过 60 秒直接标记 failed，不要让它无限卡住。线程池的队列也建议设一个 maxsize，满了就拒绝新任务，避免内存被任务对象堆满。调试时在任务开始和结束各打一行日志，停住时看最后一条日志停在哪，就能定位是哪个请求没回来。

5.3 指纹识别几乎全报 WordPress，误报率惨不忍睹

现象：随便扫一个普通的 PHP 站点，报告里能同时列出来 WordPress、ThinkPHP、DedeCMS 三种指纹，明显不可能。

原因：早期版本只要匹配到 X-Powered-By: PHP 就输出“可能为 WordPress”，单个特征命中即判成功。这种宽松规则在绝大多数 PHP 站点上都会误报，因为 PHP 只是语言环境，不是具体框架。指纹识别的核心是“多个独立特征同时指向同一个框架”，只拿语言环境特征当数值必然翻车。

解决：改成多特征评分制，每条规则至少命中 2 个特征才输出，比如 WordPress 必须同时满足 X-Powered-By 是 PHP 和 body 出现 wp-content 两个条件。在 fingerprint() 里把 score 阈值从 >= 1 提到 >= 2，误报率会立刻下降。改完用几个已知框架的站点回归一遍，确认 WordPress、ThinkPHP 各自能被正确识别，再调阈值。这个参数写在指纹匹配函数末尾的判断里，是所有误报问题的总开关。给规则加一个最后修改时间字段，答辩时能说清楚这套规则你一直在维护，不是抄来的死配置。

5.4 XSS payload 在本地能测出，换到目标站点全部哑火

现象：用 SQLi-Labs 或自己写的测试页验证反射型 XSS，检测器能报漏洞；换成真实站点后，同一个 payload 全无反应。

原因：真实站点做了三层干扰。第一，HTML 实体编码把 < 转成 <，响应里不再有原始 payload 字符串；第二，站点有 WAF 拦截带