当前位置：首页 > news >正文

支付漏洞攻防实战：从靶场演练到业务安全加固

news 2026/8/8 22:43:47

1. 从一笔“消失”的订单说起：支付漏洞的实战价值

上周，一个做电商的朋友半夜给我打电话，语气里透着焦虑。他告诉我，技术团队在内部测试时发现了一个“诡异”的现象：一个测试账号在提交订单后，没有实际支付，但后台却显示订单状态为“已支付并发货”。这听起来像是个低级错误，但排查后发现，问题出在一个第三方支付回调接口的校验逻辑上——攻击者可以伪造支付成功的通知，直接“骗过”系统。这就是一个典型的支付漏洞。它不像SQL注入或XSS那样广为人知，但一旦被利用，造成的直接经济损失和业务逻辑混乱，对任何涉及线上交易的系统都是致命的。

支付漏洞，简单来说，就是应用程序在处理支付流程时，由于逻辑设计缺陷、参数校验不严或业务流程割裂，导致攻击者能够在不支付、少支付或支付异常的情况下，完成交易、获取商品或服务。它属于业务逻辑漏洞的范畴，其危害性极高，因为它直接绕过了系统的核心盈利与安全防线。对于安全从业者、开发人员乃至业务负责人，理解支付漏洞的原理、掌握其挖掘与防御方法，都是一项至关重要的技能。

而学习这项技能最高效、最安全的方式，就是通过靶场。靶场提供了一个完全受控、合法的模拟环境，里面预置了各种精心设计的漏洞场景。你可以像黑客一样去攻击它，但不会触犯任何法律，也不会对真实业务造成损害。通过反复在靶场中演练，你不仅能深刻理解漏洞的成因，更能固化一套完整的测试与防御思路。今天，我们就以几个经典的支付漏洞场景为例，结合热门的靶场环境，进行一次深入的“攻防演示”。

2. 支付漏洞的核心攻击面与原理拆解

支付流程看似一条直线：用户提交订单 -> 选择支付方式 -> 跳转至支付网关 -> 支付成功 -> 返回商户页面 -> 更新订单状态。但实际上，这条线上的每一个环节都可能存在薄弱点。我们可以将其抽象为几个核心的攻击面。

2.1 价格参数篡改：客户端的不信任

这是最常见也最直观的一类漏洞。其根源在于过度信任客户端提交的数据。

攻击原理：在用户提交订单到生成支付单据的过程中，商品单价、总价、运费、优惠金额等关键价格参数，有时会以隐藏表单字段（<input type="hidden">）、JSON请求体或URL参数的形式，从前端传递到后端。如果后端服务器没有在生成最终支付金额时，重新从可信的数据库或会话（Session）中读取并计算这些值，而是直接使用了客户端传过来的值，那么攻击者就可以通过抓包工具（如Burp Suite）拦截请求，修改这些参数。

一个典型场景：一件商品标价100元，在提交订单的HTTP请求中，你可能会发现这样一个字段：total_amount=100.00。将其修改为total_amount=0.01并转发请求。如果后端没有校验，那么生成支付二维码或跳转支付页面的金额就变成了0.01元。你支付1分钱，却拿到了价值100元的商品。

注意：这里的篡改可能发生在“生成支付订单”的请求，也可能发生在“支付回调验证”后更新订单状态的请求中。关键在于，任何来自客户端、关乎最终交易金额和状态的参数，都必须被视为不可信的。

2.2 订单状态篡改与未授权访问：流程的断裂

这类漏洞利用了支付流程中“状态同步”的脆弱性。

攻击原理：支付成功与否，本质上是一个状态（Status）。这个状态通常由支付平台通过“异步回调”（Callback）或“同步返回”（Return）通知商户系统。漏洞常出现在：

状态值可预测/可遍历：订单状态用简单的数字表示，如status=2代表已支付。攻击者可能通过遍历其他订单ID，尝试将未支付订单的status参数直接改为2，从而绕过支付。
支付成功验证逻辑缺失：系统仅检查支付平台是否“有回调”，而没有严格验证回调信息的真实性（如签名、订单号、金额是否匹配）。攻击者可以伪造一个支付成功的HTTP请求，直接发送到系统的回调接口。
未授权订单查询/操作：系统在查询或修改订单状态时，没有校验当前用户是否是该订单的拥有者。攻击者通过修改请求中的订单ID参数，就能查看或操作他人的订单，结合其他漏洞可能完成非法支付状态确认。

2.3 数量与负数攻击：边界外的逻辑

这类漏洞考验的是系统对业务参数边界和数学逻辑的校验。

攻击原理：

数量溢出：购买数量参数quantity为整数型。如果系统设计是总价 = 单价 * 数量，并且使用了有符号整数（如int），那么当攻击者设置一个极大的数量（如999999999），可能导致总价计算溢出，变成一个极小的值甚至负数。更常见的是，设置一个负数（如-1），可能使总价变为负数，从而“增加”用户余额或直接完成“零元购”。
优惠券/积分滥用：在应用优惠券或抵扣积分时，如果允许重复使用、叠加使用，或者抵扣金额大于订单金额时，没有正确处理余额（例如，不应返还现金，而应清零），可能导致用户以极低成本甚至零成本完成支付。

2.4 时间竞争条件：毫秒间的漏洞

这是一种相对高级但危害巨大的漏洞，在抢购、限量优惠场景下尤其致命。

攻击原理：在“检查库存”和“锁定库存/创建订单”两个操作之间，存在一个微小的时间窗口。攻击者同时发起大量并发请求（例如使用脚本同时提交100个相同商品的订单）。由于服务器处理需要时间，在第一个请求检查库存时（假设库存为1），它看到库存充足；但在它完成库存锁定之前，其他99个请求也通过了库存检查。最终，系统可能为这100个请求都创建了订单，导致超卖。在支付环节，这可能表现为“库存检查通过并生成待支付订单”的逻辑存在竞争，使得多个用户获得了支付同一份稀缺商品的资格。

3. 靶场实战：在Pikachu中亲手“破解”支付逻辑

理论讲得再多，不如亲手试一次。我们以非常流行的Pikachu漏洞靶场为例，它内置了一个“越权购买（Overpermission）”的支付漏洞场景，非常适合入门演示。请注意，以下所有操作均在本地或授权环境进行。

3.1 环境搭建与目标确认

首先，你需要一个运行中的Pikachu靶场。你可以从其官网或GitHub仓库下载源码，使用PHPStudy、Docker等工具在本地搭建。假设你的访问地址是http://localhost/pikachu。

访问漏洞模块：登录Pikachu平台后，在左侧导航栏找到“越权漏洞(Over Permission)”->“越权购买(Overpermission)”。
理解场景：页面会展示一个商品列表，例如“苹果笔记本”售价8888元，“西瓜”售价1元。普通用户（如lucy）登录后，只能看到商品和价格。我们的目标是，尝试以非正常价格（比如1元）购买苹果笔记本。

3.2 漏洞挖掘与利用步骤

这个场景模拟的正是“价格参数篡改”漏洞。

第一步：正常流程抓包分析

用lucy账号登录。
打开浏览器开发者工具（F12）的“网络(Network)”选项卡，并保持录制状态。
在页面上，尝试购买一个“西瓜”（价格低，方便观察）。点击“购买”按钮。
在网络请求中，你会找到一个向purchase.php或类似接口发起的POST请求。点击查看其“载荷(Payload)”或“请求体(Request Body)”。

第二步：分析请求参数你可能会看到如下形式的参数：

product_id=2&price=1.00&quantity=1&...&submit=buy

这里，product_id=2可能对应西瓜，price=1.00是西瓜的单价。关键点在于：这个price参数是从前端传过来的。

第三步：篡改参数，实施攻击

我们需要知道苹果笔记本的product_id。可以通过查看页面源码，或者尝试遍历（比如改成product_id=1）。
我们使用专业的抓包改包工具Burp Suite来更精确地操作。
- 配置浏览器代理指向Burp Suite。
- 在Burp的Proxy->Intercept选项卡，确保拦截是开启的。
- 回到浏览器，再次点击购买“西瓜”。请求会被Burp拦截。
在Burp的拦截窗口中，修改请求参数：
- 将product_id修改为苹果笔记本对应的值（例如1）。
- 最关键的一步：将price参数从1.00修改为一个极低的值，例如0.01。
- 点击“Forward”转发修改后的请求。
观察结果：回到浏览器页面，如果漏洞存在，系统很可能会提示“购买成功”，并且订单记录显示你以0.01元的价格买到了苹果笔记本。后台的逻辑直接信任了你提交的price和product_id，没有去数据库重新查询和校验。

3.3 漏洞根因与修复思路

根因分析：后端purchase.php脚本的伪代码可能如下：

// 错误示例：直接使用客户端传来的价格 $product_id = $_POST['product_id']; $price = $_POST['price']; $quantity = $_POST['quantity']; $total = $price * $quantity; // 直接创建订单，使用$total作为实付金额 create_order($product_id, $quantity, $total);

问题一目了然：$price和$product_id完全来自用户输入，没有进行二次校验。

修复方案：正确的逻辑应该是：

// 正确示例：以服务器存储的数据为准 $product_id = intval($_POST['product_id']); // 至少做类型转换 $quantity = intval($_POST['quantity']); // 根据product_id，从数据库中查询出商品的真实价格 $real_price = query_database("SELECT price FROM products WHERE id = ?", [$product_id]); if ($real_price === false) { die("商品不存在"); } // 使用数据库中的真实价格进行计算 $total = $real_price * $quantity; // 还可以在这里检查$total是否与前端传来的某个“参考总价”大致相等（允许微小浮点误差），作为辅助校验 // $client_total = floatval($_POST['total_amount']); // if (abs($total - $client_total) > 0.01) { die("数据异常"); } create_order($product_id, $quantity, $total);

核心原则：关键业务逻辑（尤其是金额、状态）的决策依据，必须来源于服务器端的可信数据源（数据库、Session），绝不能依赖客户端提交的参数。客户端传来的数据只能作为“引用”或“标识”，真正的值必须在服务端重新查询、计算。

4. 深入DVWA靶场：探索更隐蔽的支付绕过

Pikachu的例子比较直接。我们提升一点难度，看看在DVWA (Damn Vulnerable Web Application)靶场中，一个关于“购买凭证”的漏洞如何被利用。DVWA的漏洞场景通常更贴近真实代码片段。

假设DVWA有一个漏洞模块叫“购买商品”，其核心逻辑是：

用户点击购买，生成一个待支付的订单，状态为pending，并获得一个临时order_token。
用户被引导到模拟支付页面，支付成功后，支付平台会调用一个回调URL，例如callback.php?order_id=123&token=abc&status=success。
callback.php验证token的有效性，并更新订单状态为paid。

4.1 漏洞挖掘：伪造支付回调

攻击路径：

获取订单信息：正常创建一个订单，用Burp Suite拦截所有请求。记录下你的order_id和系统生成的order_token。这个token通常是随机的，难以猜测。
分析回调机制：查看前端代码或网络请求，找到支付成功后的回调地址格式。假设是/callback.php。
尝试未经验证的回调：直接在你的浏览器或Burp的Repeater模块中，构造一个请求：
```
GET /callback.php?order_id=你的订单ID&token=你的正确token&status=success HTTP/1.1
```
发送请求。如果成功返回并提示订单支付完成，说明回调接口是可被外部直接访问的。
探索漏洞：真正的漏洞可能出现在以下方面：
- Token可预测/不变：如果你发现同一个用户的多个订单，其token有规律（如基于时间生成），你可能预测其他订单的token。
- 状态值可遍历：将status参数改为success以外的值，如paid、completed、2等，看是否能触发成功状态。
- 签名缺失：最严重的问题是，这个回调没有任何签名验证。在真实的支付接口中，支付平台会使用商户密钥，对所有回调参数生成一个数字签名（如MD5、RSA），附在回调请求中。商户服务器必须用同样算法验签，通过后才认为回调是真实的。DVWA的漏洞模块很可能省略了这一步，使得攻击者可以完全伪造回调请求。

伪造攻击：攻击者无需真正支付，只需在创建订单后，手动向callback.php发送一个伪造的“支付成功”请求，并提供正确的order_id和token（这个token在创建订单时已被攻击者知晓），即可将订单状态标记为已支付。

4.2 修复之道：签名验证与状态机

修复方案：

引入签名验证：

// callback.php 中的验证逻辑 $order_id = $_GET['order_id']; $received_sign = $_GET['sign']; // 支付平台传来的签名 $status = $_GET['status']; // 1. 根据order_id从数据库取出该订单的密钥、金额等信息 $order_info = get_order_info($order_id); $merchant_key = $order_info['merchant_key']; $amount = $order_info['amount']; // 2. 按照支付平台约定的规则，拼接签名字符串 $sign_string = "order_id={$order_id}&amount={$amount}&status={$status}&key={$merchant_key}"; // 3. 计算签名（例如MD5） $calculated_sign = md5($sign_string); // 4. 比对签名 if ($received_sign !== $calculated_sign) { die('Invalid sign!'); // 签名无效，拒绝请求 } // 5. 签名验证通过，再更新订单状态 update_order_status($order_id, $status);

这样，攻击者不知道merchant_key和正确的amount，就无法生成有效的sign，伪造的请求会被拒绝。

使用状态机管理订单：订单状态应从“待支付”到“已支付”到“已完成”等，有明确的转换路径和条件。在callback.php中，更新状态前应先检查当前状态是否为“待支付”，避免重复支付或状态回退。
校验支付金额：回调接口应校验支付平台回调中附带的amount是否与订单库中的amount一致，防止“1分钱买电脑”的篡改金额攻击在回调阶段发生。

5. 防御体系构建：从代码到流程的全面加固

通过靶场的演练，我们看到了支付漏洞的多种形态。防御不能只靠修补某一个点，而需要一套体系化的策略。

5.1 开发编码层：不信任原则与原子操作

一切输入皆不可信：这是黄金法则。所有来自客户端（前端、移动端、API调用方）的参数，包括URL、Header、Body中的任何字段，都必须进行严格的校验、过滤和类型转换。金额、数量必须是正数且符合业务范围。
关键数据服务端重算：订单总价、应付金额、折扣后价格等，必须由服务端根据从数据库读取的商品单价、优惠规则重新计算，绝不能使用前端传回的计算结果。前端计算值仅用于展示和用户确认。
使用不可预测的令牌：订单号、支付令牌（Token）、CSRF Token等应使用密码学安全的随机数生成器生成，确保其不可预测性和唯一性。
实现幂等性：支付回调接口必须实现幂等性。即无论同一个支付成功的回调被发送多少次，最终结果都只执行一次（订单状态只从“待支付”变为“已支付”一次）。这可以通过在数据库中记录回调处理日志或使用分布式锁来实现。
避免竞争条件：对“检查库存并扣减”这类操作，要使用数据库的事务（Transaction）和行级锁（SELECT ... FOR UPDATE）来保证其原子性，确保在并发请求下也不会超卖。

5.2 业务流程与架构层：解耦与监控

支付状态以支付平台为准：订单的“支付状态”应以支付平台的异步回调为唯一确认依据。用户支付后跳转回的“同步返回”页面仅用于展示“支付处理中”，不能作为支付成功的依据。
核心逻辑后置：发货、增加用户权益、赠送积分等核心业务操作，应在支付回调验证成功之后，通过消息队列异步触发。这样即使回调处理出现短暂延迟或重试，也不会影响支付主流程，同时业务逻辑更清晰。
建立对账与监控系统：
- 每日对账：每天定时将自家系统的订单支付记录与支付平台的后台交易记录进行比对，找出状态不一致（如平台成功我方失败、平台失败我方成功）的订单，及时人工介入处理。
- 实时监控：监控支付成功率、异常状态订单比例、同一IP/账号高频小额支付等异常模式，设置告警。
安全测试常态化：将支付流程作为业务逻辑测试的重中之重。在SIT（系统集成测试）和UAT（用户验收测试）阶段，引入专门的安全测试用例，模拟上述所有攻击场景。可以考虑引入模糊测试（Fuzzing），自动化地尝试大量异常、边界参数。

5.3 运维与响应层：最后的防线

日志记录详尽化：支付全链路（下单、跳转支付、同步返回、异步回调、状态更新）的每一个关键步骤，都必须打印包含唯一订单号、用户ID、关键参数、时间戳的详细日志。这些日志是事后审计和问题排查的生命线。
应急预案：提前制定支付漏洞（如发现异常订单、被黑客攻击）的应急预案。包括：如何快速定位受影响订单、如何临时关闭疑似有漏洞的接口、如何与支付平台协同冻结资金、如何与用户沟通等。
权限最小化：确保操作订单状态、金额的后台管理接口有严格的权限控制和操作日志。

支付漏洞的防御是一个贯穿软件开发生命周期（SDLC）的持续过程。从产品经理设计支付流程时考虑闭环，到开发人员编写每一行代码时秉持“不信任”原则，再到测试人员像攻击者一样思考，最后到运维人员建立监控与审计屏障，每一个角色都至关重要。靶场演练的价值，就在于让团队中的每一个人，都能在安全的环境中亲身体验攻击者的视角，从而在各自的工作中，自然而然地建立起这道坚固的防线。

查看全文

http://www.jsqmd.com/news/1355564/