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

据网络信息，支付宝在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. 其次，业务的全生命周期是一个不断变化的过程，在数字时代，业务迭代的速度更是到了一个前所未有的高度。

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