从支付宝“打八折事故”看业务安全为什么难做

据网络信息，支付宝在2024年1月16日14:40-14:45疑似出现重大BUG，多位支付宝用户表示自己在下午14:40-14:45期间通过购物、还信用卡、缴纳签证费用、加油、个人转账等各类支付操作时，均在订单支付时提示了“政府补贴”，减免优惠20%，相当于支付打了8折。

2024年1月17日凌晨 @支付宝 发文回应了该问题，提到是支付宝出现的一个失误导致小部分用户在支付时享受了立减优惠，并表示不会向用户追款。

这次事件的发生，可能平台用户或者广大网友看到的是“我错过了几个亿？”，但业务安全从业者看到的是“业务安全建设这条路仍困难重重”。

众所周知，安全圈有这么两类人，搞基础安全和搞业务安全的。作为一名有幸在基础安全厂商和业务安全厂商都“溜达”过的人，没法说二者谁更轻松，因为都不轻松。

但如果从风险的变化和带来的复杂度来看，业务安全需要考虑的面需要更多，很多时候，是事件发生了才知道。

“哦，原来是这里有问题”

从企业安全建设的角度来看，支付宝“打八折”这个P000级别的安全事件，并不是基础的安全防护出现明显的问题，比如支付接口本身存在严重的安全漏洞（相信支付宝在这块绝对是做了足够的安全建设），而是由于API接口承载了越来越多、越来越复杂的业务逻辑，一旦业务逻辑出现变化，就很容易引入新的风险；

同时，研发团队迭代各种业务功能、运营团队配置各种业务活动，这中间稍有不慎就可能会出错，比如出现业务逻辑配置错误。

我们在过往的服务案例中以及API攻击情报平台监测到的事件中也发现不少业务逻辑相关的安全问题。

如，我们之前在情报平台发现的一起由于业务逻辑问题导致的API敏感数据泄露事件。

该事件涉及的API接口按照安全要求，对接口请求都做了合法性校验，确保只有授权用户才能获取相关信息。

但在对事件复盘中发现，调用该接口的业务部门，编写的凭证校验的业务逻辑存在问题，导致攻击者通过刻意伪造用户凭证也可以通过验证，并返回指定用户ID的敏感信息。

此外，用户ID可被遍历，这意味着攻击者可以通过构造特定请求，逐步获取大量用户的个人信息。

“打八折”这个事情可以告一段落，但对广大业务安全从业者来说，“业务安全”这条路任重而道远。

>>>为什么说业务安全那么难做？

1.首先，业务安全建设的C位一定是企业自身。

业务是企业的私有资产，从业务研发到测试到最后上线，都是在企业内部完成。也就是说，业务问题的产生也是由企业自身产生，需要企业完全负责，即使有乙方厂商的参与，但由于缺乏对业务的足够理解，往往只能打辅助，因此对企业自身安全管理的挑战和压力都非常大。

2.其次，业务的全生命周期是一个不断变化的过程，在数字时代，业务迭代的速度更是到了一个前所未有的高度。

随着业务需求的变化，业务的实现逻辑也在发生变化，业务每天甚至每个小时都会更新，更新的过程可能就会引入新的风险点。

3.第三，业务安全是安全和业务交叉的岗位，会因为业务特性和风险属性的不同，需要采取不同的安全策略。

业务安全团队要达到业务和安全的平衡，需要的绝对不只是几个工具和几个模型，而是一整套匹配到自身业务的安全攻防系统，在不影响业务体验所需要的极高精准度的前提下，还需要实现极高的攻防效率。

对业务安全团队来说，业务的每一次更新就意味着风险面的再一次扩大。如何在不影响业务体验的前提下，快速发现风险点或者在事后快速阻断，是所有业务安全团队工作的关键。

支付宝这个事件，因其庞大的用户群体、影响面大，虽然也造成了很大的损失，但在问题出现时能够快速被发现和解决，但很多API攻击、业务欺诈的事件却是长期、低频进行的，在前期没有产生太大影响，但日积月累，最后造成的损失可能更大。

前面所举的案例也是在我们API情报系统发现了攻击事件后，客户通过复盘分析后才发现。这类长期进行的非P0级别事件所造成的危害同样不容忽视。

>>>企业如何做好业务体验和安全管控兼顾，避免从表面问题出发，而是有全局视角呢？

“业务风险情报”是关键手段，是业务安全体系设计的起点。

一方面，业务风险情报能力通过直接还原攻击场景的技术和人，再基于此去理解业务当前遇到的风险环境，这时候业务安全团队看到不只是技术问题，还能看到业务流程、关键对象、产品设计因素的影响、攻击方的手段影响、攻击方成本结构（便于我们理解自己的位置）、用户的风险流程等等。

有了这个全局视角后，再去看问题，这时候形成的落地方案就会避免局限在某个特定工具和手段上。

另一方面，业务攻击从产生到发展、规模化，往往有一个过程，对于那些不明显的攻击行为，基于外部情报快速发现攻击事件，在事后的早期及时阻断风险。

这就是情报的价值所在，也是威胁猎人的价值所在。