爬虫驱动的Web漏洞检测工具：源码解析与实战

简介基于网络爬虫的Web漏洞检测工具是一份面向网络安全初学者与毕业设计学生的Python实战资源。项目利用爬虫技术遍历网站结构结合常见漏洞特征库识别安全问题适用于安全审计入门、课程设计及毕业设计场景。压缩包共13个文件包含6个Python源码文件分别负责爬取、漏洞模块、数据库管理、配置与主执行逻辑另有3个工程备份文件、2个文本数据文件、1个README说明文档及1个附赠资源压缩包整体仅1.55MB轻量易部署。当前已有35人学习下载。内容涉及requests、BeautifulSoup、正则表达式、Selenium等常用技术附赠的图片与教程可帮助初学者以可视化方式理解爬虫遍历与漏洞检测流程。源码按功能拆分为配置、爬取、扫描、执行等模块结构清晰便于阅读、调试与二次开发也能为理解Web安全检测原理提供完整范例。资源来源于网络分享仅用于学习交流请勿用于商业用途。1. 爬虫驱动的Web漏洞检测工具为什么这份源码值得拆开看上个月帮朋友做内网小站的安全检查手头只有 Python 环境商业扫描器又太重最后就靠这套源码思路用爬虫把所有可见链接抓下来再逐个做基础漏洞特征匹配两小时就把问题点摸清了。这套基于网络爬虫的 Web 漏洞检测工具本质上不是那种重型企业级扫描器而是一个能让你看清楚爬虫原理怎么落地成检测工具的完整实践项目。它只做两件事一是用爬虫把站点里的 URL 和表单收集起来二是对这些目标做 SQL 注入、XSS 等常见漏洞的特征匹配最后输出结果到控制台和日志。对于正在做毕业设计、或者刚接触 Web 安全想动手复现的人来说这套源码的价值在于模块清楚、改动空间大你能从 crawl.py 一路读到 vul_module.py把爬取→检测→记录整条链路串起来。2. 扫描器架构拆解crawl.py 怎么爬、vul_module.py 怎么查2.1 三个入口脚本的分工run.py / vulscan.py / crawl.py解压后第一件事是分清入口。项目里出现了 run.py、vulscan.py、crawl.py 三个脚本很多第一次接触这套源码的人会以为三个都能直接跑其实它们的分工很明确。run.py 是总控入口负责读取 config.py 配置创建日志和输出目录然后调用扫描流程vulscan.py 是漏洞检测核心里面聚合了爬虫结果和漏洞检测模块crawl.py 则是网络爬虫模块负责从起始 URL 开始抓取页面、解析链接、去重、记录表单。我一般建议从 run.py 开始读因为它把整个调用关系串起来了。常见的误用是直接运行 vulscan.py结果发现没有初始化数据库或者日志目录不对报错后又回来翻 README。其实这种设计在毕业设计里很常见总控入口、核心逻辑、业务模块各拆一个文件便于答辩时讲清楚模块划分。如果你要改检测逻辑重点看 vulscan.py 和 vul_module.py要改爬虫行为就看 crawl.py要调整参数就看 config.py。文件里还有 dbms.py 这种数据库管理模块负责把扫描结果落库但基础使用时不一定非要启动它。2.2 爬虫模块基于 requests BeautifulSoup 的链接抓取与去重网络爬虫原理的核心环节就是抓页面→解析链接→去重→继续抓。这套源码的 crawl.py 走的是同样的路子依赖 requests 发 HTTP 请求用 BeautifulSoup 解析 HTML然后用一个 set 集合保存已访问 URL避免循环爬取。下面是一段经过简化的爬虫核心逻辑结构与源码里的 crawl.py 基本一致import requests from bs4 import BeautifulSoup from urllib.parse import urljoin, urlparse class Crawler: def __init__(self, start_url, max_pages50): self.start_url start_url self.max_pages max_pages self.visited set() self.forms [] def get_links(self, html, base_url): soup BeautifulSoup(html, html.parser) links set() for a in soup.find_all(a, hrefTrue): href a[href].strip() if href.startswith(javascript:) or href.startswith(#): continue full_url urljoin(base_url, href) if urlparse(full_url).netloc urlparse(self.start_url).netloc: links.add(full_url) return links def crawl(self): queue [self.start_url] while queue and len(self.visited) self.max_pages: url queue.pop(0) if url in self.visited: continue try: resp requests.get(url, timeout10) except requests.RequestException as e: print(f抓取失败: {url} - {e}) continue self.visited.add(url) html resp.text for link in self.get_links(html, url): if link not in self.visited: queue.append(link) return self.visited这里的爬虫做了三个关键动作首先用urljoin把相对链接拼成绝对链接否则很多href/xxx会被当成无效地址然后用urlparse(...).netloc判断域名是否属于目标站点避免爬到外链去最后用visited这个 set 做去重同时用max_pages限制爬取量防止把站点整个抓崩。实际使用中max_pages是第一个要调的参数。对一个小型毕业设计站点50 页足够覆盖但如果目标站点是新闻站或商城页面数量很容易超过几千这时这个参数就要调大或者改成按深度限制。另一点要注意的是requests.get默认不带浏览器请求头很多站点会直接返回 403源码里一般会在 config.py 里配置 User-Agent如果你自己重写这段逻辑最好把 headers 参数也传进去。2.3 漏洞检测模块基于正则与 payload 匹配的检测逻辑爬完链接之后真正干活的是 vul_module.py。这个模块的思路比较朴素对每个目标 URL 拼接特定 payload然后根据响应里出现的特征字符串判断是否存在漏洞。它不需要像专业扫描器那样维护复杂的插件体系而是用正则表达式在响应中找特征比如 SQL 报错信息、XSS 反射特征、目录穿越路径等。下面是一个典型的检测函数结构用 requests 发送带 payload 的请求再用正则去匹配响应内容import requests import re def check_sqli(url): payloads [, \, 1 OR 11] for payload in payloads: try: resp requests.get(url payload, timeout10) if re.search(rSQL syntax|mysql_fetch|ORA-[0-9]{3,5}|Unclosed quotation, resp.text, re.I): return True except requests.RequestException: continue return False def check_xss(url): payload scriptalert(1)/script try: resp requests.get(url payload, timeout10) if payload in resp.text: return True except requests.RequestException: pass return False逻辑说明不复杂check_sqli把单引号、双引号、布尔条件拼到 URL 后面然后用正则去匹配数据库报错特征。不同数据库的报错格式差异很大所以正则里写了 MySQL、Oracle 常见的报错片段匹配到任意一个就算可疑。check_xss更直接看 payload 是否原样出现在响应里如果页面把script原样返回说明存在反射型 XSS 的可能。这套检测逻辑的优点是好懂、好改、好答辩缺点是误报率不低。比如某些站点会把用户输入记录在页面注释里check_xss也会返回 True但实际漏洞可能只是把输入转义后显示。你在复现时一定不要把扫描结果直接当成漏洞定论后续需要人工确认。这也是这套代码作为教学项目的边界它教你识别漏洞特征但不会教你如何利用。3. 把项目跑起来环境配置、参数设置与一次真实扫描3.1 环境准备Python 版本、依赖库与目录结构项目在 Windows 10 和 11 上运行稳定但依赖基本的 Python 环境。我建议直接用 Python 3.8 到 3.11 之间的版本太老的 3.6 可能在解析某些语法时出问题太新的 3.12 则有可能遇到个别依赖包还未适配的情况。解压后你会看到这些关键文件crawl.py、vul_module.py、vulscan.py、run.py、config.py、dbms.py、log.txt、vulfile.txt、README.md 等。先安装依赖常见的做法是手动建一个 requirements.txt内容如下requests2.25.0 beautifulsoup44.9.3 selenium3.141.0 lxml4.6.0安装命令是pip install -r requirements.txt。这里要注意如果你只需要跑基础爬虫和漏洞检测selenium 其实可以暂时不装因为那是给动态页面爬取用的但源码里既然写了我建议还是装上避免后面调用时翻车。lxml 是为了让 BeautifulSoup 的解析速度更快不装的话会退回 Python 内置的 html.parser小站无所谓页面一多速度差距就出来了。装完依赖后先不要急着跑打开 README.md 看一遍里面一般写了作者测试时的环境。如果打不开或者内容不完整就去看 config.py把配置改对再启动。项目里还带了一个附赠内容压缩包通常是图片和教程可以留着后面对照着看。3.2 config.py 参数逐项说明config.py 是整个项目的总开关下面这些参数几乎决定了扫描行为先看默认值再决定改哪个参数名典型值含义start_urlhttp://127.0.0.1:8080扫描起始地址max_pages50最大爬取页面数timeout10单个请求超时时间秒user_agentMozilla/5.0 ...请求头中的 User-Agentthread_num5并发线程数save_logTrue是否写入 log.txtuse_dbFalse是否启用 dbms.py 数据库存储max_pages和timeout是基础调优参数。thread_num决定了并发请求数量调大能加快扫描速度但也会增加目标站点的压力我一般对测试站点用 3对本地靶场调到 10 也没关系。save_log建议保持 True因为扫描过程中很多信息只在日志里能看到控制台输出会做精简。use_db如果为 True扫描结束后会调用 dbms.py 把结果存进数据库需要额外安装数据库依赖这个在后面的排错章节里会提到。修改配置文件时要注意编码问题。Windows 下用记事本打开 config.py如果文件里包含中文注释保存成 UTF-8 格式没问题但如果原来是 GBK 保存的直接改会导致 Python 解释器报编码错误。我习惯用 VS Code 打开右下角能直接看到编码格式统一改成 UTF-8 再保存。3.3 执行 vulscan.py 的完整过程与输出解读配置改好之后进入项目目录执行扫描命令。常见的启动方式是python run.py --config config.py如果嫌命令长也可以直接运行python vulscan.py。但建议用 run.py因为这套源码的调用链是 run.py 先初始化日志和数据库再调用 vulscan.py 的扫描主函数直接跑 vulscan.py 有时候会跳过日志初始化导致后面 log.txt 是空的。扫描启动后你会看到类似下面的输出[INFO] 目标站点: http://127.0.0.1:8080 [INFO] 爬虫开始抓取链接... [INFO] 已发现链接: 12 [INFO] 开始检测SQL注入... [WARN] 发现可疑SQL注入: http://127.0.0.1:8080/news.php?id1 [INFO] 开始检测XSS... [WARN] 发现可疑XSS: http://127.0.0.1:8080/search.php?kwtest [INFO] 扫描完成总计发现 2 个可疑点每一行输出都对应一个检测阶段。已发现链接: 12表示爬虫只抓到了 12 个 URL如果目标站点的链接远不止这些说明爬虫被反爬拦住了或者只爬到了首页。可疑SQL注入后面的 URL 就是拼接了 payload 后返回异常特征的地址这里要注意它说的是可疑不代表漏洞百分百存在。扫描过程中如果某个请求耗时过长程序一直卡住不动多半是timeout参数不合理。增大timeout不一定是好事对慢站点可能只是网络问题但对本地测试站点10 秒已经足够。扫描结束后去项目目录下看 log.txt里面记录的是每次请求的详细状态和响应码这份日志比控制台输出更值得逐行读很多问题都在这里暴露。4. 常见问题与避坑记录从 dbms.py 到 log.txt 的排查路径4.1 现象扫描器启动后空白、无链接入账运行 run.py 后没有任何输出或者只显示开始扫描就卡住打开 log.txt 却看到大量连接超时记录。这种现象通常不是代码问题而是目标站点根本连不上。最常见的原因是 start_url 配置成了无法访问的地址或者本机代理导致 requests 走了错误的代理隧道。解决方式是先确认能不能在浏览器里正常打开目标站点然后在命令行执行curl -I http://127.0.0.1:8080看响应头。如果 curl 正常而 Python 请求超时检查环境变量里的 HTTP_PROXY 和 HTTPS_PROXY把代理清掉再跑。4.2 现象SQL注入检测大量误报扫描结果里 SQL 注入标红一大片但人工访问这些 URL 发现都是正常页面。原因通常是正则特征写得太宽比如 SQL syntax 可能出现在站点自己的错误提示文档里或者某些 CMS 模板把关键字写死在页面代码中。解决方法是打开 vul_module.py把check_sqli里的正则收紧比如只匹配数据库版本特征MySQL [0-9]\.[0-9]或更明确的报错词。另一个办法是增加二次验证逻辑对一个候选 URL 发送两次不同 payload只有两次都触发特征才记为漏洞。我后来都是直接改源码把误报高的特征词从正则里删掉。4.3 现象Selenium 无法启动或卡死源码里如果配置了动态页面爬取会调用 selenium但很多人第一次跑就报 WebDriver 找不到。原因很简单selenium 本身只是客户端还需要对应浏览器的驱动程序比如 Chrome 要装 chromedriver而且版本必须和浏览器大版本匹配。解决方式是先执行python -c import selenium; print(selenium.__version__)确认安装再下载对应版本的驱动把驱动所在目录加到系统 PATH 里。如果驱动版本正确但浏览器启动后一直白屏检查是否启动了无头模式推荐加--headless参数运行能减少很多环境兼容问题。4.4 现象log.txt 不写入或乱码扫描结束后 log.txt 文件还是空的或者里面全是锟斤拷这类乱码。空日志的原因一般是 run.py 里的日志初始化被跳过或者 save_log 参数被改成了 False。乱码则是写入编码问题Python 在 Windows 下默认使用 GBK 编码写文件如果 log.txt 里写入的中文用了 UTF-8 编码记事本打开就会乱码。解决方式是打开 run.py 或对应日志模块找到open(log_file, w, encodingutf-8)这样的代码把编码明确指定为utf-8。如果对日志格式没要求直接把输出改成纯英文也能避开这个问题。4.5 现象dbms.py 报错导致服务中断把 use_db 设为 True 后扫描结束时报ImportError: No module named pymysql或数据库连接失败。这套源码里的 dbms.py 负责把扫描结果写入数据库依赖常见的 MySQL 驱动但很多人环境里根本没有装。解决方式是先看清楚 dbms.py 里 import 的是哪个库如果是 pymysql 就执行pip install pymysql如果是 MySQLdb 则需要安装 mysqlclient。如果你只是做毕业设计演示建议先保持 use_dbFalse把结果输出到 log.txt 和控制台就够了等核心逻辑跑通后再接数据库。5. 二次开发把爬虫和漏洞检测能力变成自己的工具5.1 改造 crawl.py增加登录态与自定义请求头原版爬虫默认是匿名访问遇到需要登录的后台页面就只能干瞪眼。常见的做法是给 Crawler 类增加一个 headers 字典里面放 Cookie 或 Authorization 字段然后在requests.get时传进去。比如你需要在扫描时保持登录状态可以这样改def __init__(self, start_url, max_pages50, cookiesNone): self.session requests.Session() if cookies: self.session.cookies.update(cookies) self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Accept-Language: zh-CN,zh;q0.9 })以后每次请求都用self.session.get(url)而不是requests.get这样 Session 会自动携带 Cookie 和请求头。要注意的是加了登录态以后爬虫的行为会更接近真实用户但也更容易触发站点的反爬机制所以务必控制请求频率在循环体里加一个time.sleep(1)之类的限速。5.2 扩展 vul_module.py添加新的漏洞类型原版漏洞模块只覆盖 SQL 注入和 XSS如果你想把目录穿越、文件包含这类漏洞也加进去可以按照已有的函数模式写。比如增加一个检测目录穿越的函数def check_traversal(url): payloads [../../../../etc/passwd, ..\\..\\..\\Windows\\win.ini] for payload in payloads: try: resp requests.get(url / payload, timeout10) if root: in resp.text or [extensions] in resp.text: return True except requests.RequestException: continue return False写完函数后记得回到 vulscan.py 的主流程里找到遍历目标时调用的那段代码加上check_traversal(url)的判断并把结果写入日志。这里有个容易踩坑的地方目录穿越的路径拼接要看目标站点的路由规则你是拼在 URL 末尾还是替换掉某一段路径直接决定检测效果。多试几种 payload 是常态别指望一个 payload 打遍所有站点。5.3 与数据库联动dbms.py 的存储设计原版的 dbms.py 已经预留了数据库存储接口但默认不启用。如果你想在答辩时展示数据库交互可以先手动建一张表把扫描结果存进去。一个简单的表结构设计如下CREATE TABLE scan_results ( id INT AUTO_INCREMENT PRIMARY KEY, url VARCHAR(500) NOT NULL, vul_type VARCHAR(50) NOT NULL, detail TEXT, scan_time DATETIME DEFAULT CURRENT_TIMESTAMP );然后在 dbms.py 里写一个save_result(url, vul_type, detail)函数用 pymysql 连接本地数据库执行 INSERT 语句。需要注意数据库连接参数和 config.py 里的配置保持一致密码不要写死从配置里读取。数据库的好处是可以配合前端做可视化但如果你不熟悉 SQL建议先把基础扫描流程跑熟数据库只是个加分项不是必选项。6. 验证扫描结果与进阶用法让结果可信、可复现拿到扫描结果后第一件事不是急着写报告而是验证。我习惯的做法是搭一个本地靶场比如 DVWA 或者 Pikachu里面有很多已知漏洞的测试页面用这套工具去扫看能不能稳定复现出已知问题。如果扫出的结果和靶场页面完全对不上那八成是检测逻辑或配置有问题如果对上了说明这套工具在你手里已经过关了。验证时注意控制变量起始 URL 只填一个已知漏洞页面不要全站扫描登录态关闭避免触发反爬max_pages设成 10让扫描快速完成。记录每次扫描的耗时和结果数量多次对比。如果两次扫描同一个页面结果不一致检查是否启用了并发线程并发请求会导致顺序错乱日志里对不上的概率也会增加。我后面给项目加了一个简单方法每次扫描前启动 Python 内置的随机数种子固定让爬虫访问顺序保持一致这样复现更容易。进阶用法里最实用的一条是给扫描加输出报告。原版只输出到控制台和 log.txt我一般会把结果写到 Markdown 文件里便于直接粘贴到项目文档中。实现思路不难扫描完成后把结果列表逐行写入.md文件加上表格头读者一眼就能看清漏洞 URL、类型、特征。这个做法不改变原有架构只是在 run.py 的收尾阶段加几十行代码。我从这套源码里学到的最大教训是先复现再谈扩展。第一次拿到压缩包我直接跳到加漏洞类型结果连官方示例站点都扫不出东西最后发现是 User-Agent 没配、目标站点返回了 403。从那以后我每拿到一个工具项目都会强制走一遍最小化扫描流程配置干净参数→扫一个已知漏洞靶场→看日志确认请求真实发出走完这一步才开始改代码。希望这个流程也能帮到你少走几段弯路。本文还有配套的精品资源点击获取