专注AI 大模型与前沿科技深度解析习惯从工程师视角拆解技术热点让我们一起在技术浪潮中保持清醒与好奇 AI 驱动复杂业务漏洞挖掘从业务规则建模到攻击路径验证去年秋天我在一个电商风控团队做安全评审。同事老周盯着屏幕上的订单流水突然指着一条记录说“这个用户连续三天每天凌晨两点下单每单都用三张不同银行的优惠券收货地址全在同一个小区但手机号每次都不一样。”我们查了三天最后发现这是一个薅羊毛团伙——他们没利用任何代码漏洞只是把平台的优惠规则研究得比产品经理还透。老周感慨“传统扫描器扫一万遍也扫不出这个因为逻辑上每一步都是合法的。”这件事让我意识到复杂业务漏洞的本质不是代码写错了而是规则被组合出了设计者没想到的效果。而 AI 在这件事上可能比人更适合当那个“把规则研究透”的角色。30 秒结论本文判断AI 驱动业务漏洞挖掘当前最务实的路径不是“让 AI 直接找漏洞”而是“让 AI 把业务规则翻译成可验证的状态机模型再由人来设计攻击路径”。AI 负责穷举组合人负责判断危害。适用对象在校学生、转行者、刚入行的安全工程师。你不需要有生产环境经验只要会写 Python、理解 HTTP 请求、能画状态图就能在本地复现一套最小可行流程。不适合谁如果你期待“一键挖洞”的工具或者想直接套用到真实线上系统做未授权测试这篇文章不适合你。本文所有示例均基于本地模拟环境。核心技能点业务规则建模 状态机遍历 攻击路径验证。这三件事组合起来就是可以写进作品集的一个完整小项目。关键证据事实一业务逻辑漏洞在漏洞赏金中的占比持续上升。根据公开的漏洞赏金平台统计逻辑类漏洞越权、支付绕过、优惠券滥用、流程跳过在近两年的高危漏洞中占比已超过 30%且平均奖金高于注入类漏洞——因为它更难被自动化工具发现。事实二大模型在“规则理解与组合”任务上表现突出。当前主流大模型如 GPT-5.5、Qwen3.6 Max、DeepSeek 4.0 Pro 等在结构化推理任务上已经能稳定完成“给定一组业务规则输出状态转移图”的工作。这不是让 AI 猜漏洞而是让 AI 做它擅长的事把自然语言规则转成形式化描述。事实三状态机遍历是经典且可落地的技术。模型检测Model Checking在硬件和协议验证领域已经用了三十年。把它搬到业务逻辑上核心思路不变枚举所有可达状态检查是否存在违反安全属性的路径。区别只在于业务规则的状态空间通常更小更适合用 AI 辅助建模。展开说明第一步把业务规则变成状态机假设我们有一个极简的优惠券系统规则如下用户注册后获得一张“满 100 减 20”券每笔订单只能用一张券券在订单支付后标记为已使用订单取消后券退回账户这四条规则用自然语言写出来人畜无害。但如果你把它画成状态机就会发现问题# 状态定义(订单状态, 券状态)# 订单状态: CREATED, PAID, CANCELLED# 券状态: AVAILABLE, LOCKED, USEDtransitions{(CREATED,AVAILABLE):[(CREATED,LOCKED)],# 下单锁券(CREATED,LOCKED):[(PAID,USED),# 支付(CANCELLED,AVAILABLE)],# 取消退券(PAID,USED):[(CANCELLED,AVAILABLE)],# 支付后取消}注意最后一行如果系统允许“已支付订单取消并退券”那么用户就可以反复下单、支付、取消券永远退回。如果这个过程中还有积分奖励或返现就形成了无限循环套利。这就是 AI 建模的价值它不会“觉得”某条路径不可能它只会忠实地枚举。你可以用当前主流大模型做这件事提示词大致如下给定以下业务规则输出所有可能的状态转移路径 并标记每条路径是否可能导致资源重复使用 [规则文本]大模型会输出一个比你手画更完整的转移表。然后你把这张表转成代码用 BFS 遍历所有可达状态。第二步定义安全属性让遍历有的放矢状态空间可能很大盲目遍历没有意义。你需要定义“什么算漏洞”。常见的安全属性有三类资源守恒券的总数不能增加积分不能凭空产生权限单调用户不能通过任何操作序列获得未授予的权限状态不可逆已支付订单不能回到未支付状态除非有明确的退款流程把这三条写成断言遍历时检查每个状态是否违反断言。违反的路径就是候选攻击路径。第三步攻击路径验证——从模型回到真实请求模型里发现的路径未必在真实系统里可行。因为真实系统可能有额外的校验、频率限制、并发控制。所以最后一步是把模型输出的路径翻译成真实的 HTTP 请求序列在本地模拟环境里跑一遍。# 模型输出CREATED/AVAILABLE - CREATED/LOCKED - PAID/USED - CANCELLED/AVAILABLE# 翻译成请求序列requests[(POST,/api/order/create,{coupon_id:C123}),(POST,/api/order/pay,{order_id:O456}),(POST,/api/order/cancel,{order_id:O456}),# 检查券是否退回(GET,/api/coupon/C123,None),]如果第三步返回的券状态是 AVAILABLE而订单已经支付过那么你就验证了一个真实的业务逻辑漏洞。面试/作业里常被追问的点你如何区分“模型误报”和“真实漏洞”答案是模型只负责生成候选路径验证必须回到真实系统。任何没有经过请求验证的路径都只能叫“疑似”。落地建议今天就能做的三件事选一个你熟悉的业务场景用自然语言写出 5-10 条规则然后让大模型帮你画状态转移图。不需要写代码先感受“规则组合”的威力。比如外卖平台的满减、图书馆的借阅续借、校园网的流量套餐。用 Python 写一个 50 行以内的 BFS 遍历器输入状态转移表输出所有可达状态。这是可以写进作品集的最小完整项目。代码不需要依赖任何公司内部基础设施本地跑就行。找一个开源的小型 Web 应用比如一个开源的优惠券系统在本地部署用上面的方法跑一遍。把发现的疑似路径整理成报告格式参考漏洞赏金平台的报告模板。这就是你的作品集素材。风险与反例什么情况下这套方法不成立规则本身无法形式化如果业务规则大量依赖人工审核、模糊判断、外部系统状态状态机建模会失真。比如“风控系统认为这笔订单可疑”——这个“可疑”没有明确边界模型无法处理。状态空间爆炸如果业务有几十个相互关联的实体状态空间可能是指数级的。这时候需要先做抽象只保留与安全属性相关的状态变量。抽象不当会漏掉漏洞。并发与竞态状态机模型通常是串行的但真实系统是并发的。两个请求同时到达时可能出现模型里不存在的中间状态。这类漏洞需要额外的并发模型超出了本文范围。法律与授权所有验证必须在你自己拥有或明确授权的系统上进行。对未授权系统做攻击路径验证无论是否造成损害都可能违法。最后回到老周那个案例。如果当时我们用这套方法把优惠券规则、用户注册规则、收货地址规则一起建模可能第一天就能发现“同一小区多手机号凌晨下单”这条路径在模型里是可达的。AI 不会替你决定这是不是漏洞但它会告诉你这条路走得通你要不要看看 AI 驱动复杂业务漏洞挖掘：从业务规则建模到攻击路径验证
专注AI 大模型与前沿科技深度解析习惯从工程师视角拆解技术热点让我们一起在技术浪潮中保持清醒与好奇 AI 驱动复杂业务漏洞挖掘从业务规则建模到攻击路径验证去年秋天我在一个电商风控团队做安全评审。同事老周盯着屏幕上的订单流水突然指着一条记录说“这个用户连续三天每天凌晨两点下单每单都用三张不同银行的优惠券收货地址全在同一个小区但手机号每次都不一样。”我们查了三天最后发现这是一个薅羊毛团伙——他们没利用任何代码漏洞只是把平台的优惠规则研究得比产品经理还透。老周感慨“传统扫描器扫一万遍也扫不出这个因为逻辑上每一步都是合法的。”这件事让我意识到复杂业务漏洞的本质不是代码写错了而是规则被组合出了设计者没想到的效果。而 AI 在这件事上可能比人更适合当那个“把规则研究透”的角色。30 秒结论本文判断AI 驱动业务漏洞挖掘当前最务实的路径不是“让 AI 直接找漏洞”而是“让 AI 把业务规则翻译成可验证的状态机模型再由人来设计攻击路径”。AI 负责穷举组合人负责判断危害。适用对象在校学生、转行者、刚入行的安全工程师。你不需要有生产环境经验只要会写 Python、理解 HTTP 请求、能画状态图就能在本地复现一套最小可行流程。不适合谁如果你期待“一键挖洞”的工具或者想直接套用到真实线上系统做未授权测试这篇文章不适合你。本文所有示例均基于本地模拟环境。核心技能点业务规则建模 状态机遍历 攻击路径验证。这三件事组合起来就是可以写进作品集的一个完整小项目。关键证据事实一业务逻辑漏洞在漏洞赏金中的占比持续上升。根据公开的漏洞赏金平台统计逻辑类漏洞越权、支付绕过、优惠券滥用、流程跳过在近两年的高危漏洞中占比已超过 30%且平均奖金高于注入类漏洞——因为它更难被自动化工具发现。事实二大模型在“规则理解与组合”任务上表现突出。当前主流大模型如 GPT-5.5、Qwen3.6 Max、DeepSeek 4.0 Pro 等在结构化推理任务上已经能稳定完成“给定一组业务规则输出状态转移图”的工作。这不是让 AI 猜漏洞而是让 AI 做它擅长的事把自然语言规则转成形式化描述。事实三状态机遍历是经典且可落地的技术。模型检测Model Checking在硬件和协议验证领域已经用了三十年。把它搬到业务逻辑上核心思路不变枚举所有可达状态检查是否存在违反安全属性的路径。区别只在于业务规则的状态空间通常更小更适合用 AI 辅助建模。展开说明第一步把业务规则变成状态机假设我们有一个极简的优惠券系统规则如下用户注册后获得一张“满 100 减 20”券每笔订单只能用一张券券在订单支付后标记为已使用订单取消后券退回账户这四条规则用自然语言写出来人畜无害。但如果你把它画成状态机就会发现问题# 状态定义(订单状态, 券状态)# 订单状态: CREATED, PAID, CANCELLED# 券状态: AVAILABLE, LOCKED, USEDtransitions{(CREATED,AVAILABLE):[(CREATED,LOCKED)],# 下单锁券(CREATED,LOCKED):[(PAID,USED),# 支付(CANCELLED,AVAILABLE)],# 取消退券(PAID,USED):[(CANCELLED,AVAILABLE)],# 支付后取消}注意最后一行如果系统允许“已支付订单取消并退券”那么用户就可以反复下单、支付、取消券永远退回。如果这个过程中还有积分奖励或返现就形成了无限循环套利。这就是 AI 建模的价值它不会“觉得”某条路径不可能它只会忠实地枚举。你可以用当前主流大模型做这件事提示词大致如下给定以下业务规则输出所有可能的状态转移路径 并标记每条路径是否可能导致资源重复使用 [规则文本]大模型会输出一个比你手画更完整的转移表。然后你把这张表转成代码用 BFS 遍历所有可达状态。第二步定义安全属性让遍历有的放矢状态空间可能很大盲目遍历没有意义。你需要定义“什么算漏洞”。常见的安全属性有三类资源守恒券的总数不能增加积分不能凭空产生权限单调用户不能通过任何操作序列获得未授予的权限状态不可逆已支付订单不能回到未支付状态除非有明确的退款流程把这三条写成断言遍历时检查每个状态是否违反断言。违反的路径就是候选攻击路径。第三步攻击路径验证——从模型回到真实请求模型里发现的路径未必在真实系统里可行。因为真实系统可能有额外的校验、频率限制、并发控制。所以最后一步是把模型输出的路径翻译成真实的 HTTP 请求序列在本地模拟环境里跑一遍。# 模型输出CREATED/AVAILABLE - CREATED/LOCKED - PAID/USED - CANCELLED/AVAILABLE# 翻译成请求序列requests[(POST,/api/order/create,{coupon_id:C123}),(POST,/api/order/pay,{order_id:O456}),(POST,/api/order/cancel,{order_id:O456}),# 检查券是否退回(GET,/api/coupon/C123,None),]如果第三步返回的券状态是 AVAILABLE而订单已经支付过那么你就验证了一个真实的业务逻辑漏洞。面试/作业里常被追问的点你如何区分“模型误报”和“真实漏洞”答案是模型只负责生成候选路径验证必须回到真实系统。任何没有经过请求验证的路径都只能叫“疑似”。落地建议今天就能做的三件事选一个你熟悉的业务场景用自然语言写出 5-10 条规则然后让大模型帮你画状态转移图。不需要写代码先感受“规则组合”的威力。比如外卖平台的满减、图书馆的借阅续借、校园网的流量套餐。用 Python 写一个 50 行以内的 BFS 遍历器输入状态转移表输出所有可达状态。这是可以写进作品集的最小完整项目。代码不需要依赖任何公司内部基础设施本地跑就行。找一个开源的小型 Web 应用比如一个开源的优惠券系统在本地部署用上面的方法跑一遍。把发现的疑似路径整理成报告格式参考漏洞赏金平台的报告模板。这就是你的作品集素材。风险与反例什么情况下这套方法不成立规则本身无法形式化如果业务规则大量依赖人工审核、模糊判断、外部系统状态状态机建模会失真。比如“风控系统认为这笔订单可疑”——这个“可疑”没有明确边界模型无法处理。状态空间爆炸如果业务有几十个相互关联的实体状态空间可能是指数级的。这时候需要先做抽象只保留与安全属性相关的状态变量。抽象不当会漏掉漏洞。并发与竞态状态机模型通常是串行的但真实系统是并发的。两个请求同时到达时可能出现模型里不存在的中间状态。这类漏洞需要额外的并发模型超出了本文范围。法律与授权所有验证必须在你自己拥有或明确授权的系统上进行。对未授权系统做攻击路径验证无论是否造成损害都可能违法。最后回到老周那个案例。如果当时我们用这套方法把优惠券规则、用户注册规则、收货地址规则一起建模可能第一天就能发现“同一小区多手机号凌晨下单”这条路径在模型里是可达的。AI 不会替你决定这是不是漏洞但它会告诉你这条路走得通你要不要看看