免责声明：由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号陌笙不太懂安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉，谢谢！
作者: 一天要喝八杯水
原文链接: https://forum.butian.net/index.php/share/4441
渗透测试人员像极了代码世界的“侦探”，手握 Burp Suite 这把“放大镜”，在资产海洋里遨游。我们对着页面疯狂修改参数、发送请求，却常常被系统用平淡的响应打发，如同在广阔的大洋投石，激不起一丝涟漪；要么请求直接被拦截，让人气得想砸键盘。
尤其是开局一个登录框，简直是“经典打卡地”。测试 API 接口时，既要扮演研究正常逻辑的“好学生”，又得瞬间化身为设计注入 Payload 的“脑洞大师”，还得时刻提防 WAF 悄无声息地送你一张 404“飞机票”。漏洞挖掘本就是逆水行舟，挖不到才是常态。
最近我挖到的几个中高危漏洞，既没靠 0day 这种“王炸”，也没搞复杂的利用链“炫技”，纯粹是靠瞪大眼睛当“人肉扫描器”，连标点符号都不放过地逐行比对参数与响应。直到某个昏昏欲睡的下午，随手改了个藏在 JSON 数据深处的小参数，系统突然像“短路”一样反馈了全新的信息，反常的响应直接暴露了未授权访问的“马脚”。那一刻的激动，差点让我把咖啡泼到键盘上——原来洒掉的咖啡，比喝下去的提神一百倍。
无限抽奖币
新的功能点往往被常规功能所掩盖，进行黑盒测试的我们只能点点点。但当你坚持到那个隐秘功能点出现时，漏洞往往已经呼之欲出。
在微信搜索厂商资产时，我找到一个不起眼的小程序，特点是“20币抓一次娃娃”，并且有机会获得实物。
初始游戏币是100个。我小心翼翼地尝试了自定义投币数量、修改返回包控制所得物品、并发签到等操作，结果漏洞没挖到，游戏币却快测没了，简直是“天塌了”。
当时已经深夜12点，当我最后一次尝试抓娃娃并修改请求包仍一无所获时，悬着的心终于死了，正准备 Win + X, U, U 光速关机。但就在游戏币消耗殆尽时，界面上弹出了新的功能点，这让我死去的心再次燃烧起来。
“分享赚币”？点击后，我立刻在 Burp Suite 的历史记录中逐个查看数据包。凭借经验，最终锁定了 /app/point/doll/share 这个接口，它就是控制奖励金币数量的关键。数据包里有一个参数：
points=15
思路理清了，那就没什么好说的，直接重发数据包，把 points 参数改成一个大得离谱的数值。
不出意外，成功了！轻松拿下一个中危漏洞，又能多买几个馒头了。这次测试告诉我：不测试完所有功能点，就绝不轻言放弃。不要自己给自己说丧气话。很多人测试一个站点时，发现越权有鉴权，就下定义认为这个站没有越权了，这是万万不行的。作为白帽子，只有穷尽所有思路，才算完成一次完整的渗透测试。细心再细心，虽然过程枯燥，但长此以往，相信肯定会有收获。
可控所得优惠券
在一些购物平台，购买特定商品或服务后，系统会赠送优惠券。但通常都是些小额券，除非购买昂贵服务才会赠送高价值券。这里的思路是：利用低价服务获得的优惠券接口，通过手法找到高价值优惠券对应的 token，进行替换，从而达到“刷”高价值券的效果。
站点特征比较明显，我们快进到数据包分析阶段。选择一个商品服务下单，用 Burp Suite 记录所有流量。通过逐个分析，定位到创建订单的关键接口：
https://xxxxx/restapi/soa2/19691/orderCreate?_fxpcqlnired
将其发送到重发器（Repeater）等待进一步测试。
回到小程序查看已创建的订单，寻找可操作的业务。我注意到，订单支付成功后，系统会赠送相应的优惠券。
不过，都是一些不起眼的小额福利券，跟QQ空间那种“5元兰博基尼购车抵用券”不能说毫无关系，只能说一模一样。
将创建订单的接口发送到重发器后，开始观察数据包。这种涉及多流程的业务，数据包参数通常很多，有的关键，有的只是冗余。通过“人肉扫描器”逐段观察，我定位到 data 数据体中记录了优惠券对应的 token。
通过一系列方法（此处略去细节），我找到了其他高价值优惠券的 token。然后，我将数据包中三处低价值券的 token 替换为高价值券的 token。替换成功后，再次提交订单。
不出所料，新订单关联的优惠券，已经从三张小额券变成了三张“豪车打车立减100元券”。这意味着，只要我知道任意高价值券的 token，就可以通过低价订单获取它，并且可以通过叠加字段实现批量获取。
普通的CSRF
在如今各种高级逻辑漏洞、云安全攻防、OWASP Top 10 大行其道的今天，最基础的 CSRF 往往被轻视，常被认为需要与其他漏洞结合利用。但人们往往忽略了单个CSRF所能造成的直接影响。
我的理解是：只要功能涉及用户主观操作，比如修改个人信息、新增收货地址、发送邮件等等，并且请求中没有发现有效的 token 或类似校验字段，都可以尝试 CSRF。
在某金融站点，正常用户修改绑定邮箱需要输入交易密码。
但该站点同时存在一个“更新个人信息”的接口，可以直接修改绑定邮箱，且无需交易密码。如果制作一个 POST 请求的 CSRF PoC，诱导受害者点击，就可以将其绑定邮箱及个人信息修改为我们设定的内容。
为不影响真实业务，我准备了两个已完成实名认证的小号进行交叉测试。
在账号A中，对个人信息进行修改，同时用 Burp Suite 记录所有流量。捕获到更新信息的接口为：
/fund/apl/postUserinfo
观察这个更新个人信息的请求：第一，它包含了邮箱字段，如上所述，正常修改邮箱需要密码，但这个接口却可以直接修改；第二，请求包中没有 token、Referer 校验等其他防护字段。那么，它是否可能存在 CSRF 呢？
将这条 POST 请求右键，使用 Burp Suite 的 “Engagement tools” -> “Generate CSRF PoC” 功能。把生成的 HTML 代码拷贝出来，将其中的个人信息修改为自定义内容（例如攻击者的邮箱），然后保存为本地 poc.html 文件。
用已登录账号A的浏览器打开这个 poc.html 文件，点击页面上的 “Submit request” 按钮。
点击后，浏览器静默提交表单，并返回了“修改用户信息成功!”的响应。
刷新站点个人信息页面，发现当前账号的邮箱等个人信息，已经成功被修改为我们预设的内容。CSRF 攻击成功。
网站泄露导致接管
这个案例来自于近期的一次公司渗透测试项目，目标是一个地区的大量单位，最终成功拿下一个网站的超级管理员权限。
与企业SRC通常给出明确域名范围不同，这次工作是获得授权的渗透项目，需要面对的是海量的、未经梳理的单位名称资产。
测绘资产处理
众多单位名中，只有部分存在备案网站，这些才是有效的可渗透资产。如何筛选出无备案的单位？测绘平台在这里起到了关键作用。
像 鹰图（Hunter） 这类平台支持直接用企业备案名称进行查询，语法如下：
icp.name="xxx公司"
这是 fofa、360 Quake 等平台所不具备的特色。因此，在开局面对海量单位名时，Hunter 是最佳选择，唯一缺点是这种方式比较消耗平台积分。
既然知道方法，就可以编写一个批量脚本，填入 API Key 进行自动化调用。下面是一个参考的 Python 脚本核心框架：
import requests
import base64
import time
import json
import pandas as pd
# 鹰图平台的 API 地址
BASE_URL = "https://hunter.qianxin.com"
SEARCH_ENDPOINT = "/openApi/search"
# 你的 API Key（从鹰图平台获取）
API_KEY = "" # 替换为实际的 API Key
# 字段翻译映射表（略，见原文长列表）
FIELD_TRANSLATION = {
"code": "状态码",
"message": "错误信息",
# ... 更多字段映射
}
# 从 txt 文件读取公司名称列表
def load_company_names(file_path):
try:
with open(file_path, 'r', encoding='utf-8') as f:
companies = [line.strip() for line in f.readlines() if line.strip()]
return companies
except FileNotFoundError:
print(f"错误：文件 {file_path} 不存在")
return []
except Exception as e:
print(f"读取文件时出错: {e}")
return []
# 公司名称文件路径
COMPANY_FILE = "dz.txt"
# 加载公司名称列表
company_names = load_company_names(COMPANY_FILE)
if not company_names:
print("没有可用的公司名称，请检查 gs.txt 文件内容")
exit()
# 请求参数
page_size = 10 # 每页资产条数
# 存储所有检索结果
results = []
no_data_companies = []
for company_name in company_names:
print(f"\n正在查询公司: {company_name}")
page = 1
total_pages = 1
has_data = False
while page <= total_pages:
search_query = f'icp.name="{company_name}"'
search_encoded = base64.urlsafe_b64encode(search_query.encode("utf-8")).decode("utf-8")
params = {
"api-key": API_KEY,
"search": search_encoded,
"page": page,
"page_size": page_size
}
try:
response = requests.get(
f"{BASE_URL}{SEARCH_ENDPOINT}",
params=params,
timeout=15
)
response.raise_for_status()
data = response.json()
# ...（后续处理逻辑，包括分页、结果存储、异常处理等）
# 具体完整代码请参考原文长代码块
except requests.exceptions.RequestException as e:
print(f"公司 {company_name} 请求失败: {e}")
break
if not has_data:
no_data_companies.append(company_name)
# ...（后续结果保存为JSON和Excel的代码）
将公司名单填入 dz.txt，运行脚本后，会生成 JSON 格式的原始数据文件和整理好的 Excel 文件，便于后续分析。
通过这个步骤收集到的域名资产，我通常会筛选出状态码为200的Web资产。之后便会开始使用 nuclei 和 afrog 等工具进行同步扫描。由于测试标准较宽，在手工测试前，配置好的自动化工具就能帮我们发现一些 Swagger API 泄露、目录遍历，以及部分 CVE 漏洞和高危的端口服务，方便后续进行弱口令爆破等操作。
渗透实战
当资产被扫描器轮番测试时，我便开始对资产进行手工测试。开局一个首页，看起来确实没什么功能点，常见的测试方向就是目录扫描和接口未授权探测。
我打开了自己的 dirsearch 工具。为了应对不同的目标架构和需求，需要在多种命令行参数间快速切换。各位师傅可以让 AI 辅助写一个批处理脚本（.bat），来调用工具的不同参数模式，从而在单目标、多目标、递归扫描之间迅速切换。
对目标进行目录扫描后，发现了一个 Admin 目录，这大概率是网站的管理后台。
http://xxxxx.com/Admin/
直接访问，提示“连接超时！请先登录”，状态码是301，被重定向到了后台登录页面。这说明访问已被鉴权。
面对登录框，先尝试了 admin/admin 等几个经典弱口令，均告失败。注意到网站标题是“XX网络”，我猜测这可能是个小众CMS或框架，于是去搜索相关文章，但没找到公开漏洞。
尝试测试其他接口看看能否信息泄露，但接口同样少得可怜。此时，常规思路似乎已经穷尽，站点还是没拿下。
此时只剩下两个选择：一是继续爆破登录框（虽然有验证码，但可尝试绕过）；二是继续在目录扫描结果上深挖。既然一开始就能扫出登录后台，证明站点防护可能并不严密。我选择回到第一步，仔细审视 dirsearch 的扫描结果。
果然有发现！一个朴实无华的 password.txt 文件赫然在列。不会吧？不会真有人把密码明文放在网站目录下还没删除吧？
访问这个文件，成功获取了疑似后台的账户密码。
使用获取到的凭据尝试登录后台，一气呵成，成功进入。点到为止，测试完成。
总结
没有华而不实的“屠龙术”，只有重复测试99个平淡的数据包，而第100个产生了惊喜。唯有点滴的付出，你坚持的东西总有一天会反过来拥抱你。在网络安全，尤其是 渗透测试 这条路上，细心和坚持往往比复杂的技巧更为重要。
希望本文分享的几个真实案例和思考过程，能给你带来一些启发。漏洞挖掘不仅是技术活，更是一场心态和耐心的较量。如果你对 安全 领域的实战技术交流感兴趣，欢迎关注云栈社区，这里汇聚了众多技术同好。
发表于 前天 08:38
|
查看: 28|
回复: 0
