⚠️ 免责声明：本项目仅用于网络安全技术学习与研究，请勿用于任何非法用途。

完整测试报告及详细截图已开源至 GitHub：14free/kuaidi100-security-analysis: 快递100安全分析报告

一、测试环境

• 工具：Burp Suite + 微信
• 目标：快递 100 微信小程序
• 接口基线：GET /apicenter/kdquerytools.do
• 测试时间：2026-04-27

二、接口基线与正常请求

• 接口：GET /apicenter/kdquerytools.do?method=userinfo4queryresult

• 请求方法：GET

• 关键参数：

  num=YT886***5838——业务参数

  openid=ocNgX***PkZE——微信用户的唯一标识，同一个用户在不同的程序下都不一样，长期有效

  Token=XC6428***dde6_V2——鉴权令牌

  platform=WEIXINAPP——客户端标识

  apiversion=28——接口版本号

三、安全测试记录

3.1 重放攻击测试

• 方法：同一个请求原封不动的重放了三次，间隔大约30秒
• 结果：三次均返回 200，data 内容一致，无 token expired 或 timestamp 校验提示
• 结论：接口无防重放机制（缺少时间戳窗口或一次性 nonce），存在重放风险

3.2 越权测试（参数篡改 - 单号）

• 方法：保持 Token/Openid 不变，仅修改 num 为其他单号
• 结果：结果返回200 OK，data中包含其他人的快递信息（uuid不同）
• 结论：存在水平越权，后端没有检验单号和当前的会话者的关系

修改前的：

修改后：

3.3 Token 鉴权测试

3.3.1全量剥离测试（验证鉴权是否强制）

方法：

• URL 参数：删除 Token、ssotoken、logintoken、Openid、unionid

• Headers：删除 Openid:、Token:

结果：

返回200 OK，data字段为null

结论：

3.3.2令牌篡改测试（验证token检验的严格性）

方法：

修改以下两处为无效值：

• URL 参数 Token=12345

• Header Token: 12345

结果：

分析：通过截图可以看到，修改后返回的仍是详细信息。但我仅修改了 Token，还存在另外两个有效凭证：

&ssotoken=XC6429***5e27_V2
&logintoken=0mN7M***PeE9v

分析：

快递 100 的后端逻辑是“只要有任意一个有效的凭证（ssotoken 或 logintoken）就放行”，而忽略了被改坏的 Token 参数。 删除这两个参数后，返回的仍是详细信息，猜测服务端可能仅认 Openid（因其难以伪造）。

验证想法：

删除 URL 和 Header 中的 Openid 参数，结果如下：

data 返回 null。但这不能直接说明 Openid 是鉴权核心，因为此时 Token 是无效的。删除所有 Token 相关参数，仅保留 Openid，结果如下：

删除所有 Openid 并保留正确的 Token：

返回详细信息。结论：后端采用“或（OR）”逻辑，只要任意一个凭证有效即放行，缺乏双因子绑定校验。

3.4 签名/时间戳/必填参数测试

方法：每次只删除一个参数，其他保持不变：

删除 platform

结论：平台标识未校验

删除 apiversion

结论：版本号未校验

接口无签名（sign）机制，无时间戳（timestamp）校验，存在参数篡改与重放攻击风险。

3.5 响应敏感信息检查

• 提取正常响应的JSON

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Apr 2026 10:29:50 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Content-Length: 231
{"message":"success","status":200,
"data":{"sharecardtype":null,"cardtype":null,"exclusiveTotal":0,"shareprisecardtype":null,"kdbestTotal":0,"havecoupon":"N","isgot":"Y","uuid":"YT886***5837_993***289","userorder":"N","expid":0}}

这里有个敏感信息：

这是一种间接泄露:

YT886***5837 = 快递单号 993***289 = 用户 ID

结合之前的越权漏洞，攻击路径可能是这样：

第 1 步：攻击者注册一个账号 第 2 步：用越权漏洞遍历查询 10000 个快递单号 第 3 步：从每个响应的 uuid 中提取用户 ID 第 4 步：获得"快递单号 ↔ 用户 ID"的完整映射表 第 5 步：用这个映射表去攻击其他接口（如订单详情、用户信息等）

四、风险汇总与修复建议

高危：水平越权（IDOR）

• 描述：接口未校验快递单号与用户身份的归属关系。攻击者使用合法身份（Token 或 Openid）修改 num 参数，可查询任意用户物流信息。
• 修复：服务端增加对象级授权校验：WHERE num=? AND user_id=?。

中危：鉴权逻辑冗余（或逻辑漏洞）

• 描述：接口存在双重认证通道（Token 与 Openid），服务端采用“或（OR）”逻辑校验。攻击者可通过泄露的 Openid 绕过 Token 安全机制。
• 修复：收敛认证入口，强制要求 Token 与 Openid 绑定校验，实施双因子身份确认。

中危：缺乏防重放与防篡改机制

• 描述：请求无签名（sign）和时间戳（timestamp）参数，同一请求可无限重放，业务参数可随意篡改。
• 修复：引入 HMAC-SHA256 签名机制，增加 ±5 分钟时间窗口校验。

低危：间接信息泄露

• 描述：响应中 uuid 字段明文暴露“快递单号_用户 ID"映射关系，结合越权漏洞可构建攻击数据库。
• 修复：使用随机 UUID 替代可预测的拼接格式，对用户 ID 进行哈希处理。