【第五期】漏洞攻防-逻辑篇：越权与支付漏洞 —— 为什么改个参数就能“0元购”？

💡 导读 ：在上一期中，我们用 SQL 注入"骗"过了数据库。但有一种漏洞比 SQL 注入更可怕，因为它不需要任何黑客工具，只需要动动手指改个 ID，就能接管别人的账户、甚至把价值万元的商品改成 0.01 元买下。这就是 逻辑漏洞（Business Logic Vulnerability）。今天，我们就来聊聊黑客眼中的"支付"与"权限"。

---

一、 什么是逻辑漏洞？

核心定义 ：代码没有错，但业务流程错了。

传统的漏洞（如 SQL 注入）是因为代码写得不严谨导致被攻击；而逻辑漏洞往往是开发者"想少了"，导致业务流程可以被非正常地串联或篡改。

经典笑话：

开发：只要用户支付成功，我就发货。

黑客：如果我告诉你我支付成功了，哪怕我没付钱，你是不是也得发货？

---

二、 越权漏洞（Broken Access Control）

这是 OWASP Top 10 中排名第一的漏洞。简单来说："你本来只能看自己的工资条，结果你改了个数字，看到了老板的工资条。"

1. 水平越权（Peer-to-Peer）

场景：修改个人资料。

• 正常请求：

  http

  POST /update_profile HTTP/1.1
  {"user_id": 1001, "email": "my@email.com"}

• 攻击操作 ：用 Burp Suite 拦截请求，把 user_id改为 1002。

• 结果 ：如果你的邮箱绑定到了 1002这个用户身上，说明存在水平越权。你可以修改任何人的资料。

2. 垂直越权（Privilege Escalation）

场景：普通用户变管理员。

• 背景 ：普通用户访问 /admin会提示 403 Forbidden。

• 攻击操作 ：抓取一个普通用户的 Cookie，尝试直接访问 https://site.com/admin/delete_user.php?id=5。

• 结果 ：如果页面正常显示并执行了删除操作，说明存在垂直越权。

🔍 实战案例：某社交平台"窥探"漏洞

安全研究员发现，在查看私信时，URL 为 https://site.com/message?msg_id=888。

他写了一个 Python 脚本，循环遍历 msg_id从 1 到 100000。

后果：他读取了数万条陌生人的私密聊天记录，因为服务器没有校验"这条消息是否属于当前登录用户"。

---

三、 支付逻辑漏洞（"0元购"的实现）

这是逻辑漏洞中最具危害性（也是最容易坐牢）的部分。

1. 价格篡改（Price Manipulation）

场景：下单购买商品。

• 正常流程：前端显示价格 100 元 -> 后端生成订单 -> 调用支付宝支付 100 元 -> 支付成功 -> 发货。

• 漏洞点 ：前端传给后端的价格参数 $_POST['price'] = 100。

• 攻击操作 ：用 Burp Suite 拦截请求，修改 price=0.01。

• 结果：如果后端没有去数据库校验真实价格，而是直接相信前端传来的 0.01 元，那么恭喜你，实现了"0元购"。

2. 负数购买（Negative Amount）

场景：充值话费。

• 漏洞点：某些老旧系统在扣费时只做减法。

• 攻击操作 ：尝试输入充值金额为 -100。

• 结果：不仅没扣钱，反而账户余额增加了 100 元。

3. 并发竞争（Race Condition）

场景：优惠券抵扣。

• 背景：你有 1 张 50 元优惠券，买 50 元商品。

• 攻击操作 ：用 Burp Suite 的 Intruder​ 模块，同时发送 20 个支付请求。

• 结果：由于服务器处理速度跟不上，可能只核销了 1 张券，却成功下了 20 个订单。

---

四、 实战演练：如何测试逻辑漏洞？

在 OWASP Juice Shop​ 中，有一个经典的支付漏洞：

1. 登录普通用户，往购物车添加商品（总价 99 元）。

2. 进入结算页面，点击"支付"。

3. 打开 Burp Suite 拦截请求。

4. 观察请求体：

   json

   {
     "paymentId": 123,
     "total": 99.00,
     "products": [...]
   }

5. 修改 total为 0.01。

6. Forward（放行）。

7. 结果：订单显示支付成功，且状态为已发货。

💡 思考：为什么会有这个漏洞？因为开发人员偷懒，直接用前端计算的总价作为最终扣款依据，而没有在后端重新计算。

---

五、 2026 年防御视角：如何修复？

作为开发者或安全测试者，修复逻辑漏洞比找漏洞更难。

1. 永远不要相信前端 ：所有涉及到钱、权限的参数（价格、折扣、用户ID、角色等级），必须在**后端（Server-side）**进行校验和计算。

2. 权限校验 ：在执行任何操作前，问自己一句代码："当前登录的用户，有权限执行这个动作吗？"

3. 签名机制：对重要的参数（如价格）进行 Hash 签名（例如 MD5(price + salt)），一旦参数被篡改，签名就会失效。

---

⚠️ 安全警示与法律红线

🚨 极度严肃的警告：

1. 这是高压线 ：相比于 SQL 注入，利用支付漏洞 进行"0元购"或"负数充值"，在司法实践中极易被定性为盗窃罪 或诈骗罪。

2. 仅限靶场 ：本篇文章中提到的所有技巧（修改价格、并发测试），严禁在任何真实运行的电商平台、金融APP上尝试。

3. 测试边界 ：在授权测试中，一旦发现可以通过修改参数免费获取商品，请立即停止支付流程，仅提交漏洞报告，切勿实际收货。否则，即使有授权书，也可能面临民事纠纷甚至刑事责任。

君子爱财，取之有道。用你的技术去帮企业堵住漏洞，而不是利用漏洞牟利。

---

💬 互动环节

• 你见过最离谱的逻辑漏洞是什么？（比如买一送一，结果送的那个也算钱，导致倒贴钱？）

• 如果你是开发者，你会如何设计架构来防止"价格被篡改"？

• 欢迎在评论区留言讨论！

👉 下一期预告：【漏洞攻防-身份认证篇】JWT、Session 与 OAuth ------ 为什么你的登录令牌可能被伪造？