简介基于Python与Django实现的Web渗透测试工具毕业设计项目面向网络安全、计算机相关专业学生及开源安全工具开发者可用作毕设参考、课程设计或二次开发起点。内容覆盖论文与代码全流程涉及研究背景、系统可行性分析、SQL注入漏洞原理与危害、端口扫描、Web漏洞测试等模块并附带答辩演示视频与数据库文件。资源共2000个文件压缩包约577MB。以275个Python源码和197个pyc编译文件为核心配套HTML/CSS/JS前端页面、PNG/JPG图片、日志、SQL及sqlite3数据库等类型便于直接还原运行环境。文档含docx、pdf等格式论文全文。目录按论文章节组织可逐模块对照学习。已有1766人学习下载。整体提供可运行的源代码、数据库、演示视频、论文摘要与结论从后台逻辑到前端展示均有覆盖适合需要完整毕业设计参考方案或快速上手Django安全项目的人员。1. 拿到“基于 python 的 web 渗透测试工具django”这套毕设 zip先搞清楚它到底解决什么问题答辩现场老师最常问的一句话是“你这个 web 渗透测试工具的扫描核心是你自己写的还是调了别人的轮子”很多拿 django 做安全类毕设的同学都在这里翻车。原因很简单这类 zip 极少给你讲清楚“web 壳”和“扫描引擎”是怎么分工的——django 负责接收 URL、管理任务、展示报告python 写的那套探测逻辑才是真正的核心。如果只把页面做漂亮扫描部分是拼凑的答辩一深问就散了。这套项目要解决的事情可以用一句话概括把渗透测试里重复性最高、最适合自动化的步骤目标探测、端口服务识别、敏感文件检查、URL 参数风险检测做成一个可多人使用、可追溯过程、能导出报告的 web 平台。它适合三类人一是需要交毕业设计的计算机/网安专业学生二是想用 django 练手“任务型系统”的 python 后端初学者三是企业内部需要做授权范围内漏洞巡检的安全工程师。你要明白一点zip 里的源码只是起点真正值钱的是你能把“任务调度、结果入库、进度推送”这条工程链路讲清楚这才是它和课程作业的区别。2. 把工具拆成“Web 壳 扫描引擎”两半django 项目架构的复用点在哪2.1 为什么用 django 而不是 Flask后台任务和后台管理决定了选型先说结论做 web 渗透测试工具这类“任务型系统”django 比 Flask 合适。Flask 轻适合写 API但你的毕设里要有用户登录、任务历史、结果列表、报告导出这几块Flask 全都要自己拼。django 自带 Admin 后台、ORM、表单校验、模板引擎等于把“管理类系统”的地基打好了你只需要在它上面盖扫描引擎这层楼。我一般建议项目里先建三个 app而不是把所有逻辑塞在一个 views.py 里。常见的做法是这样的拆分web_scan_app负责目标录入、任务创建、结果展示等 web 交互scan_engine负责实际的探测逻辑不依赖 django 的请求/响应生命周期reports负责把 scan_result 表的数据生成 PDF 页面或 HTML 报告。这样做的好处是扫描引擎部分可以脱离 django 独立测试。你在终端直接python scan_engine/plugins/header_check.py --url http://127.0.0.1:8000就能跑不用每次开浏览器。这也是答辩时能拿出来讲的“解耦设计”。django-admin startproject web_pen_test . python manage.py startapp scan_engine python manage.py startapp web_scan_app python manage.py startapp reports代码块里的三个 app 划分对应的是“任务管理、扫描逻辑、报告输出”三条职责线。注意我没有把扫描逻辑放在 web_scan_app 下因为那样会导致视图函数里塞一大坨 requests 请求逻辑后面加定时任务或者换异步框架时特别痛苦。2.2 数据库表设计这几张表决定了毕设能讲多少东西很多新手拿到的项目里只有一个表把目标 URL 和扫描结果塞在一行里这种设计答辩时会被老师一句话问穿“如果一个目标扫出 30 个风险点你这一行怎么查”所以表结构至少要按目标、任务、结果、插件四层拆分。表名作用关键字段备注scan_target扫描目标url、protocol、host、allow_scanallow_scan 表示该目标是否已获得授权,建议默认 Falsescan_task一次完整的扫描任务task_id、target 外键、status、progressstatus 取 pending/running/finished/failedscan_result单条风险记录task 外键、plugin_name、severity、url、detailseverity 分 low/mid/highscan_plugin插件注册表plugin_name、description、enabled没这张表后期加插件只能改代码scan_plugin表是很多毕设项目没有的。它的核心价值是让扫描逻辑可扩展你想加一个新检测项时只需要往表里插一条记录然后在scan_engine/plugins/目录下加一个同名函数扫描器运行时按表里 enabled 为 True 的插件名去动态加载。这就是一个最小的插件化设计。from django.db import models import uuid class ScanTarget(models.Model): name models.CharField(max_length255, verbose_name目标名称) base_url models.URLField(verbose_name待测地址) allow_scan models.BooleanField(defaultFalse, verbose_name授权状态) created_at models.DateTimeField(auto_now_addTrue) class ScanTask(models.Model): task_id models.UUIDField(defaultuuid.uuid4, editableFalse, uniqueTrue) target models.ForeignKey(ScanTarget, on_deletemodels.CASCADE) status models.CharField(max_length20, defaultpending) progress models.IntegerField(default0) started_at models.DateTimeField(nullTrue, blankTrue) finished_at models.DateTimeField(nullTrue, blankTrue)uuid做任务 ID比自增 id 好。原因是扫描任务对外展示时URL 里会出现任务号如果直接用自增 id别人可以遍历?task_id1,2,3偷看任务记录。UUID 虽然不能完全防猜测但毕设和实际使用上都体面得多。on_deletemodels.CASCADE表示删除目标时关联任务一并清理避免脏数据。2.3 任务流程从提交 URL 到出报告的完整链路把一次扫描拆成五步每步对应一个函数这是整个项目里最值得在答辩时画出来的“链路图”用户提交http://192.168.x.x:8080到表单先做 URL 合法性校验校验通过后创建ScanTask记录状态为 pending后台任务池取出任务把状态改为 running开始按插件顺序检测每个插件返回一组结果分批写入ScanResult表全部执行完任务状态改为 finished前端跳转结果页。from django import forms from urllib.parse import urlparse class TargetForm(forms.ModelForm): class Meta: model ScanTarget fields [name, base_url] def clean_base_url(self): base self.cleaned_data[base_url] if not base.startswith((http://, https://)): raise forms.ValidationError(必须带上 http:// 或 https:// 协议头) host urlparse(base).hostname if not host: raise forms.ValidationError(无法解析出主机名) return base这段表单校验是第一个坑的防线。很多人直接拿用户输入的字符串去拼接 URL输入javascript:alert(1)或者不带协议的域名requests 库会报一堆莫名其妙的异常。urlparse把 host 提取出来既是为了后续拼接路径方便也是在流程第一步拦截非法目标。allow_scan字段我在演示环境里会主动置为 True但在正式使用场景应当有“管理员审核授权”这一步而不是让任意注册用户随便扫外网地址。3. 扫描引擎的落地实现从接收 URL 到输出报告的骨架代码3.1 目标预检先做连通性检查再做探测扫描引擎启动后第一步不是上插件而是做基础连通性探测。这一步要区分“目标不可达”和“目标无风险”两种状态否则后面所有插件都在浪费时间。import requests def probe_target(base_url, timeout(5, 10)): 探测目标是否可达返回 (status_code, headers, error) try: resp requests.get( base_url.rstrip(/) /, timeouttimeout, allow_redirectsTrue, headers{User-Agent: Mozilla/5.0 (Study Project)} ) return resp.status_code, dict(resp.headers), None except requests.exceptions.ConnectTimeout: return None, None, 连接超时 except requests.exceptions.ConnectionError: return None, None, 目标拒绝连接这里有两个参数值得解释。timeout(5, 10)是 requests 的元组写法前一个值是连接超时后一个是读超时如果你的扫描目标在内网5 秒连接超时足够如果扫描公网资产建议放宽到 8 秒。allow_redirectsTrue是因为很多站点访问根路径会 302 跳到首页或登录页如果不开你会把 302 当成一个“异常状态”误报进结果表里。预检通过后的结果不建议直接入库而是存在一个ScanContext对象里后续插件共用。这个对象里可以放 base_url、session、目标 host、初始 cookie。用同一个requests.Session()的好处是保持连接复用扫描大量路径时不会每次都重新握手速度差距在百级路径时非常明显。3.2 任务引擎用线程池跑插件别在视图里直接 wait新手最容易犯的错是在 django 视图函数里直接调用扫描逻辑然后前端 fetch 这个接口等 3 分钟。浏览器早就超时了而且 uwsgi 的 worker 会被占满。正确的做法是把扫描任务丢进一个后台队列视图立刻返回“任务已创建”前端再定时轮询任务状态。import queue import threading from scan_engine.runner import run_scan_task task_queue queue.Queue() WORKERS 3 def worker_loop(): while True: task_id task_queue.get() if task_id is None: break try: run_scan_task(task_id) finally: task_queue.task_done() def start_workers(): for _ in range(WORKERS): t threading.Thread(targetworker_loop, daemonTrue) t.start()把start_workers()放到AppConfig.ready()里这样 django 启动时线程池就跟着起来。三个 worker 意味着最多同时跑三个扫描任务再多就在队列里排队。毕设规模用 threading 完全够如果你想写成生产级可以换 Celery/Huey但要额外起 Redis复杂度会上去。答辩时能说清楚“为什么不用 Celery”比被反问“这是什么”更有优势。线程池方案真正的坑在 django ORM 的连接管理。每个线程默认共享主线程的数据库连接扫描任务跑久了会报MySQL server has gone away或者 sqlite 的 database is locked。解决办法是每个任务开始时调用django.db.close_old_connections()用完数据库立即关掉旧连接强制下次重新建立。3.3 插件化扫描逻辑每个检测项是一个独立的纯函数插件设计是整个引擎最好讲、也最容易扩展的部分。以“敏感文件检查”为例它只是按字典路径列表发起 GET然后根据状态码和页面内容判断风险。from urllib.parse import urljoin import requests SENSITIVE_PATHS [ /.git/HEAD, /.env, /WEB-INF/web.xml, /.svn/entries, ] def check_sensitive_files(ctx): 检查敏感文件是否可访问返回风险记录 list findings [] session ctx.session for path in SENSITIVE_PATHS: url urljoin(ctx.base_url, path) try: resp session.get(url, timeoutctx.timeout, allow_redirectsFalse) except requests.RequestException: continue if resp.status_code in (200, 403): findings.append({ plugin_name: sensitive_file_check, severity: high if resp.status_code 200 else mid, url: url, detail: f敏感文件疑似可访问状态码 {resp.status_code} }) return findings为什么要allow_redirectsFalse因为 302 本身是一个中间状态如果开了自动跟随/WEB-INF/web.xml跳到登录页然后返回 200会产生误报。这里只看 200并且只对高价值路径报警。403 标记为 mid 是因为服务器存在该路径但禁止访问也可能仅是默认拒绝规则需要人工复核。每个插件函数都接收ctx返回一个list[dict]。主调度器拿到所有插件的返回结果后统一入库。这样设计之后新增一个检测插件只需要三步在scan_engine/plugins/下新建 py 文件、在scan_plugin表里插记录、重启 worker。3.4 结果批量入库不要在循环里逐条 save扫描路径多的时候一个插件可能返回几百条结果。如果你在 view 里for item in findings: ScanResult.objects.create(...)扫 300 个路径就要打开关闭 300 次数据库事务插入速度慢到肉眼可见。from scan_engine.models import ScanResult def save_results(task, findings): objs [ ScanResult( tasktask, plugin_namef[plugin_name], severityf[severity], urlf[url], detailf[detail], ) for f in findings ] ScanResult.objects.bulk_create(objs, batch_size100)bulk_create只发一条 INSERT 语句把数据批量写入batch_size100防止单条 SQL 过长。这一步对 sqlite 和 mysql 都有效实测 3000 条结果从 30 秒降到 2 秒左右。注意 bulk_create 不像 save 那样会触发模型的save()方法所以如果你的 ScanResult 里有自定义信号用 bulk_create 时不会触发别在这种场景依赖信号。4. 扫描结果页与进度推送web 端最值得写的部分4.1 用 WebSocket 推送扫描进度结果页如果靠用户手动刷新体验比较原始。django 里做实时进度标准方案是 Channels它在 django 外面包了一层 ASGI允许长连接推送消息。从标题这个项目来看能实现“任务进度实时展示”是亮点大多数毕设只做轮询那就会在“不够工程化”这一条上被扣印象分。# routing.py from django.urls import path from .consumers import TaskProgressConsumer websocket_urlpatterns [ path(ws/task/uuid:task_id/, TaskProgressConsumer.as_asgi()), ]# consumers.py import json from channels.generic.websocket import WebsocketConsumer class TaskProgressConsumer(WebsocketConsumer): def connect(self): self.task_id self.scope[url_route][kwargs][task_id] self.accept() def send_progress(self, percent, message): self.send(text_datajson.dumps({ progress: percent, message: message }))后端 worker 每完成一个插件检查就把进度推进一格。前端用new WebSocket(ws:// location.host /ws/task/ task_id /)监听在 onmessage 里更新进度条。这里有个需要注意的事Channels 的 GraphQL 和普通请求在同一个端口上是兼容的但你本地如果用python manage.py runserver测试 WebSocket必须确保装了 channels 并配置好ASGI_APPLICATION否则会一直走 WSGI 处理 websocket连不上。如果不想引入 Channels折中方案是进度下拉取接口api/task/task_id/progress/返回{“progress”: 42}前端 setInterval 每 2 秒拉一次任务结束就 clearInterval。两种方案我建议至少实现 WebSocket 那一版因为它的连贯性和“实时代”观感在演示视频里效果差很多。4.2 报告导出PDF 和独立报告页一页都不能少报告是安全工具的价值出口。没有报告的扫描工具就像没有化验单的体检中心。导出 PDF 在 django 里最省事的方式是先用 HTML 模板渲染结果再用weasyprint转 PDF。from django.template.loader import render_to_string from django.http import HttpResponse import tempfile def export_report(request, task_id): task ScanTask.objects.get(task_idtask_id) findings task.results.all().order_by(-severity) html render_to_string(reports/report_template.html, { task: task, findings: findings }) with tempfile.NamedTemporaryFile(suffix.html, deleteFalse) as f: f.write(html.encode(utf-8)) # 此处调用 weasyprint 把 html 转成 pdf_bytes pdf_bytes html_to_pdf(html) response HttpResponse(pdf_bytes, content_typeapplication/pdf) response[Content-Disposition] fattachment; filenamereport_{task_id}.pdf return responseContent-Disposition直接决定浏览器是打开还是下载。文件名最好带 task_id这样导出多份报告时不会互相覆盖。weasyprint 在 Windows 上需要装 GTK 库很多同学栽在这里如果你不想折腾改两行代码直接返回 HTML 页面打印成 PDF 也是可以的——用window.print()让浏览器用户自己“另存为 PDF”在本地演示完全够用。哪天答辩老师问“为什么不用 itext 生成 PDF”你可以答用 weasyprint 转换避免手动排版后期模板改动成本低这个回答是站得住的。我一般建议表格里的 severity 字段在模板里按 high/mid/low 分别显示红橙黄背景色顶部再加一个统计卡片高风险 N 条、中风险 N 条、低风险 N 条评审看报告第一眼就有结论比密密麻麻的列表舒服很多。5. 毕设级安全工具的避坑记录从部署到答辩的 5 个真实翻车点5.1 现象扫描任务跑一半就卡死页面一直转圈原因requests 没有设置 timeout也没有把每个任务运行包在异常处理里。目标服务器的一个端口不响应请求默认会挂到系统超时任务线程被拖死队列后面所有任务都排队。解决所有请求方法统一传入timeout(5, 8)在 worker 循环里用 try/except 包住整个run_scan_task任何异常都记录 task.status failed 并保证任务从队列中移除。另外给每个线程设置 daemonTrue主进程退出时线程随之退出避免 supervisor 重启 django 时残留僵尸线程。5.2 现象扫描结果里出现大量“200 OK”误报原因目标站点根路径有登录页所有不存在的路径都被统一返回 200 的 SPA 页面或软 404。例如 Vue 项目配 history 路由/.env这个路径也会 200 回首页内容。解决不能只看状态码要同时校验内容。检查响应体的 title、关键字或长度。比如访问/.git/HEAD如果返回 200 但页面标题是“用户登录”那大概率是软 404不该入库。把判断逻辑从“状态码200”升级为“状态码200 且 内容包含指定标识”。这一步一改误报率能降一半。扫到一个路径后把它返回给前端时增加一个“手工复核”标记比直接下漏洞结论更稳妥。5.3 现象数据库连接耗尽任务一多就报异常原因线程池里每个 worker 用的都是 django 启动时创建的数据库连接。长任务跑十分钟后MySQL 服务端关闭了空闲连接ORM 再操作就报错。sqlite 则直接出现 database is locked。解决在每次任务开始和结束时调用一次from django.db import close_old_connections; close_old_connections()。线程内所有 ORM 查询之间间隔太久时也建议显式关一下。这个操作成本极低但能避开绝大多数生产环境才出现的玄学问题。5.4 现象演示视频里的界面和 zip 里跑出来的完全不一样原因源码包和演示视频没对齐版本。视频里数据库有 20 条演示数据zip 解压后 migrate 只给了空表视频里用的 python 3.8本机装的是 python 3.11某个依赖库 api 变了导致页面样式错乱。解决收到任何源码包第一步不要直接跑先看有没有 requirements.txt。没有就把项目里 import 的库列进一份。然后一定要做一次“干净环境测试”换一台没装过任何 python 包的机器新建虚拟环境按 README 一步步跑通。跑通后再录一版新的演示视频。答辩演示翻车九成是环境依赖问题而不是功能 bug。5.5 现象图片和 CSS 加载不出来扫描结果页只剩导航栏原因django 的 DEBUGFalse 时不再托管静态文件。开发时你开着 DEBUG 没感觉一旦为了演示视频把DEBUGFalse改了所有/static/请求全部 404。解决临时用python manage.py runserver --insecure跑演示环境让 django 强制提供静态文件或者正规一点python manage.py collectstatic后用 whitenoise 中间件托管。毕设答辩通常不需要上生产 nginx所以 whitenoise 一行配置就能解决别在这上面浪费时间。把DEBUG这个值在部署环节单独说清楚就好了。6. 把工具升级成“安全评估平台”三个成本低但加分多的改造方向第一个方向是给任务加“授权触发条件”。做一个带 token 的部署模式在目标详情页生成一段探测字符串要求目标方把它放在站点根目录来证明所有权检测器随后去验证这段字符串存在后才允许执行扫描。这个功能在真实的安全评估业务里叫“所有权验证”只要二三十行代码但答辩老师一看就知道你的工具不是玩具而是考虑过合规边界的。第二个方向是定时基线对比。在 ScanTask 里加一个schedule_type字段支持 weekly/daily用 django-crontab 或系统 crontab 跑一个命令python manage.py run_scheduled_scans --target 3。每次扫描结果和上次结果做 diff只在前台突出“新增问题”和“已修复问题”。代码量不大但它把工具从“一次性扫描器”变成“持续监控系统”这是安全运营里最常讲的词用在毕设概念里非常拉分。第三个方向是结果聚合视图。现在多数工具给的是扁平列表升级做法是加一个仪表盘页用 Chart.js 展示近 30 天各类漏洞数量趋势severity 分布饼图最后一个表格列 Top 10 问题 URL。这类改造不碰扫描引擎只加查询接口和前端组件工作量很低但对“项目完整性”的观感提升非常明显。验证方法上有一条我自己的习惯每完成一次改动先在终端跑一遍python manage.py test scan_engine.tests没有测试就把核心函数单独调一遍。你不必写完整测试套件但至少要给probe_target和save_results各写一个最小用例因为这两个函数一边是入口一边是出口它们崩了整个项目就瘫了。如果你打算把源码放博客仓库那顺手补一版docker-compose.yml把 mysql 和 django 编排起来让人一条命令跑起来对你和读者都有好处。希望这些经验帮到你也提醒一句这类工具做演示前永远记得先跑一遍完整流程再录像玄学往往藏在最后一次改动里。本文还有配套的精品资源点击获取