漏洞挖掘-逻辑漏洞挖掘中的一些新思路
字数 4117 2025-10-01 14:05:44

逻辑漏洞挖掘新思路：从信息泄露到状态篡改的深入利用

文档说明： 本文档基于公开的技术研究文章《漏洞挖掘-逻辑漏洞挖掘中的一些新思路》进行梳理和扩展，旨在系统性地阐述其中揭示的三种高级逻辑漏洞利用手法。所有案例均已修复，本文仅用于安全技术教学与研究，旨在提升安全人员的安全意识与防护能力。

一、 任意用户登录接管：信息泄露与响应包替换的组合利用

这是一种结合了敏感信息泄露和认证逻辑缺陷的链式漏洞利用手法。

1. 漏洞背景与发现：

  • 目标： 某景区服务小程序。
  • 测试功能点： “我的意见”功能（通常为反馈、投诉入口）。
  • 测试方法： 清理浏览器或代理工具（如Burp Suite）的历史记录后，操作特定功能，观察产生的所有HTTP请求，避免干扰。

2. 漏洞挖掘过程：

  • Step 1: 发现信息泄露漏洞

    • 在“我的意见”功能中提交信息后，通过拦截或观察HTTP请求，发现一个查询接口：

      GET /minibgs2/public/index/suggest/sug_info/?id=570

    • 该接口无需任何身份认证Token或Cookie，仅通过修改URL中的id参数，即可直接返回对应用户的敏感信息，包括用户ID、姓名、手机号等（即“二要素”）。
    • 漏洞点： 接口未对当前会话权限做校验，导致越权信息泄露。

  • Step 2: 规模化利用信息泄露

    • 利用工具： 编写脚本或使用Burp Intruder等工具，自动化遍历id参数（例如从1到10000）。
    • 数据提取： 从返回包中正则匹配提取姓名和手机号。
    • 成果： 成功批量获取大量用户敏感信息（文中提及约5k条）。

  • Step 3: 定位认证逻辑缺陷

    • 转向另一功能点： 测试“我的套餐券”功能，该功能需要手机号验证码登录。
    • 分析登录流程：
      1. 输入手机号获取验证码。
      2. 输入验证码登录。
    • 关键发现： 登录成功后的服务器响应包中，没有返回标准的Token、Session等鉴权凭证，而是返回了一个看似是Base64编码的data字段。

      {"code": 100, "msg": "验证通过", "data": "MDU3MjAxxxxxxxxx0MzE1NjYwMA=="}

    • 解码分析： 对data参数进行Base64解码后，发现其内容即为当前登录用户的手机号拼接上一个固定的字符串（如0572030）。这意味着整个登录状态的维持依赖于这个可预测、可伪造的返回值。

  • Step 4: 完成任意用户接管

    • 攻击流程：
      1. 攻击者使用自己的手机号正常接收验证码，进行登录操作。
      2. 在Burp Suite中拦截登录过程的响应包。
      3. 将响应包中的data字段替换为事先通过信息泄露漏洞获取到的目标用户手机号编码后的值。
      4. 放行被篡改的响应包至客户端（小程序）。
    • 结果： 客户端小程序接收到响应后，会误以为当前登录的是目标用户，从而成功接管其账号，可以查看和操作其订单等敏感信息。

3. 核心要点总结：

  • 漏洞链： 信息泄露（无权限校验） -> 认证凭证可预测/可伪造 -> 响应包替换。
  • 关键思路： 不要只盯着请求包，服务器返回的响应包同样可能是逻辑漏洞的关键。认证凭证不一定总是复杂的Token，可能是简单的、可预测的用户标识。
  • 防御措施：
    • 所有查询接口必须进行严格的权限校验，确保用户只能访问属于自己的数据。
    • 认证成功的凭证应使用不可预测、高熵值的随机值（如JWT、随机Session ID）。
    • 避免将敏感信息或认证标识直接编码后返回给客户端。

二、 支付状态签名复用：状态校验逻辑绕过

这是一种通过“复用”正常流程中的成功状态响应包，来绕过支付校验的逻辑漏洞。

1. 漏洞背景与发现：

  • 目标： 某医院挂号系统。
  • 测试业务： 在线挂号支付业务。

2. 漏洞挖掘过程：

  • Step 1: 分析正常支付流程

    • 正常选择科室、医生、时间，生成订单。
    • 完成支付（微信付款）。
    • 支付成功后，服务器会返回一个“支付成功”的响应包。

      POST /api/bz/order/Sta/appoint
      {"code":0, "message": “支付成功”, "data":null}

  • Step 2: 首次尝试与失败

    • 初始想法： 尝试在支付环节拦截请求或响应，修改金额或状态。但支付流程通常与第三方支付平台交互，难以直接绕过。
    • 另一种思路： 在生成订单后，不进行实际支付，而是直接尝试访问“验证支付状态”的接口。
    • 操作：生成订单后，在支付页面取消支付（文中提及“叉掉二维码”），此时系统会去检查支付状态。
    • 拦截并替换这个检查状态的请求的响应包，将其改为之前捕获的“支付成功”响应包。
    • 结果： 首次尝试失败。订单状态并未变为成功。

  • Step 3: 深入分析与关键发现

    • 对比正常支付成功和检查状态失败的响应包，发现了一个关键差异：成功响应包的Header中包含一个类似追踪ID或签名的字段（例如：tlogTraceId: jyvU1094795431411044352）。
    • 该字段很可能与订单号绑定，并由支付平台或后端在成功支付后生成，用于唯一标识一次成功的交易。简单的响应包替换无法伪造这个签名。

  • Step 4: 脑洞大开的“签名复用”

    • 核心思路： 虽然不能伪造签名，但可以复用一次真实产生的成功签名。
    • 攻击流程：
      1. 正常支付一笔订单A（牺牲少量资金），并完整捕获从支付到最终成功返回的所有HTTP响应，保存整个成功的响应包（包括Header和Body）。
      2. 重新下单，生成一个新的订单B。
      3. 在新订单B的支付页面，取消支付，触发系统对订单B的支付状态检查。
      4. 拦截检查订单B支付状态的请求所对应的响应包。
      5. 将整个响应包（包括成功的Code、Message、以及关键的Header签名tlogTraceId）全部替换为之前订单A的成功响应包。
      6. 放行被篡改的响应包。
    • 结果： 后端系统接收到成功的状态响应，误认为订单B已经支付成功，从而生成有效的就医凭证。攻击者可以凭此凭证直接去医院就诊，实现了支付绕过。（文中提到订单列表可能不显示，但核心凭证已生成）

3. 核心要点总结：

  • 漏洞本质： 支付状态校验接口过于信任客户端（或网络传输中）的响应信息，未能与支付平台进行二次有效验证。
  • 关键思路： “签名”或“令牌”在一次有效会话中可能是可复用的。通过“牺牲”一个低价值订单，获取一个高价值订单的免费权限。
  • 防御措施：
    • 支付状态校验必须由服务器后端主动、直接地向支付平台查询确认，绝不能依赖客户端提供的任何信息。
    • 用于状态校验的令牌（如tlogTraceId）必须与订单号强绑定，且一次性有效。

三、 鉴权参数定位与响应包篡改：状态码操控

这种手法专注于识别应用程序中控制业务逻辑的关键参数，并通过篡改响应包中的这些参数来欺骗前端或后端。

1. 漏洞背景与发现：

  • 目标： 某景区门票购买业务。
  • 测试业务： 购买景点门票。

2. 漏洞挖掘过程：

  • Step 1: 分析正常流程

    • 正常选择门票、数量，下单并支付。
    • 捕获支付成功后的所有响应包。

  • Step 2: 定位关键鉴权参数

    • 与第一个案例不同，此次的响应包没有明显的认证信息，但包含了大量数据。
    • 通过仔细对比分析支付成功和支付失败的响应包，识别出三个控制出票逻辑的核心状态参数（参数名可能为type, status, payStatus等，原文未明确给出）。
    • 假设其值如下：
      • 支付失败： "param1": 1, "param2": 0, "param3": 0
      • 支付成功： "param1": 0, "param2": 1, "param3": 1
    • 这些参数直接决定了前端是否显示出票成功，以及后端是否生成有效门票凭证。

  • Step 3: 实施攻击

    • 攻击流程：
      1. 正常下单，但在支付环节中断支付（不实际付款）。
      2. 触发系统对支付状态的查询。
      3. 拦截状态查询的响应包。
      4. 在响应包中，将控制业务的几个关键参数的值从“失败”状态篡改为“成功”状态。
      5. 放行响应包。
    • 结果： 应用程序（前端或后端）根据被篡改的参数值，判断为支付成功，从而生成有效门票。攻击者无需付费即可获得门票。

3. 核心要点总结与拓展：

  • 漏洞本质： 应用程序将业务逻辑的决定权依赖于HTTP响应中的明文参数，这些参数容易被篡改。
  • 关键思路： 渗透测试不应仅限于修改请求参数，更要注重分析并篡改响应参数。需要具备通过对比分析，精准定位关键参数的能力。
  • 通用测试方法：
    • 密切关注HTTP状态码（如404->200）。
    • 关注业务状态码（如code: 500 -> 200, status: 0 -> 1）。
    • 关注数据内容（如 data: null -> {...}）。
  • 防御措施：
    • 核心业务逻辑应在服务器后端完成，决策结果不应依赖于客户端传递或返回的任何参数。
    • 敏感操作的结果应由服务器通过安全通道直接通知前端，或前端再次向服务器发起验证请求。

四、 总结与建议

本文介绍的三种新思路，打破了传统逻辑漏洞测试中只注重请求参数的思维定式，强调了信息泄露的深层次利用、响应包的重要性以及业务状态参数的操控。

  1. 测试思路转变： 从“修改请求”扩展到“拦截与篡改响应”，从“单一漏洞点”扩展到“漏洞链利用”。
  2. 重点关注对象：
    • 任何无需认证的API接口（信息泄露源头）。
    • 登录、注册、支付、状态查询等关键业务流程的响应包。
    • 响应包中的状态码、明文参数、Base64等编码数据。
  3. 防御设计原则：
    • 权限校验： 所有接口必须施行严格的访问控制。
    • 不可预测性： 认证凭证和重要令牌必须是高随机性的。
    • 服务器端校验： 核心业务逻辑和状态决策必须在服务器端完成，并主动向可信源（如支付平台）进行验证。
    • 最小化信息泄露： 返回给客户端的信息应遵循最小化原则。

希望这篇详细的文档能为您提供有价值的安全技术洞察。请务必在合法授权范围内进行安全测试。

逻辑漏洞挖掘新思路：从信息泄露到状态篡改的深入利用 文档说明： 本文档基于公开的技术研究文章《漏洞挖掘-逻辑漏洞挖掘中的一些新思路》进行梳理和扩展，旨在系统性地阐述其中揭示的三种高级逻辑漏洞利用手法。所有案例均已修复，本文仅用于安全技术教学与研究，旨在提升安全人员的安全意识与防护能力。 一、 任意用户登录接管：信息泄露与响应包替换的组合利用 这是一种结合了敏感信息泄露和认证逻辑缺陷的链式漏洞利用手法。 1. 漏洞背景与发现： 目标： 某景区服务小程序。 测试功能点： “我的意见”功能（通常为反馈、投诉入口）。 测试方法： 清理浏览器或代理工具（如Burp Suite）的历史记录后，操作特定功能，观察产生的所有HTTP请求，避免干扰。 2. 漏洞挖掘过程： Step 1: 发现信息泄露漏洞 在“我的意见”功能中提交信息后，通过拦截或观察HTTP请求，发现一个查询接口： GET /minibgs2/public/index/suggest/sug_info/?id=570 该接口 无需任何身份认证Token或Cookie ，仅通过修改URL中的 id 参数，即可直接返回对应用户的敏感信息，包括 用户ID、姓名、手机号 等（即“二要素”）。 漏洞点： 接口未对当前会话权限做校验，导致越权信息泄露。 Step 2: 规模化利用信息泄露 利用工具： 编写脚本或使用Burp Intruder等工具，自动化遍历 id 参数（例如从1到10000）。 数据提取： 从返回包中正则匹配提取 姓名 和 手机号 。 成果： 成功批量获取大量用户敏感信息（文中提及约5k条）。 Step 3: 定位认证逻辑缺陷 转向另一功能点： 测试“我的套餐券”功能，该功能需要手机号验证码登录。 分析登录流程： 输入手机号获取验证码。 输入验证码登录。 关键发现： 登录成功后的服务器响应包中， 没有返回标准的Token、Session 等鉴权凭证，而是返回了一个看似是Base64编码的 data 字段。 {"code": 100, "msg": "验证通过", "data": "MDU3MjAxxxxxxxxx0MzE1NjYwMA=="} 解码分析： 对 data 参数进行Base64解码后，发现其内容即为 当前登录用户的手机号拼接上一个固定的字符串（如0572030） 。这意味着整个登录状态的维持依赖于这个可预测、可伪造的返回值。 Step 4: 完成任意用户接管 攻击流程： 攻击者使用自己的手机号正常接收验证码，进行登录操作。 在Burp Suite中拦截登录过程的 响应包 。 将响应包中的 data 字段替换为 事先通过信息泄露漏洞获取到的目标用户手机号 编码后的值。 放行被篡改的响应包至客户端（小程序）。 结果： 客户端小程序接收到响应后，会误以为当前登录的是目标用户，从而成功接管其账号，可以查看和操作其订单等敏感信息。 3. 核心要点总结： 漏洞链： 信息泄露（无权限校验） -> 认证凭证可预测/可伪造 -> 响应包替换。 关键思路： 不要只盯着请求包， 服务器返回的响应包同样可能是逻辑漏洞的关键 。认证凭证不一定总是复杂的Token，可能是简单的、可预测的用户标识。 防御措施： 所有查询接口必须进行严格的权限校验，确保用户只能访问属于自己的数据。 认证成功的凭证应使用不可预测、高熵值的随机值（如JWT、随机Session ID）。 避免将敏感信息或认证标识直接编码后返回给客户端。 二、 支付状态签名复用：状态校验逻辑绕过 这是一种通过“复用”正常流程中的成功状态响应包，来绕过支付校验的逻辑漏洞。 1. 漏洞背景与发现： 目标： 某医院挂号系统。 测试业务： 在线挂号支付业务。 2. 漏洞挖掘过程： Step 1: 分析正常支付流程 正常选择科室、医生、时间，生成订单。 完成支付（微信付款）。 支付成功后，服务器会返回一个“支付成功”的响应包。 POST /api/bz/order/Sta/appoint {"code":0, "message": “支付成功”, "data":null} Step 2: 首次尝试与失败 初始想法： 尝试在支付环节拦截请求或响应，修改金额或状态。但支付流程通常与第三方支付平台交互，难以直接绕过。 另一种思路： 在生成订单后， 不进行实际支付 ，而是直接尝试访问“验证支付状态”的接口。 操作：生成订单后，在支付页面取消支付（文中提及“叉掉二维码”），此时系统会去检查支付状态。 拦截并替换 这个检查状态的请求的响应包，将其改为之前捕获的“支付成功”响应包。 结果： 首次尝试失败。订单状态并未变为成功。 Step 3: 深入分析与关键发现 对比正常支付成功和检查状态失败的响应包，发现了一个关键差异：成功响应包的Header中包含一个类似追踪ID或签名的字段（例如： tlogTraceId: jyvU1094795431411044352 ）。 该字段很可能与订单号绑定，并由支付平台或后端在成功支付后生成，用于唯一标识一次成功的交易。简单的响应包替换无法伪造这个签名。 Step 4: 脑洞大开的“签名复用” 核心思路： 虽然不能伪造签名，但可以 复用 一次 真实产生 的成功签名。 攻击流程： 正常支付一笔订单A （牺牲少量资金），并完整捕获从支付到最终成功返回的 所有HTTP响应 ，保存整个成功的响应包（包括Header和Body）。 重新下单，生成一个 新的订单B 。 在新订单B的支付页面，取消支付，触发系统对订单B的 支付状态检查 。 拦截 检查订单B支付状态 的请求所对应的 响应包 。 将整个响应包（包括成功的Code、Message、以及关键的Header签名 tlogTraceId ）全部替换为之前订单A的成功响应包 。 放行被篡改的响应包。 结果： 后端系统接收到成功的状态响应，误认为订单B已经支付成功，从而生成有效的就医凭证。攻击者可以凭此凭证直接去医院就诊， 实现了支付绕过 。（文中提到订单列表可能不显示，但核心凭证已生成） 3. 核心要点总结： 漏洞本质： 支付状态校验接口过于信任客户端（或网络传输中）的响应信息，未能与支付平台进行二次有效验证。 关键思路： “签名”或“令牌”在 一次有效会话中可能是可复用的 。通过“牺牲”一个低价值订单，获取一个高价值订单的免费权限。 防御措施： 支付状态校验必须由服务器后端主动、直接地向支付平台查询确认， 绝不能依赖客户端提供的任何信息 。 用于状态校验的令牌（如 tlogTraceId ）必须与订单号强绑定，且一次性有效。 三、 鉴权参数定位与响应包篡改：状态码操控 这种手法专注于识别应用程序中控制业务逻辑的关键参数，并通过篡改响应包中的这些参数来欺骗前端或后端。 1. 漏洞背景与发现： 目标： 某景区门票购买业务。 测试业务： 购买景点门票。 2. 漏洞挖掘过程： Step 1: 分析正常流程 正常选择门票、数量，下单并支付。 捕获支付成功后的所有响应包。 Step 2: 定位关键鉴权参数 与第一个案例不同，此次的响应包没有明显的认证信息，但包含了大量数据。 通过仔细对比分析支付成功和支付失败的响应包， 识别出三个控制出票逻辑的核心状态参数 （参数名可能为 type , status , payStatus 等，原文未明确给出）。 假设其值如下： 支付失败： "param1": 1, "param2": 0, "param3": 0 支付成功： "param1": 0, "param2": 1, "param3": 1 这些参数直接决定了前端是否显示出票成功，以及后端是否生成有效门票凭证。 Step 3: 实施攻击 攻击流程： 正常下单，但在支付环节中断支付（不实际付款）。 触发系统对支付状态的查询。 拦截状态查询的 响应包 。 在响应包中， 将控制业务的几个关键参数的值从“失败”状态篡改为“成功”状态 。 放行响应包。 结果： 应用程序（前端或后端）根据被篡改的参数值，判断为支付成功，从而生成有效门票。攻击者无需付费即可获得门票。 3. 核心要点总结与拓展： 漏洞本质： 应用程序将业务逻辑的决定权依赖于HTTP响应中的明文参数，这些参数容易被篡改。 关键思路： 渗透测试不应仅限于修改 请求 参数，更要注重分析并篡改 响应 参数。需要具备通过对比分析， 精准定位关键参数 的能力。 通用测试方法： 密切关注HTTP状态码（如404->200）。 关注业务状态码（如 code: 500 -> 200 , status: 0 -> 1 ）。 关注数据内容（如 data: null -> {...} ）。 防御措施： 核心业务逻辑应在服务器后端完成，决策结果不应依赖于客户端传递或返回的任何参数。 敏感操作的结果应由服务器通过安全通道直接通知前端，或前端再次向服务器发起验证请求。 四、 总结与建议 本文介绍的三种新思路，打破了传统逻辑漏洞测试中只注重请求参数的思维定式，强调了 信息泄露的深层次利用 、 响应包的重要性 以及 业务状态参数的操控 。 测试思路转变： 从“修改请求”扩展到“拦截与篡改响应”，从“单一漏洞点”扩展到“漏洞链利用”。 重点关注对象： 任何无需认证的API接口（信息泄露源头）。 登录、注册、支付、状态查询等关键业务流程的响应包。 响应包中的状态码、明文参数、Base64等编码数据。 防御设计原则： 权限校验： 所有接口必须施行严格的访问控制。 不可预测性： 认证凭证和重要令牌必须是高随机性的。 服务器端校验： 核心业务逻辑和状态决策必须在服务器端完成，并主动向可信源（如支付平台）进行验证。 最小化信息泄露： 返回给客户端的信息应遵循最小化原则。 希望这篇详细的文档能为您提供有价值的安全技术洞察。请务必在合法授权范围内进行安全测试。