05 规则之外：业务逻辑漏洞与拒绝服务

05 规则之外：业务逻辑漏洞与拒绝服务

业务逻辑漏洞指攻击者利用流程规则的漏洞，绕过业务预期达成非预期结果（如跳过付款、重复领赏、篡改定价），它不代码报错但损害业务正确性；拒绝服务攻击通过耗尽资源的请求或流量让服务不可用。前者针对“规则”，后者针对“可用性”，都要求从“流程正确性”与“资源可用性”两个视角防御。

第四幕收尾的两个问题不按“注入/ZXXX”的套路，而是打业务本身。业务逻辑漏洞靠的是“懂业务的人想通了规则的漏洞”，拒绝服务靠的是“多到让你忙不过来”的资源战争。两者与后面第七幕的威胁建模、运维应急强相关。

一、业务逻辑漏洞：绕过规矩才是它的本事

传统 AppSec 关注“数据没被破坏”，业务逻辑关注“流程别被绕过头”。常见形态：付款流程在回调前就发货、领券接口不限次数可重复刷、把下单数量改成负数做出负金额、把支付金额参数改成 0 元、抢购接口用脚本并发刷单。它们的功能都能正常跑，但规则的有意为之被绕过，造成的损失是直接的业务利益。

这类漏洞难自动化发现，因为必须结合业务语义判断。这也提示：业务逻辑校验不该只堆在某个角落，而应作为“业务规则在被越界输入下是否仍成立”的一种断言，在前置编排层做校验（例如支付金额以服务端订单额为准，不信前端）。

二、拒绝服务：让服务“忙不过来”

DoS 想让服务在规则上不可用。常见两类：单点级（一个慢查询、一个超大文件上传、一次复杂正则）消耗个别线程/资源导致局部卡死；分布式 DDoS 用海量分布式流量/请求把入口带宽或连接数打满。前者的缓解偏代码层（超时、限流、资源上限），后者的缓解偏架构与网络层（CDN 清洗、抗 DDoS、负载伸缩）。

拒绝服务的本质是把可用性（A）打崩，对应第一幕 CIA 里的 A。它可能需要比“修代码”更广的手段——网络层清洗、弹性伸缩、配额管理都要参与。

三、业务逻辑与 DDoS 的防御区别

业务逻辑漏洞靠规则语义的校验与编排：把“什么条件下允许发生什么”写清楚，在各种越界输入下仍成立；关键变更（支付、改密、发货）以服务端权威数据为准，少信前端提交的金额与状态。拒绝服务靠资源与可用性治理：最小化单点崩溃（超时、限流、配额）、架构弹性（缓存、水平扩容）、网络清洗（CDN/DDoS 防护）。两者一个防“规则被绕”，一个防“资源被耗”。

💡 关键直觉：业务逻辑的问题肉眼“看不出”，要靠“换一种身份/顺序/次数去试”。DDoS 的问题在“无法完全防住”，重点是把它进忠实反射与缩短影响窗口——这两类都不适合用注入类思维硬套。

四、业务逻辑漏洞的发现，靠“对手戏”打法

业务逻辑漏洞几乎没有自动化扫描能替你兜底，因为判断它对不对依赖业务语义。最有效的发现方式是“换个角色或流程去刁难它”：改待遇试用——用普通用户、新用户、老用户分别走一遍领券流程，看有没有某一类被绕过校验；改顺序试用——先发货后付款、先改价后下单、先领券后改数量，把流程顺序打乱看状态是否还成立；改次数试用——同一个动作反复执行、并发执行，看校验是否只在“第一次”成立。这三种“对手戏”凡是碰到某个环节“我以为它只该触发一次”却没有限制的，几乎都藏着一个业务逻辑漏洞。它不精巧，但它扎实，恰好是自动化覆盖不到的盲区。

五、拒绝服务不只是“被打”才发生

拒绝服务的诱因里常混着“被攻击”和“自己犯错”两类信号。一部分确实是恶意的 DDoS，另一部分往往是业务自身的峰值失守：一次慢查询索引没建、一个递归调用写崩了、一个大文件格式解析耗光 CPU。后者不是有人打你，而是系统自身在请求放大时先撑不住。所以抗可用性不能只买 CDN 清洗，还至少要在代码层列三项：把外部请求最关键路径上的重活做超时、给单用户/单动作上配额与限流、把能预热的查询和资源做缓存。分清“被打”与“自身脆”，你才知道钱该砸在网络边界还是内部架构。

六、一次完整的演练

背景一：一个下单-支付-发货流程，支付金额以请求里的参数为准。操作：把支付金额参数改为 0 再下单。结果：付款成功率通过但金额为 0。解读：业务状态被前端可篡改提交控制。变式：金额改以服务端订单额为准并二次校验，0 元单被拒。背景二：一个无超时与限流的文档接口，用一个大文件与若干并发请求压测。结果：响应变慢、部分超时。变式：加超时、限流与资源上限后，压测对服务影响明显收敛。

七、给业务规则加“极限输入”测试基线

业务逻辑漏洞最怕“正常流程跑通就验收”。让这类问题暴露得更早，可以在每条关键流程的测试里搭一组“极限输入”基线：把金额填成负数或极大值、把数量填成 0 或超限、把状态参数改成流程不允许的跳变（先发货后付款）、把同一请求并发重复发出。每一个都是正常人不会做、攻击者一定会试的姿势。把这些写进测试用例与回归，每次发版自动跑一遍，就能拦截“这次重构悄悄把负数判断删了”这类回归。拒绝服务这边同样给一层基线：为慢查询、大文件、递归请求设超时与资源上限，并为单用户单动作做配额，压测时留出“自身峰值”的观测点。业务逻辑守“规则语义”，拒绝服务守“资源可用”，两条基线的目标一致：让漏洞在开发期现形，而不是等事故把我请去善后。

本节要点回顾

• 业务逻辑用对手戏发现：换角色、顺序、次数去刁难流程，能挖出校验只成立一次的漏洞。
• 拒绝服务分外力与自重：既防恶意 DDoS，也防自身峰值失守，网络清洗与内部架构要一起投资。
• 业务逻辑漏洞靠绕过业务规则造成直接利益损失，本质是规则语义校验缺失。
• 高发于付款、领券、金额、抢购等有“预期规则”的流程。
• 拒绝服务打的是可用性，分单点耗尽与分布式打垮两类，缓解手段在代码层与网络层不同。
• 业务逻辑靠规则校验与编排，关键变更以服务端权威数据为准。
• 拒绝服务靠资源与可用性治理：超时限流、弹性扩展、CDN 清洗。