Django漏洞扫描系统源码解析：从搭建到二次开发

简介：这是一套基于Django框架与Python实现的漏洞扫描系统完整源码，面向计算机、信息安全、数据科学等专业的在校学生、教师及企业员工，可用于课程设计、期末大作业、毕业设计或初期项目立项演示。资源包共441个文件，以146个py源码、68个html模板、42个js脚本及scss、css、less等前端样式文件为主，另含sql数据库脚本、json配置、bat启动脚本与项目说明文档，压缩包约8.46MB，目录结构清晰，便于按模块检索学习。系统覆盖主机漏洞扫描、Web网页漏洞扫描、数据库管理、用户交互、漏洞报告、用户管理、日志记录与修复评估等模块，包含端口扫描、服务识别、XSS与SQL注入检测、报告生成下载等完整功能，代码经运行验证，稳定可靠。目前已有320人学习下载，适合小白入门进阶，也可作为二次开发与功能DIY的参考基础。

1. 从一份 Django 漏洞扫描系统源码说起：它能帮你省下多少搭建时间

如果你正在做课程设计、期末大作业或者毕业设计，选题又恰好落在「Web 安全」和「Python 后端」的交叉点上，那这套基于 Django 框架加 Python 实现的漏洞扫描系统源码，大概率能让你少熬几个通宵。它不是那种只跑一个print("hello")的玩具 demo，而是一套带 SQL 数据库、带详细项目说明的完整工程：有 Web 管理界面、有扫描任务调度、有结果落库、有报告展示。你拿到手之后，需要做的不是从零设计表结构、从零写路由，而是理解它的扫描流程，把环境跑通，再按自己的选题要求做二次调整。

我见过太多同学在「漏洞扫描」这个题目上翻车，原因往往不是算法多难，而是工程链路太长——Django 的 app 怎么建、SQL 数据库怎么初始化、扫描模块怎么和 Web 层解耦、任务状态怎么回写。这套源码的价值就在于，它把这条链路已经串好了，你拿到的是一个能跑起来的骨架，而不是一堆散落的函数。接下来我会按「它是什么 → 怎么跑起来 → 坑在哪 → 怎么改成你自己的」这个顺序，把这份资源拆开讲清楚。

2. 拆开这套 Django 漏洞扫描系统：模块划分与 SQL 表结构设计

2.1 为什么用 Django 而不是 Flask 来做扫描系统

漏洞扫描系统的本质是一个「任务管理 + 结果存储 + 报告展示」的 Web 应用，扫描逻辑本身可以独立成模块，但外围的任务调度、用户管理、结果查询、权限控制，都是典型的 CRUD 场景。Django 自带 ORM、Admin 后台、用户认证和表单系统，这些恰好是扫描系统最耗时的外围部分。用 Flask 的话，你得自己选 ORM、自己搭后台、自己写登录，工作量会翻倍。

另一个现实原因是课程设计和毕业设计的评审老师通常认 Django 的「工程完整度」。Django 的settings.py、urls.py、models.py、views.py这套结构清晰，答辩时容易讲清楚分层。这套源码就是按标准 Django 项目组织的，常见做法是分成scanner（扫描核心）、web（界面与接口）、accounts（用户）几个 app，SQL 数据库用 MySQL 或 SQLite 承载扫描结果。

2.2 核心数据表与字段设计

扫描系统的数据库设计决定了后面查询和报告能不能做。这套源码里通常会有几张关键表，我按常见实现整理成下面这张对照表，你拿到源码后可以先去models.py里核对：

设计上最容易出问题的是scan_result和scan_task的关联。如果一条任务扫出几百条结果，用外键关联查询时一定要加索引，否则报告页面会慢到你以为程序卡死。常见做法是在task_id和risk_level上建联合索引，SQL 层面就是CREATE INDEX idx_task_risk ON scan_result(task_id, risk_level);。

2.3 扫描模块与 Web 层的解耦方式

这套源码里扫描逻辑一般不会直接写在views.py里，而是抽成一个独立的scanner模块，Web 层只负责创建任务和读取结果。典型调用链是：前端提交目标 → view 创建scan_task记录 → 后台线程或定时任务执行扫描 → 扫描器把结果写入scan_result→ 前端轮询任务状态。

这种解耦的好处是，你可以单独测试扫描器，不用每次都启动 Django。我一般会先写一个run_scanner.py脚本，直接调用扫描模块，确认能出结果之后，再接到 Web 层。下面是一个常见的扫描入口写法：

# scanner/engine.py import requests from .rules import SQLI_PAYLOADS, XSS_PAYLOADS def scan_url(target_url, timeout=5): """对单个 URL 执行基础漏洞探测，返回结果列表""" findings = [] # SQL 注入探测：拼接常见 payload，观察响应差异 for payload in SQLI_PAYLOADS: test_url = f"{target_url}?id={payload}" try: resp = requests.get(test_url, timeout=timeout) # 命中数据库报错特征则判定为疑似注入 if any(err in resp.text for err in ["SQL syntax", "mysql_fetch", "ORA-"]): findings.append({ "vuln_type": "sql_injection", "risk_level": 3, "payload": payload, "evidence": resp.text[:200], }) except requests.RequestException: continue return findings

这段代码的逻辑很直白：遍历 payload 列表，拼到参数上发请求，然后看响应里有没有数据库报错特征。参数说明上，timeout别设太大，扫描系统最怕一个请求卡住整个任务；risk_level用整数是为了后面排序和统计方便。实际源码里规则会更丰富，可能还包括 XSS、目录遍历、敏感文件泄露等，但结构基本一致。

提示：扫描模块里所有网络请求都要加超时和异常捕获，否则一个不可达的目标就能让整个任务挂起。

3. 把源码跑起来：环境搭建、数据库初始化与首次扫描

3.1 Python 与 Django 环境准备

拿到源码后第一步不是急着runserver，而是先确认 Python 版本和依赖。这套项目一般要求 Python 3.8 以上，Django 版本看requirements.txt。如果你机器上还没有 Python，去官网下载安装包时记得勾选「Add Python to PATH」，否则后面命令行里python会提示找不到。安装完用下面几条命令确认环境：

python --version pip --version # 建议在项目目录下创建虚拟环境，避免污染全局包 python -m venv venv # Windows 激活 venv\Scripts\activate # macOS / Linux 激活 source venv/bin/activate

虚拟环境这一步很多人嫌麻烦跳过，结果就是 Django 版本和系统里其他项目冲突，报一堆ImportError。我一般会强制走一遍虚拟环境，后面装依赖才不会互相打架。激活之后安装依赖：

pip install -r requirements.txt # 如果源码没带 requirements，常见核心依赖是这些 pip install django requests pymysql

pymysql是因为很多 Django 项目连 MySQL 时用它做驱动，如果你用 SQLite 就不需要。装完之后可以在settings.py里确认DATABASES配置，SQLite 的话直接指向一个.db文件即可。

3.2 数据库初始化与迁移

Django 的数据库初始化靠迁移命令，这一步是把models.py里的表结构同步到 SQL 数据库。常见操作顺序是先生成迁移文件，再执行迁移：

# 生成迁移文件，app 名按源码实际填写，比如 scanner python manage.py makemigrations scanner # 执行迁移，创建数据表 python manage.py migrate # 创建后台管理员账号，用于登录 Admin python manage.py createsuperuser

makemigrations只负责根据模型生成 SQL 语句，migrate才真正执行。如果你改了models.py里的字段，比如给scan_result加了一个evidence字段，必须重新走一遍这两条命令。翻车最多的情况是只跑了makemigrations没跑migrate，然后启动服务发现表不存在，报no such table。

注意：如果源码自带.sql文件，说明作者可能已经导出了建表语句。你可以选择用migrate自动建表，也可以手动执行 SQL 脚本，但两者别混用，否则表结构会对不上。

3.3 启动服务并执行第一次扫描

数据库就绪后，启动开发服务器：

python manage.py runserver 0.0.0.0:8000

浏览器打开http://127.0.0.1:8000，一般会看到登录页或任务列表页。用刚才创建的超级用户登录后台，先建一个扫描任务，目标填一个你有权限测试的地址，比如自己搭的本地靶场。提交后观察任务状态变化，如果一直是pending，说明后台执行线程没起来，需要检查源码里任务调度的部分。

第一次扫描建议选一个简单目标，比如本地起的 DVWA 或自己写的测试页面，别一上来就扫真实站点。扫描完成后去结果页看有没有数据落库，如果页面空白但数据库里有记录，那就是模板渲染或查询条件的问题。这一步跑通，整套系统的核心链路就算打通了。

4. 避坑与排查：扫描任务不执行、结果不落库的常见原因

4.1 任务状态一直停在 pending

现象是提交任务后，列表里状态永远是待执行，没有任何结果。原因通常是源码里的扫描触发方式依赖后台线程或定时任务，而你在开发模式下没有启动对应的 worker。有些实现用threading.Thread直接起线程，有些用 Celery。如果是前者，检查views.py里创建任务后有没有调用thread.start()；如果是 Celery，需要额外启动celery -A 项目名 worker。解决办法是先看项目说明里有没有写启动命令，没有的话去tasks.py或views.py里找触发点。

4.2 扫描结果写入时报字段长度超限

现象是扫描能跑，但一到写库就抛异常，提示Data too long for column。原因是evidence或payload字段设了CharField(max_length=200)，而实际响应内容远超这个长度。解决办法是把这类字段改成TextField，它没有长度限制。改完models.py后记得重新makemigrations和migrate。这个坑很典型，因为扫描到的报错信息往往很长，设计表时容易低估。

4.3 中文乱码或时区不对

现象是结果页里中文显示成问号，或者任务时间比实际时间差 8 小时。原因是数据库字符集不是utf8mb4，以及 Django 的TIME_ZONE和USE_TZ配置不对。解决办法是在 MySQL 建库时指定CHARACTER SET utf8mb4，并在settings.py里设置LANGUAGE_CODE = 'zh-hans'、TIME_ZONE = 'Asia/Shanghai'、USE_TZ = False。SQLite 一般不会有字符集问题，但时区配置同样要改。

4.4 扫描目标不可达导致任务卡死

现象是任务状态变成 running 后再也不变，日志里也没有新内容。原因是扫描器对某个目标发请求时没有设超时，或者 DNS 解析卡住。解决办法是在所有requests.get里加timeout参数，并在外层加try/except捕获异常后把任务状态置为 failed。我一般还会在扫描循环里加一个总时长限制，超过就主动中断，避免一个任务占着线程不放。

4.5 迁移文件和数据库不一致

现象是执行migrate时报Table already exists或字段冲突。原因是之前手动改过数据库，或者迁移文件被删过又重建。解决办法是开发阶段可以直接删掉 SQLite 文件或 drop 掉 MySQL 库，重新migrate；如果库里有重要数据，就用python manage.py migrate --fake跳过已存在的迁移，但这一步要谨慎，容易把状态搞乱。

5. 二次开发与验证：把通用扫描器改成你的选题亮点

5.1 增加一种漏洞类型的完整流程

答辩时如果只展示 SQL 注入和 XSS，容易显得单薄。你可以基于现有结构加一种漏洞检测，比如敏感文件泄露。流程是：在rules.py里加一个路径字典，在engine.py里加一个检测函数，在models.py的vuln_type选项里加新类型，最后在前端结果页加一个筛选标签。下面是一个检测敏感文件的示例：

# scanner/rules.py SENSITIVE_PATHS = [ "/.git/config", "/backup.sql", "/phpinfo.php", "/.env", ] # scanner/engine.py def scan_sensitive_files(base_url, timeout=5): """探测常见敏感文件是否可直接访问""" findings = [] for path in SENSITIVE_PATHS: url = base_url.rstrip("/") + path try: resp = requests.get(url, timeout=timeout) # 200 且内容不是通用 404 页面，才认为命中 if resp.status_code == 200 and len(resp.text) > 0: findings.append({ "vuln_type": "sensitive_file", "risk_level": 4, "payload": path, "evidence": f"HTTP 200, length={len(resp.text)}", }) except requests.RequestException: continue return findings

这段代码的关键参数是risk_level，敏感文件泄露通常给 4 级，比注入略低但高于信息泄露。evidence里记录状态码和长度，方便你在报告里说明判定依据。加完之后记得在任务执行入口里调用这个函数，并把结果合并到总结果列表。

5.2 用 SQL 查询验证扫描结果是否完整

改完代码后怎么确认数据没问题？直接查数据库最快。假设你用 MySQL，可以执行下面这条 SQL 看每个任务的漏洞分布：

-- 统计每个任务的漏洞类型和数量，确认没有漏写 SELECT task_id, vuln_type, COUNT(*) AS cnt FROM scan_result GROUP BY task_id, vuln_type ORDER BY task_id DESC, cnt DESC;

如果某个任务扫出了结果但这里查不到，说明写入逻辑有问题；如果数量对不上，可能是去重逻辑把不同 payload 的结果合并了。我一般还会查一下scan_log里有没有异常记录：

-- 查看最近失败或警告级别的日志 SELECT task_id, level, message, timestamp FROM scan_log WHERE level IN ('ERROR', 'WARNING') ORDER BY timestamp DESC LIMIT 20;

5.3 报告导出与结果验证的一个实用技巧

很多同学做到最后想加一个「导出 PDF 报告」的功能，结果卡在模板渲染上。我的习惯是先用 Django 模板生成 HTML，再用浏览器打印成 PDF，别一上来就上reportlab或weasyprint，依赖重且容易出字体问题。验证报告是否完整，可以拿一个已知有漏洞的靶场跑一遍，人工核对结果页和数据库记录是否一致。从那以后我每次改完扫描规则，都会先跑一个固定靶场做回归，确认老漏洞还能扫出来、新漏洞能扫出来、误报没有明显增加，再提交代码。希望这份源码能帮你把课程设计或毕业设计稳稳落地。

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