简介面向Web安全初学者与毕业设计学生的Python爬虫漏洞扫描源码包以爬虫为核心驱动对目标Web应用进行信息采集与漏洞识别覆盖requests、BeautifulSoup、正则表达式、Selenium等常用技术栈呈现从页面抓取、链接解析、表单探测到脆弱点判定的完整安全审计思路。包内含13个文件包括6个Python源码、3个zbak备份、2个txt说明、1个md文档和1个zip附赠内容整体仅1.55MB结构紧凑适合在Windows 10/11环境快速部署实验。项目运行稳定且具备跨平台能力源码模块划分清晰便于按爬虫模块、漏洞模块、配置模块研读与二次开发。配套说明文档涉及安装、使用和常见问题处理附赠图片与教程资源能降低入门门槛帮助理解漏洞原理与检测方式。目前已有35人学习下载适合作为课程设计或毕业设计的实践参考也可作为爬虫技术与Web安全结合的学习案例。1. 爬虫看不见的路由扫描器永远测不到给一个授权的 Web 项目做漏洞检测最常见的结果不是发现了漏洞而是报告空得可疑。手动点几个页面都正常自动化工具却连首页之外的功能都没测到。问题多半不在 payload而在候选集爬虫如果只走到首页的静态链接那么藏在登录后、分页、表单提交和 JavaScript 里的接口就不会进入检测队列。所以“基于网络爬虫的 Web 漏洞检测工具”真正要解决的第一件事不是注入而是把站点拓扑完整地变成结构化输入检测引擎只负责在这些输入上做基于基线对比的判定。下面按爬虫采集、参数提取、漏洞判定、覆盖验证四个环节展开适合要自己搭检测管线、或想理解商业扫描器为什么漏报的工程师。2. 用网络爬虫把站点 URL 空间变成检测候选集2.1 网络爬虫原理在 Web 漏洞检测里的作用边界通用爬虫的目标是把页面内容抓下来入库漏洞检测里的爬虫目标完全不同——它要回答“这个站有哪些可访问资源、每个资源接受哪些参数”。两者共享同一个骨架种子 URL、抓取队列、去重表、解析器、限速器但检测爬虫必须做到两点抓到的 URL 要能回溯到它在哪个页面、以什么上下文出现表单控件要当参数入口记录而不是当纯文本丢弃。手动做 Web 安全测试时人会在浏览器里完成“找接口”这件事刷新页面看新链接、翻页看路径规律、提交表单看行为变化。爬虫就是把这套动作固化成可重复的流程。正因如此覆盖率才直接决定检出率上限候选集里没有的参数检测引擎连探测的机会都没有。后面所有判定的质量都建立在这层输入是否完整之上。2.2 URL 规范化与去重键是防爆炸的第一道闸同一资源在站点里会以多种写法出现大小写、默认端口、多余斜杠、末尾查询串甚至会话 ID。如果不做规范化去重表会放过大量等价 URL导致同一页面被反复抓取和检测浪费带宽也拉长扫描窗口。import re from hashlib import sha1 from urllib.parse import urlsplit, urlunsplit # 去掉 fragment 和默认端口统一 scheme/host 大小写压缩连续斜杠 def normalize_url(raw: str) - str: p urlsplit(raw.strip()) scheme p.scheme.lower() host (p.hostname or ).lower() port p.port if port is None or (scheme http and port 80) or (scheme https and port 443): netloc host else: netloc f{host}:{port} path re.sub(r/{2,}, /, p.path or /) return urlunsplit((scheme, netloc, path, p.query, )) def dedup_key(method: str, url: str) - str: return sha1(f{method.upper()}|{normalize_url(url)}.encode()).hexdigest()这段代码把 fragment 直接丢弃因为检测请求不需要它host 强制小写避免Example.com和example.com被当成两个资源。去重键里带了 method是因为同一个 URL 的 GET 和 POST 语义可以完全不同POST 必须走表单参数矩阵单独生成候选。需要注意normalize_url没有对 query 排序若站点同一页面用不同参数顺序输出不同内容排序反而会误伤保守做法是不排序靠抓取预算兜底。2.3 抓取预算、限速与退避的参数设计候选集失控的表现很典型日历页生成几千个日期链接或者排序参数让分页无限增长。预算字段要在爬虫启动前就设好而不是等进程被拖死后才想起来。| 字段 | 作用 | 常见起始值 | | max_depth | 从种子页算起的链路深度 | 3 | | max_pages | 单个 host 最多入队页面数 | 2000 | | max_pending | 待抓队列上限超出则丢弃低价值 URL | 5000 | | politeness | 同一 host 两次请求的最小间隔秒 | 0.5 | | timeout | 单请求超时时间秒 | 10 | | backoff | 收到 429/503 后的等待基数秒 | 2之后按 2 倍递增 |import time from urllib.parse import urlsplit class CrawlWorker: def __init__(self, session, budget): self.session session self.budget budget self.last_request_at {} def fetch(self, url: str): host urlsplit(url).hostname or unknown now time.monotonic() gap self.budget.politeness - (now - self.last_request_at.get(host, 0)) if gap 0: time.sleep(gap) try: resp self.session.get(url, timeoutself.budget.timeout) except requests.RequestException: return None self.last_request_at[host] time.monotonic() if resp.status_code in (429, 503): wait self.budget.backoff self.budget.backoff min(self.budget.backoff * 2, 60) time.sleep(wait) return None return resplast_request_at按 host 记时间而不是全局一个时钟这样多 host 抓取可以并行又不会因慢站点拖住整个队列。polite-ness 调到 0.2 秒以内通常不明智很多站点没有明确限流就会丢包或返回 500误伤后还要重抓一次整体收益是负的。429/503 处理很关键检测工具的流量特征本来就比普通爬虫可疑收到限流响应后继续高频请求只会让后续响应全部失真。3. 从响应里提取检测入口HTML 解析与表单参数矩阵3.1 先做响应清洗再谈解析效率爬虫拿到 HTML 后第一步不是喂给解析器而是判断这个响应值不值得解析。资源类的 content-typeimage、css、font直接跳过301/302 要跟随重定向还原最终 URL响应体超过阈值比如 10MB时只取头部避免解析器被拖死。这一步做扎实后面的表单提取才不会在垃圾数据上浪费时间。很多人在这一步直接用正则抠链接遇到属性里带转义符或大小写混写就漏。站点内链接的写法千奇百怪相对路径、绝对路径、//host/path协议相对、javascript:伪协议。用标准解析器加urljoin处理相对路径比正则稳定得多。爬虫模块里应该给响应体大小、重定向次数、可解析类型各设一个上限值并且在日志里记录被跳过的原因方便排查覆盖率异常。3.2 用表单解析把控件名当参数入口记录from html.parser import HTMLParser from urllib.parse import urljoin class FormExtractor(HTMLParser): def __init__(self, base_url: str): super().__init__() self.base_url base_url self.forms [] self._form None def handle_starttag(self, tag, attrs): attrs dict(attrs) if tag form: self._form { action: urljoin(self.base_url, attrs.get(action, )), method: attrs.get(method, get).lower(), enctype: attrs.get(enctype, application/x-www-form-urlencoded), inputs: [], } elif tag input and self._form is not None: self._form[inputs].append({ name: attrs.get(name), type: attrs.get(type, text), value: attrs.get(value, ), }) def handle_endtag(self, tag): if tag form and self._form is not None: self.forms.append(self._form) self._form None这段继承html.parser的实现只处理了 form 和 inputselect、textarea 在实际 web 工程里同样常见扩展方式是在handle_starttag里加分支。urljoin(base_url, action)是必须的一步因为表单 action 经常只写相对路径不拼接就会把探测请求发到错误地址。input 的 type 字段不能省略它决定后续参数矩阵怎么选样本。3.3 按控件类型分配检测样本别把所有参数当字符串| 控件类型 | 参数语义 | 检测样本方向 | | text/textarea | 字符串回显 | 闭合标记、反射型 XSS 探针 | | number | 数值标识 | 边界值、布尔条件对比 | | select | 枚举值 | 越权枚举、整型异常 | | url/link | 外链 | SSRF 回调、开放重定向 | | hidden/csrf token | 校验令牌 | 不注入按原值回传 |企业级 web 开发里隐藏域最常见的用途是 CSRF token 和状态标识。把 token 当普通参数去注入是新手最容易交的学费要么触发令牌校验导致所有探测响应都是 403要么一次性作废会话后面的请求全部失去登录态。处理方式是首次抓取时记录 token 的 name 和 value每次探测请求前重新获取页面并更新 token 值或者直接把这组参数从注入候选里剔除。会话保持是参数提取的隐藏前提。爬虫和检测引擎必须共用一个requests.Session登录态的 Cookie 才会连续生效。如果检测阶段另起 Session爬虫阶段确认过的功能页面会在探测时全部跳回登录页此时任何判定都会被误导。4. 检测引擎让爬虫候选集变成可复核的漏洞判定4.1 主动探测与被动指纹分工检测引擎处理的对象不是原始 HTML而是“候选资源乘参数矩阵”的笛卡尔积。它分成两条线被动指纹从响应头、Cookie 属性和错误页特征里提取版本与配置信息例如Server头暴露的中间件版本、Set-Cookie缺失HttpOnly、错误页里出现的堆栈路径主动探测则对参数注入构造样本观察响应与基线之间的差异。Web 服务器安全的排查常常依赖这类指纹一条信息泄露路径、一个带版本号的 500 页面就能让测试人员优先去查对应隐患。主动探测的样本要小型化原则是“能证明参数被代入就停”而不是追求一锤定音的攻击效果。所有探测都应在你有权测试的目标上进行并保留请求日志便于复核。4.2 基线对比是误报控制的核心def compare_response(base, probe, marker: str) - dict: delta len(probe.text) - len(base.text) return { status: probe.status_code, delta: delta, reflected: marker in probe.text, } def is_interesting(session, url, params, key, probe, marker): ordinary {**params, key: 0} # 基线值 base session.get(url, paramsordinary) tested {**params, key: probe} # 探针值 probe_resp session.get(url, paramstested) diff compare_response(base, probe_resp, marker) # 状态码一致、出现标记时才进入人工确认队列 if (base.status_code probe_resp.status_code and diff[reflected]): return diff return None这里用0做基线值而不是空字符串是为了避免参数缺省与参数为空两种行为混在一起。marker是一段无意义的随机字符串用来证明输入被原样带回响应体——只有它出现时“反射”这个结论才成立。长度差不能作为唯一判据因为正常业务也会随参数变化改变输出反射标记加状态码一致性组合才是把误报压下去的关键。判定分两轮会更稳妥第一轮用宽松规则筛“可疑”第二轮用精确条件确认。第一轮里只要反射标记出现就入队第二轮再判断闭合情况、上下文是否可执行。只跑一轮就直接报漏洞往往会把站内搜索功能误报成存储型 XSS。4.3 探测参数与验证开关检测脚本通常要暴露几个开关方便不同站点调整--method指定 GET/POST 探测、--key指定只测某几个参数、--confirm开启二次确认、--log-dir保留原始请求与响应。还有一个容易被忽略的参数是--safe-codes某些站点的 WAF 会对可疑请求返回 403把 403 直接当漏洞证据是典型误判正确的做法是把它标记为“被拦截”单独导出。CTF 场景和真实站点最大的差别也在这里靶场里任意注入都有效真实 web 项目背后常有 WAF 与参数清洗逻辑探测响应里出现拦截页的频率远高于漏洞响应。检测引擎把拦截页、登录跳转、验证码挑战三种情况单独分类比混在“无漏洞”里更有价值。提示如果探测过程中响应从正常页面突然变成统一的 403 或登录跳转先检查 Cookie 与 token 是否失效再检查是否触发了拦截最后才怀疑是参数问题。5. 覆盖率验证用最小靶机校准爬虫与检测5.1 一个两接口的 Flask 靶机from flask import Flask, request, render_template_string app Flask(__name__) app.route(/) def index(): return render_template_string( a href/echo?q1echo/a form action/calc methodget input nameainput nameb buttonsubmit/button/form ) app.route(/echo) def echo(): return request.args.get(q, ) app.route(/calc) def calc(): a, b request.args.get(a, 0), request.args.get(b, 0) return str(int(a) int(b)) app.run(host0.0.0.0, port5000, debugFalse)首页里同时出现静态链接和表单正是为了验证两件事爬虫能否从链接发现/echo解析器能否从表单提取a和b两个参数。启动后跑一次python cli.py crawl --seed http://127.0.0.1:5000/ --depth 2 --max-pages 50预期结果应该是三个候选资源/echo?q、/calc?ab外加根路径/。如果/echo没出现查链接提取如果/calc出现了但参数为空查表单解析。这个最小靶机就是爬虫模块的单元测试基准。5.2 三个最常踩的坑第一个坑是会话丢失靶机没有登录页所以测不出来真实站点一旦设了登录态 Cookie爬虫和检测必须共用 Session否则后半个流程全在测登录跳转页。第二个坑是 SPA 首屏无链接纯前端渲染的页面里 HTML 解析器拿不到路由常见做法是配置 headless 浏览器渲染后再解析或者直接把前端打包产物里的路由表导入种子列表成本低得多。第三个坑是重爬时重复劳动如果站点响应带 ETag 或 Last-Modified爬虫可以用条件请求跳过未变化页面把时间留给真正变更过的部分。使用http.cookiejar与requests.Session结合时记得在重爬前清空 CookieJar否则旧会话残留会让新的登录态验证形同虚设。重爬策略的触发条件一般看三个指标目标站点上线新版本、种子列表出现新入口、上一轮报告里被 WAF 拦截的路径占比异常升高。这个标题下的工具本质是把“先摸清目标再验证问题”这个过程自动化。把爬虫的覆盖率指标和检测的确认队列分开看出现问题时就能快速定位是没抓到还是没检出。本文还有配套的精品资源点击获取