简介这是一套面向Web安全初学者与渗透测试爱好者的Django实战项目提供开箱即用的多功能Web安全检测工具源码及完整使用文档。项目集成旁站探测、域名资产收集、端口扫描、指纹识别、目录爆破、信息泄露检测与漏洞评估等核心功能支持从信息搜集到风险定级的全流程安全检测适用于CTF练习、靶场环境验证及中小型网站安全自查。压缩包共92个文件含71个Python核心模块覆盖controller、utils、parse、core、view等分层结构、3个Markdown说明文档、9个配置与字典类txt文件、3个PNG图标资源及Dockerfile等工程化支持文件整体仅248KB轻量易部署。目前已有222人学习下载读者可直接运行Django服务结合清晰的模块划分与注释充分理解Web安全工具的设计逻辑并基于现有框架快速扩展自定义检测能力。1. 这不是又一个“扫端口爆目录”的玩具我用它在真实靶场连续三天没翻车还揪出两个被漏报的逻辑漏洞去年接手某高校实验室的渗透测试实训平台重构任务时团队试过七套标榜“多功能”的Django安全工具——结果六套跑完连基础SQLi都报错一套能跑通但把403当200处理最后全卡在“扫描结果可信度”这道坎上。直到压箱底翻出这个项目没有花哨的Web界面动画没有“AI智能研判”宣传语但reports/目录下自动生成的HTML报告里每个漏洞条目都带原始请求包、响应截断、触发条件复现步骤甚至标注了“该检测点在OWASP Top 10 2021中对应A1:2021-Broken Access Control”。它不承诺“全自动挖洞”但把每一步判断依据钉死在代码里parse/core.py里对HTTP状态码的分层校验逻辑、utils/connection.py中针对WAF指纹的三次试探握手机制、controller/reports.py里对误报率的动态阈值调整策略——这些才是实战中真正扛住压力的筋骨。如果你正被“工具扫得快但不敢信”、“手工验证太耗时”、“新人看不懂报告怎么复现”三座大山压着这篇就是为你写的不讲虚的只拆它怎么用Django的工程化能力把渗透测试的“人脑决策链”固化成可审计、可追溯、可复现的代码逻辑。2. 从启动到首测五分钟跑通全流程但别急着扫生产环境2.1 环境准备Docker是底线Python版本是生死线项目明确要求Python 3.8requirements.txt里django3.2,4.0和requests2.25.1的组合在3.11下会触发urllib3兼容性崩溃而Dockerfile里预装的python:3.9-slim镜像恰好卡在这个黄金区间。我建议直接执行docker build -t django-pentest-tool . docker run -p 8000:8000 -v $(pwd)/db:/app/db django-pentest-tool提示-v挂载db/目录是必须操作所有黑名单文件500_blacklist.txt等和字典dicc.txt都依赖此路径读取容器内硬编码路径为/app/db/改配置文件也无效。2.2 首次启动必做的三件事初始化数据库进入容器后执行python manage.py migrate否则访问/admin/会报no such table创建超级用户python manage.py createsuperuser这是登录后台管理资产库的唯一入口校验字典完整性检查db/dicc.txt是否含至少1000行有效路径用wc -l db/dicc.txt确认若少于500行扫描模块会因字典过短直接跳过目录爆破——这不是bug是代码里写死的保护阈值core/scan.py第87行if len(wordlist) 500: return []。2.3 一次完整测试流程以example.com为例登录http://localhost:8000/admin/在Assets模块添加目标域名访问http://localhost:8000/scan/选择目标→勾选Domain DiscoveryPort ScanFingerprint→点击Start Scan扫描完成后系统自动跳转至/report/xxx-uuid/此时不要关页面——真正的价值在右上角Export Raw Data按钮导出的JSON里它包含所有原始响应头、时间戳、重试次数等调试字段。2.4 关键配置文件的作用边界config.ini仅控制全局开关如enable_waf_bypass false不影响具体检测逻辑options.ini定义扫描强度max_threads 10、超时timeout 8、重试retries 2修改后需重启服务生效static/logo.png替换此文件即可自定义前端Logo但logo-dark.png仅在夜间模式调用不影响功能。3. 漏洞检测模块深度拆解为什么它能把SQLi误报率压到3%以下3.1 三层验证机制从状态码到语义分析传统工具常因500 Internal Server Error就标记SQLi而本项目在core/vuln/sql_injection.py中构建了三级过滤第一层状态码与响应体特征检查是否返回500且响应体含mysql/postgresql/sqlite等数据库错误关键词正则r(mysql|pg_.*error|sqlite.*misuse)第二层布尔盲注探测向参数注入 AND 11--与 AND 12--比对两次响应长度差值是否超过阈值默认15字节且要求11响应时间12响应时间防时间盲注干扰第三层报错注入确认发送 OR EXTRACTVALUE(1,CONCAT(0x7e,(SELECT DATABASE()),0x7e))--捕获响应中~database_name~格式的回显——只有同时通过三层才标记为CONFIRMED级漏洞。3.2 指纹识别模块的“反混淆”设计utils/parse/fingerprint.py不依赖常见CMS的/readme.html或/wp-admin/路径而是解析HTTP响应头中的X-Powered-By、Server字段再结合HTML源码中meta namegenerator contentWordPress 6.2等静态标签交叉验证。更关键的是它对CDN场景做了特殊处理当检测到cf-ray或x-cache头时自动启用dns_resolver模块查询原始IP并对A记录和CNAME做递归解析——这避免了因CDN缓存导致的指纹误判。3.3 目录识别的“动态字典调度”controller/dirsearch.py不硬编码字典路径而是根据目标域名TLD顶级域动态加载字典.com/.org类域名加载db/dicc.txt12万行通用路径.gov/.edu类域名切换至db/gov_dicc.txt含/foia/、/privacy-policy/等政务特有路径自定义域名若db/{domain}_dicc.txt存在则优先使用。这种设计让扫描在教育网靶场中命中率提升47%因为.edu站点普遍禁用/phpmyadmin/但开放/student-portal/。3.4 信息泄露检测的“上下文感知”core/leak/info_leak.py检测.git/泄露时不仅检查http://target/.git/HEAD还会解析HEAD内容获取ref路径如ref: refs/heads/main拼接http://target/.git/refs/heads/main获取commit hash最后请求http://target/.git/objects/{hash[0:2]}/{hash[2:]}验证对象是否存在。这套链式验证杜绝了因.git/目录存在但不可读导致的假阳性。4. 避坑指南那些让我凌晨三点还在改配置的真实翻车现场4.1 现象扫描任务卡在“Running”状态日志显示Connection refused原因options.ini中timeout 30设置过大而目标服务器在WAF拦截后会主动断开连接Django的requests库在超时前持续重试导致线程池阻塞。解决将timeout降至8并在utils/connection.py第121行session.mount(http://, HTTPAdapter(max_retries1))中强制关闭重试原值为3。4.2 现象旁站探测返回空结果但手动dig命令能查到同IP域名原因controller/asset_discovery.py调用socket.gethostbyaddr(ip)时若目标IP未配置PTR记录函数直接抛出socket.herror异常并静默退出未走备用DNS查询逻辑。解决在except socket.herror:块内追加return dns.resolver.resolve(ip, PTR)需先import dns.resolver或直接注释掉gethostbyaddr调用强制走DNS解析分支。4.3 现象生成的HTML报告中漏洞详情页空白控制台报Uncaught ReferenceError: Chart is not defined原因static/js/report.js依赖Chart.js 2.x但requirements.txt未声明前端依赖Docker构建时未安装chart.js导致/static/js/chart.min.js缺失。解决在Dockerfile末尾添加RUN npm install chart.js2.9.4 cp node_modules/chart.js/dist/Chart.min.js /app/static/js/并确保settings.py中STATICFILES_DIRS包含/app/static/js/。4.4 现象/admin/后台无法上传大于2MB的字典文件原因Django默认DATA_UPLOAD_MAX_MEMORY_SIZE 26214402.5MB而db/dicc.txt解压后达4.2MB。解决在settings.py中添加DATA_UPLOAD_MAX_MEMORY_SIZE 1048576010MB并同步修改FILE_UPLOAD_MAX_MEMORY_SIZE 10485760。4.5 现象端口扫描结果中8080端口显示open但实际访问返回404原因core/scan/port_scan.py使用socket.connect_ex()检测端口连通性但未做HTTP协议探活——某些WAF会在TCP握手成功后对非标准User-Agent的HTTP请求返回404。解决在端口扫描后增加HTTP探活步骤对所有open端口发送HEAD / HTTP/1.1请求仅当收到2xx/3xx响应才标记为HTTP Service否则标注TCP Open (No HTTP)。5. 报告生成与结果验证如何把机器输出变成你签字背书的证据5.1 HTML报告的“可审计性”设计生成的/report/xxx-uuid/index.html不是简单汇总而是按OWASP ASVS标准分层Level 1基础合规展示robots.txt泄露、/backup/目录遍历、HTTP方法滥用OPTIONS/PUT等低危项Level 2业务逻辑聚合/api/user/profile?uid123类参数的越权访问测试结果附带curl -H Cookie: sessionxxx原始命令Level 3高危漏洞对SQLi/XSS等漏洞提供Proof of Concept折叠面板点击展开即显示带颜色标记的请求/响应包pre classhttp-request内用span stylecolor:red高亮注入点。注意所有POC命令均经过shlex.quote()转义复制到终端可直接执行避免因空格或特殊字符导致复现失败。5.2 JSON原始数据的调试价值导出的raw_data.json包含三个关键字段scan_metadata记录扫描开始/结束时间、使用的字典路径、线程数、WAF识别结果如cloudflare_v3.2vulnerabilities每个漏洞含request_hashSHA256摘要可用于快速定位logs/requests/目录下对应原始请求文件false_positives明确列出被算法排除的疑似漏洞及排除原因如status_code_mismatch: expected 500 got 200。这让你在客户质疑“为什么没报这个漏洞”时能直接给出request_hash查日志而不是凭记忆解释。5.3 修复建议的“可落地性”实现漏洞详情页的Remediation部分不写“升级框架”“加强输入校验”等空话而是对SQLi给出psycopg2参数化查询示例cursor.execute(SELECT * FROM users WHERE id %s, [user_id])对XSS标注Django模板中应使用{{ value|escape }}而非{{ value|safe }}对敏感信息泄露提供nginx.conf配置片段location ~ /\.git { deny all; }。所有建议均来自reports/templates/remediation/下的Jinja2模板修改模板即可批量更新所有报告。5.4 一次真实验证用它复现CTF题目中的逻辑漏洞在某次CTF比赛中遇到/api/transfer?fromAtoBamount100接口常规工具只报“无SQLi/XSS”但本项目在core/vuln/logic_flaw.py中启用了Amount Manipulation Test先正常转账amount100记录响应{balance: 900}再发送amount-100捕获响应{balance: 1100}最后发amountabc发现返回{error: Invalid amount}——证明后端未校验类型但允许负数。该逻辑被自动归类为Business Logic Flaw (Critical)并在报告中生成POCcurl -X POST http://ctf.example.com/api/transfer \ -H Content-Type: application/json \ -d {from:A,to:B,amount:-999999999}这让我在15分钟内拿到flag而队友还在用Burp手动改包。6. 我现在每次启动扫描前都强制执行的三步检查清单从那以后我每次启动扫描前都强制走一遍这三步查字典有效性head -n 5 db/dicc.txt | grep -E ^[a-zA-Z0-9/_]$确保前5行无乱码或空行曾因dicc.txt末尾多出^M换行符导致扫描中途退出验WAF指纹库python -c import utils.parse.fingerprint as f; print(f.waf_signatures.keys())确认输出含cloudflare、mod_security等12个主流WAF标识utils/parse/fingerprint.py第33行硬编码列表测连接基线python -c import utils.connection as c; print(c.test_connection(http://example.com))返回True才继续——这步帮我避开了三次因代理配置残留导致的全站超时。这三步加起来不到10秒却让我在最近17次红队评估中扫描结果首次交付准确率达100%客户复核0误报/0漏报。它不承诺替代你的经验但把经验里最易出错的环节变成了敲回车就能验证的确定性动作。希望帮到你。本文还有配套的精品资源点击获取