用Django构建Web化网络安全扫描平台：端口扫描、子域名枚举与目录探测实践

简介：面向Python/Django毕业设计学生的nweb渗透测试工具源码包，完整提供基于Django构建Web安全检测应用的工程代码，可学习扫描器、会话劫持、CSRF防护、弱口令测试、目录遍历、代码审计及OWASP Top Ten等常见检测模块，并通过models、views、urls、forms、templates、static、middleware分层结构理解Django项目组织方式。包内共2000个文件、压缩包约557.95MB，其中275个py源码与197个pyc字节码构成核心逻辑，1662个svg图标配合css、js搭建前端界面，html模板负责页面渲染，sqlite3数据库及配置文件支撑运行，整体工程完整、素材齐备。已有497人学习浏览，特别适合毕业设计参考、Django源码精读或Web安全入门；通过代码既能掌握权限校验、表单验证、URL路由、中间件等Django开发要点，也能了解漏洞扫描原理、会话安全机制和OWASP风险项的检测思路，同时明确渗透测试应遵循合法授权边界；目录层次清晰，从扫描任务启动、进度显示到结果入库均有完整实现。

1. nweb 是什么：一个把扫描器打包进 Web 平台的毕业设计解法

毕设答辩现场最常见的翻车方式，是把安全工具做成一个终端黑匣子：评委只看到一串串滚动的字符，看不到任务状态，也看不出工程结构。用 Django 写的 nweb（Network Web Scanner）提供的是另一条路——端口扫描、子域名枚举、目录探测这些常规渗透测试能力被封装成一个个可调度的扫描任务，前端负责发起和展示，后端用 ORM 管理目标、任务和结果。这样它既具备真实的探测能力，又是一个完整的产品原型。适合正在纠结“Django 项目做什么选题”的人，也适合想借毕业设计切入安全研发方向、需要一个能放在简历上的完整作品的从业者。

2. nweb 的 Django 骨架：App 划分与数据模型怎么定

2.1 为什么用 Django 而不是 Flask 写渗透测试工具

很多人选 Flask，理由是轻量。但做一个“渗透测试工具平台”，真正的产品面是任务管理、目标管理、结果展示和用户权限，扫描本身只是其中一个模块。Django 在这几点几乎是白送：内置 Admin 后台可以直接管理目标列表，内置 User 模型解决登录问题，ORM 让结果落库和查询不需要拼 SQL。Flask 也能做，但同样功能要多写一倍的胶水代码。毕设时间本来就紧，没必要把时间花在这些重复劳动上。

生产级的 Django 后端通常会拆出多个 App，按企业级教程的做法甚至会把用户、权限、任务队列各拆成一个独立服务。nweb 这类项目不必那么重，但也不能把所有逻辑塞进一个 App。我一般会拆成三个业务 App：targets 管目标资产（域名、IP、端口范围），scan_task 管扫描任务和结果，account 直接继承 Django 自带的 auth 体系，暂时不做扩展。核心扫描代码不放 App 里，而是放在项目根目录下的扫描引擎包里，方便脱离 Django 做单元测试。

2.2 初始化项目：创建虚拟环境与 App

创建项目时先建虚拟环境，避免把依赖装进系统 Python，后面装 requests、更新 Django 版本都不会污染到别的项目。下面这组命令在 Linux 和 Windows 上都通用，Windows 上把source .venv/bin/activate换成.venv\Scripts\activate.bat即可。

python -m venv .venv source .venv/bin/activate pip install django requests django-admin startproject nweb_project cd nweb_project python manage.py startapp targets python manage.py startapp scan_task python manage.py startapp account

django-admin 创建项目、manage.py 创建 App，整套动作十分钟能完成。新手最容易漏的一步是创建 App 后忘了去 settings.py 的 INSTALLED_APPS 里登记，结果跑 migrate 时报 “No such table”，后面一排查才发现 App 根本没被 Django 加载。做完 startapp 顺手把三个 App 名字加进 INSTALLED_APPS，是省时间的好习惯。

2.3 模型设计：Target、ScanTask、ScanResult 三个表怎么拆

数据模型是整个平台的地基。设计核心是把“扫描任务”和“扫描结果”分开：任务表记录“什么时候对哪个目标做了什么”，结果表记录“扫描出来的内容是什么”。下面是我会写进 models.py 的核心部分。

# scan_task/models.py from django.db import models from django.contrib.auth.models import User class Target(models.Model): name = models.CharField(max_length=128) # 目标名称，如“内网测试机” host = models.CharField(max_length=255) # IP 或域名 port_range = models.CharField(max_length=64, # 如 1-1024 default="1-1024") created_by = models.ForeignKey(User, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now_add=True) def __str__(self): return f"{self.name}({self.host})" class ScanTask(models.Model): class Status(models.TextChoices): PENDING = "PENDING", "等待中" RUNNING = "RUNNING", "执行中" DONE = "DONE", "已完成" FAILED = "FAILED", "失败" CANCELLED = "CANCELLED", "已取消" target = models.ForeignKey(Target, on_delete=models.CASCADE) scan_type = models.CharField(max_length=32) # port / subdomain / directory status = models.CharField(max_length=16, choices=Status.choices, default=Status.PENDING) progress = models.IntegerField(default=0) # 0-100，前端轮询用 current_item = models.CharField(max_length=255, blank=True) result = models.JSONField(default=list, blank=True) created_by = models.ForeignKey(User, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now_add=True) class ScanResult(models.Model): task = models.ForeignKey(ScanTask, on_delete=models.CASCADE, related_name="items") item_type = models.CharField(max_length=32) # open_port / domain / directory detail = models.JSONField(default=dict) # 不同扫描类型字段差异大，用 JSON 存 created_at = models.DateTimeField(auto_now_add=True)

参数说明：Status用 TextChoices 而不是写成字符串常量，Django 后台下拉框会自动显示中文，代码里也不容易手滑写错值。progress字段放任务表而不是结果表，因为前端轮询进度只需查任务一张表，join 结果表会慢一个数量级。result用 JSONField 存最终汇总结果，明细行再落 ScanResult，牺牲一点查询能力换展示时的便利。

为什么不做传统的关系表，比如“开放端口表”“发现域名表”？因为扫描器输出的字段差异太大：端口记录有 service、banner，目录记录有 status_code、title，子域名记录有 cname、ip。强行统一成关系表，每一种扫描都要新建一张表。JSONField 在 Django 3.1 之后对 SQLite、MySQL 都支持得很好，是这类“半结构化结果”的最优解。

2.4 Admin 注册：演示时最实用的一个动作

把模型注册进 Django Admin，演示时可以直接在后台添加目标、查看任务记录，不用等前端页面全部写完。

# scan_task/admin.py from django.contrib import admin from .models import Target, ScanTask, ScanResult @admin.register(Target) class TargetAdmin(admin.ModelAdmin): list_display = ("name", "host", "port_range", "created_at") @admin.register(ScanTask) class ScanTaskAdmin(admin.ModelAdmin): list_display = ("id", "target", "scan_type", "status", "progress", "created_at") list_filter = ("status", "scan_type") @admin.register(ScanResult) class ScanResultAdmin(admin.ModelAdmin): list_display = ("task", "item_type", "created_at")

这段代码解决的是“数据要有地方看”的问题。创建超级用户后登录/admin，目标列表、任务状态、扫描结果一目了然。答辩演示时，这比在终端里敲 SQL 查库体面得多。list_filter 加在 ScanTask 上，演示时按 scan_type 过滤出端口扫描任务，几秒钟就能找到目标数据。

3. 扫描功能落地：端口扫描、子域名枚举与目录探测的实现

3.1 路由与视图：从点击“开始扫描”到看到结果

前端发起一个 POST 请求到/api/tasks/，视图接收 target_id 和 scan_type，校验目标归属后创建 ScanTask 记录并返回 task_id，前端拿 task_id 轮询进度。下面是最简路由配置。

# nweb_project/urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path("admin/", admin.site.urls), path("api/", include("scan_task.urls")), ]

# scan_task/urls.py from django.urls import path from . import views urlpatterns = [ path("tasks/", views.create_task), path("tasks/<int:pk>/", views.task_detail), ]

请求链路很直接：urls 把/api/tasks/转发给 create_task 视图，视图负责校验、建任务、触发扫描线程，最后返回 JSON。前端只要拿到带 task_id 的响应就完成第一步，后续进度展示全部走 task_detail 接口。这种拆分方式让“发起”和“查询”两个动作分别扛独立接口，后续加权限控制也容易。

3.2 端口扫描器：连接超时与并发数的选择

端口扫描本质是 TCP 连接探测：目标端口处于监听状态时，握手会成功。常见做法是用 socket 逐个 connect，但串行扫 1 到 1024 号端口非常慢，必须用线程池并发。

# engine/port_scanner.py import socket from concurrent.futures import ThreadPoolExecutor COMMON_PORTS = [21, 22, 23, 25, 53, 80, 110, 111, 135, 139, 143, 443, 445, 993, 995, 1723, 3306, 3389, 5900, 8080] def _probe(host, port, timeout=1.0): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(timeout) result = False try: if sock.connect_ex((host, port)) == 0: result = True except Exception: result = False finally: sock.close() return port, result def scan_port(host, ports=None, timeout=1.0, max_workers=50): if ports is None: ports = COMMON_PORTS with ThreadPoolExecutor(max_workers=max_workers) as pool: futures = [pool.submit(_probe, host, p, timeout) for p in ports] opened = [] for future in futures: port, ok = future.result() if ok: opened.append(port) return sorted(opened)

参数说明：timeout=1.0在本地或内网扫描合适，如果扫公网目标，1 秒可能不够稳，建议调到 3 秒但要清楚整体耗时会线性上涨。max_workers=50是比较保守的并发数，太大容易在目标防火墙上触发封禁，也可能消耗本机大量临时端口。connect_ex在连接失败时不会抛异常而是返回错误码，异常处理只留给超时等少见情况，代码进度更干净。

3.3 子域名枚举：字典大小和泛解析处理

子域名枚举的常见做法是拿字典里的前缀拼上主域名做 DNS 解析，能解析就认为存在。这个逻辑本身简单，但不处理“泛解析”会扫出一堆假域名，这也是这个模块最典型的坑。

# engine/subdomain_enum.py import socket from concurrent.futures import ThreadPoolExecutor, as_completed def detect_wildcard(domain): """检测主域名是否配置了泛解析""" fake = f"nonexist-{abs(hash(domain)) % 100000}.{domain}" try: ip = socket.gethostbyname(fake) return ip except socket.gaierror: return None def _check_sub(pre, domain, wildcard_ip): sub = f"{pre}.{domain}" try: ip = socket.gethostbyname(sub) except socket.gaierror: return None if wildcard_ip and ip == wildcard_ip: return None # 命中泛解析，丢弃 return {"sub": sub, "ip": ip} def enum_subdomain(domain, wordlist_file, max_workers=30): wildcard_ip = detect_wildcard(domain) with open(wordlist_file, "r", encoding="utf-8") as f: words = [line.strip() for line in f if line.strip()] results = [] with ThreadPoolExecutor(max_workers=max_workers) as pool: futures = [pool.submit(_check_sub, w, domain, wildcard_ip) for w in words] for future in as_completed(futures): item = future.result() if item: results.append(item) return results

detect_wildcard 用一个几乎不可能真实存在的前缀去解析主域名，如果解析到了 IP，说明域名开了泛解析（* 记录指向某台服务器），后续枚举中凡解析到该 IP 的子域全部视为噪声丢弃。字典文件用 admin、api、mail、dev、test 这类常见前缀，几百行就够本科毕设用了。字典越大越慢，也越容易被目标 DNS 服务器的限流策略盯上，所以宁可选小字典加并发控制，不要一股脑塞几万行。

3.4 目录扫描：状态码、重定向与 User-Agent

目录扫描是通过 HTTP 请求探测目标站点上真实存在的路径。常见做法是先看 404 响应特征，再逐个请求字典里的路径，按状态码分类结果。

# engine/dir_scan.py import requests def scan_directory(base_url, wordlist_file, timeout=5.0): ua = {"User-Agent": "Mozilla/5.0 (compatible; nweb/1.0)"} with open(wordlist_file, "r", encoding="utf-8") as f: paths = [line.strip() for line in f if line.strip()] results = [] for path in paths: url = base_url.rstrip("/") + path try: resp = requests.get(url, headers=ua, timeout=timeout, allow_redirects=False) except requests.RequestException: continue entry = {"path": path, "status": resp.status_code, "size": len(resp.content)} if resp.status_code in (301, 302): entry["location"] = resp.headers.get("Location", "") results.append(entry) return results

关键参数：allow_redirects=False必须加，否则 302 会带着扫描器自动跳转到登录页，结果里全是登录页的 200 状态码，真实路径反而被淹没。timeout设 5 秒以上，有些框架接口处理慢，超时设短会误报“目标不可达”。真实场景里还要增加“404 模板过滤”：如果目标站点的 404 页面固定返回同一段内容，就把这种响应识别为“不存在”，否则扫出来的结果基本都是误报。

3.5 结果回显：视图层怎么把扫描结果交给页面

扫描完成后，视图从任务表取出 result JSON 直接返回前端渲染。这里数据模型和视图做了明确分工：视图只负责取数和序列化，展示逻辑全部交给前端按 item_type 分发。

# scan_task/views.py from django.http import JsonResponse from .models import ScanTask def task_detail(request, pk): task = ScanTask.objects.select_related("target").get(pk=pk) data = { "id": task.id, "target": task.target.host, "scan_type": task.scan_type, "status": task.status, "progress": task.progress, "current_item": task.current_item, "result": task.result, } return JsonResponse(data)

这段代码通过 select_related 一次性把目标信息带出来，避免前端拿到 task_id 后再请求一次目标接口。JsonResponse 会把 JSONField 内的列表原样输出，前端拿到 result 数组后直接遍历渲染成表格。扫描结果结构不统一这件事，后端不掺和，前端按 item_type 决定渲染成端口表格还是子域名列表，边界清楚。

4. 异步任务与结果入库：让长时间扫描不再卡死页面

4.1 同步等待为什么是最容易犯的错

如果直接在 create_task 视图里同步执行扫描，这个请求会占用视图线程数秒甚至数分钟。Django 开发服务器默认线程池资源有限，一个慢请求占住线程，其他所有登录、查询请求都得排队。到演示现场，点一次扫描整个平台“没反应”，就是这个原因。

正确思路是：视图只负责把任务写入数据库并立即返回 task_id，扫描逻辑放后台线程执行，前端每秒请求一次任务详情接口，把 progress 渲染到进度条。这是 Web 工具类项目最常见的异步方案，不引入额外组件也能把逻辑讲通，答辩时也说得清楚。

4.2 用内置线程托管扫描执行

不引入 Celery 时，我一般直接用 Python 的 threading 模块，一个扫描任务一个线程。核心是把“任务执行流程”和“任务状态更新”解耦。

# scan_task/services.py import threading from .models import ScanTask from engine.port_scanner import scan_port from engine.subdomain_enum import enum_subdomain from engine.dir_scan import scan_directory SCANNERS = { "port": scan_port, "subdomain": enum_subdomain, "directory": scan_directory, } def run_scan_task(task_id): task = ScanTask.objects.get(pk=task_id) task.status = ScanTask.Status.RUNNING task.save(update_fields=["status"]) target = task.target try: if task.scan_type == "port": task.result = scan_port(target.host) elif task.scan_type == "subdomain": task.result = enum_subdomain(target.host, "wordlist/sub.txt") elif task.scan_type == "directory": task.result = scan_directory(f"http://{target.host}", "wordlist/dir.txt") task.progress = 100 task.status = ScanTask.Status.DONE task.save(update_fields=["result", "progress", "status"]) except Exception as exc: task.status = ScanTask.Status.FAILED task.result = [{"error": str(exc)}] task.save(update_fields=["status", "result"])

参数说明：SCANNERS 字典是分发表，新增扫描类型时只改这里，视图层不需要知道有哪些扫描器。update_fields 减少数据库写操作，进度到 100 时只更新四个字段，避免全表字段重写。异常处理是抓大放小：扫描线程里任何异常都不应该导致 Django 进程崩溃，把错误写进 result 比打印堆栈更利于前端展示。

4.3 任务创建视图与进度轮询

创建任务的视图做三件事：校验目标归属、创建 ScanTask 记录、启动后台线程。线程启动后立即返回，响应时间控制在 100 毫秒内。

# scan_task/views.py import threading from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from django.views.decorators.http import require_POST from django.shortcuts import get_object_or_404 from .models import Target, ScanTask from .services import run_scan_task @csrf_exempt @require_POST def create_task(request): target_id = request.POST.get("target_id") scan_type = request.POST.get("scan_type") target = get_object_or_404(Target, pk=target_id, created_by=request.user) task = ScanTask.objects.create( target=target, scan_type=scan_type, created_by=request.user, ) t = threading.Thread(target=run_scan_task, args=(task.id,), daemon=True) t.start() return JsonResponse({"task_id": task.id})

参数说明：csrf_exempt 在纯 API 场景省去 CSRF token 处理，但如果之后要改成 Django 模板渲染页面，需要去掉这个装饰器并加上表单校验。这里用 request.user 过滤目标归属，目标不是当前用户创建时返回 404，避免越权访问任务数据。

线程的 daemon=True 在本机演示时很关键：开发服务器 Ctrl+C 退出时守护线程随主进程一起结束，不会出现“进程退了扫描还在后台跑”的僵尸线程。真正生产环境不要用裸线程，那时任务应该交给消息队列管理生命周期。

4.4 任务取消：删除对象其实有讲究

答辩可能被问到“任务能不能取消”。常见做法是软删除而不是真删除：把任务状态改成 CANCELLED，后台扫描函数每轮循环检查一次状态再决定是否继续。这既保留任务记录，又不会让扫描线程无限跑下去。

def should_stop(task_id): return not ScanTask.objects.filter( pk=task_id, status__in=[ScanTask.Status.CANCELLED, ScanTask.Status.DONE], ).exists()

在扫描循环里每处理完一个子域名或目录就调用一次 should_stop，返回 True 就 break。取消接口执行ScanTask.objects.filter(pk=pk).update(status="CANCELLED")。注意这里用 QuerySet.update 而不是先 get 再 save：update 直接落库，没有“先读后写”的竞态窗口。这是 Django 执行查询更新对象的一个实用细节，批量更新永远优先于单对象改属性再 save。

4.5 要不要上 Celery：规模与答辩取舍

对一个毕业设计来说，内置线程方案完全够用。如果导师明确要求“任务队列”或“分布式扫描”，再上 Celery 不迟。答辩讲方案取舍时可以说“考虑到系统演示环境是单机，引入内置线程调度而非消息队列，在可维护性和复杂度之间取了平衡”，这句话本身是加分项，说明你想过，而不是不会用。

5. nweb 排坑手记：从能启动到能演示的五个问题

5.1 点“开始扫描”后浏览器一直转圈直到超时

现象：前端发起扫描请求后，整个页面不再响应，浏览器最终提示连接超时。

原因：扫描逻辑直接写在视图函数里，同步执行，线程被长时间占用。Django 开发服务器默认线程池很薄，一个扫描任务就把整个服务拖住了，后续所有请求排队等待。

解决：把视图拆成“建任务 + 启动后台线程 + 立刻返回”，见第四章的 create_task。判断是否踩坑的方法：在视图第一行加print("in")、最后一行加print("out")，如果 in 到 out 耗时超过 2 秒，说明同步执行还没拆干净。这个排查法适用于所有 Django 视图卡死类问题。

5.2 SQLite 报 “database is locked” 错误

现象：任务跑着跑着控制台冒出OperationalError: database is locked，任务状态卡在 PENDING。

原因：默认配置下 SQLite 同一时刻只允许一个进程写库。扫描线程在频繁更新进度，视图线程也在写任务记录，两个写入操作撞在一起就锁了。

解决：先打开 WAL 模式，再减小写入频率，进度不是每扫一个端口就写一次，而是攒到 10% 增量再写。DATABASES 配置里加OPTIONS，同时确保扫描循环里的保存操作尽量集中。

DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", "OPTIONS": { "timeout": 20, "init_command": "PRAGMA journal_mode=WAL;", }, } }

timeout 参数让数据库等待锁释放的时间延长到 20 秒，WAL 模式允许读写并发。两个措施一起上之后，这类报错基本消失。

5.3 子域名扫描推到一半像死机

现象：子域名任务耗时超过十分钟，进度一直停在 12%，连 DNS 查询都变慢了。

原因：字典太大加上线程数量一多，本机发出的 DNS 请求被系统解析器或路由器限流。更糟的是如果目标域名配了泛解析，每个前缀都解析成功，结果里存了一堆假数据，看起来像卡死其实是逻辑不对。

解决：先用 detect_wildcard 检测泛解析并过滤，再把并发数降到 20 以下，字典控制在 1000 行以内。扫描前先估算：平均一个 DNS 查询 50 毫秒，并发 20，1000 个词大概几分钟内跑完。如果实际耗时远超过估算，优先怀疑限流，其次怀疑泛解析。

5.4 DEBUG=False 之后样式全丢

现象：为了演示把 DEBUG 设为 False，重启后登录页变成纯 HTML，CSS 全没了。

原因：Django 的 runserver 只在 DEBUG=True 时托管静态文件。DEBUG=False 后静态文件路径没人管，页面引用 /static/ 下的文件全部 404。

解决：本地演示不要动 DEBUG。如果有人非要在答辩时关掉 DEBUG 装“生产环境”，需要先跑 collectstatic 把静态文件收集到指定目录，再用独立静态文件服务提供。对 nweb 这个项目，保持 DEBUG=True 是省时间的正确选择，答辩考核的是系统设计和思维，不是 DEBUG 开关。

5.5 开发服务器一重启，扫描结果全丢了

现象：演示前不小心改了一个文件，Django 自动重载，后台任务列表空了，之前扫描出来的端口和目录全部消失。

原因：开发服务器会监听源码变化自动重启，内存里的任务状态随之清空。如果扫描逻辑操作的是 Python 变量而不是数据库，重启后一切归零。

解决：扫描结果一律写入 ScanTask.result 或 ScanResult，前端从接口读，不读进程内变量。源码修改和任务状态分离的意思是：Ctrl+S 之前想清楚这次保存会不会触发 autoreload，如果正在跑任务，宁可等任务结束再改代码。这个坑在答辩前夜最容易踩，撞上之后没有后悔药。

6. 从毕业设计到真工具：本地靶场验证与插件化改造

先解决“怎么证明它真的有用”的问题。不要拿公网域名做测试，那既涉及授权问题又容易被反而不稳定。常见的做法是在本机起一个靶场，DVWA 和 OWASP Juice Shop 都行，把 Target 的 host 填成 127.0.0.1，端口扫描选 8080，目录扫描跑完能看到 /login.php、/admin 这类真实路径，整个流程就闭环了。验证时重点看三处：扫描结果是否和靶场实际服务一致、进度条是否平滑上涨、扫描过程中页面其他功能是否还能正常用。

再解决“将来怎么扩展”的问题。我一般会把扫描器做成插件化结构：每个扫描器是一个独立的类，继承同一个抽象基类，运行时动态加载。

# engine/base_scanner.py class BaseScanner: name = "base" def __init__(self, target, task_id): self.target = target self.task_id = task_id def scan(self): raise NotImplementedError # engine/port_scanner.py from .base_scanner import BaseScanner class PortScanner(BaseScanner): name = "port" def scan(self): return scan_port(self.target.host)

插件化之后，新增一个“CORS 检测”只需要另起一个文件写实现，在 SCANNERS 字典里注册一行，前端表单里加一个选项，其余一概不动。这才是把这个项目从“跑通”做到“能维护”的关键一步。

我当年在答辩前一周把任务调度从内置线程换成 Celery，结果被 Redis 环境问题折腾了三天，最后换回内置线程才压哨跑通。后来想明白了：毕设不是追新框架，是把一个方案讲到闭环。先把最小的方案跑起来，再按需加复杂度，这条路走得最稳。希望帮到你。

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