互联网大厂的支付系统的安全性应该是如何设计的?

Posted JavaEdge.

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了互联网大厂的支付系统的安全性应该是如何设计的?相关的知识,希望对你有一定的参考价值。

安全兜底分级:

  1. 无限额涉及钱
    比如退款
  2. 限额涉及钱
    为用户提供的红包奖励等,通常限额
  3. 无门槛虚拟货币
    无门槛优惠券、积分等,由于这部分基本与货币可以等值,但是由于存在可以追回的机会,所以尚存一些容错)
  4. 有门槛虚拟货币
    因为是为了促销,并不会带来实质经济损失,所以没有那么敏感

分级之后,再进一步划分处理的级别。因为人力和时间都是有限的,很难将所有的安全兜底都控制的那么完美,那就优先保证一些损失影响可能较大的业务上。

权重更高的业务,可以予以更严谨的测试,以及附加的人工审核机制,更频繁的监控等。相对权重较低的,就可能重视程度不那么高,仅保留较低限度的兜底。

安全第一步,防刷

最常见的短信验证码服务,由于是注册用,所以无需登录就能调用。若发短信接口无任何保护措施,直接调用三方短信通道,很容易被短信轰炸平台滥用。

那么,如何防刷?

验证额外参数信息

验证客户端请求头的一些额外参数,比如是否存在浏览器或手机型号、设备分辨率请求头。因为像那些爬虫,一般就只能接收到URL。

先过注册页

无论何种客户端注册,一定要先进入注册页,才能看到验证码按钮。
所以可以在页面打开时请求固定的前置接口,为这个设备开启允许发送验证码的窗口,之后的请求发送验证码才算合法请求。

这可以拦截绕过固定流程,直接通过接口调用验证码的请求。

控制同一手机号的发送次数、间隔

除非是没收到短信,否则用户不太会请求了验证码后不点击注册,还重新请求。
所以,可以限制同一手机号每天的最大请求次数。还要控制好发送的时间间隔,常见的至少间隔1min。

增加前置操作。

短信轰炸平台会收集很多免费短信接口,而且一个接口它们也只会给一个用户发一次短信,不会触发上一条规则。
对于这种情况,可以将图形验证码作为前置条件。技术🐂🍺的还可使用滑块、验证码文字点击、人机检测。

限量

对优惠券这种虚拟资产,平台方必须确保其使用界限。

对于商家,可能只是收到一个用户支付的订单,并不知道用户使用了平台的优惠券。
大部分平台和商家都是事后对账结算,所以下单了就会马上安排发货,事后造成大量资金损失。大量跟风网络主播被薅羊毛的店铺就是这么没的。

优惠券应该需要提前申请:用于何种活动、谁申请的。

幂等

考虑如下:

  1. 幂等依据
    每次交互生成的token、客户端的序列号、有意义的业务订单号等
  2. 根据幂等依据进行幂等处理:
  • 限制:比如锁、状态机控制
  • 去重

先有订单,再操作资金。任何资金操作都要在平台侧生成业务属性订单,可以是优惠券发放订单,可以是返现订单,也可以是借款订单。

订单的产生必须要有业务属性:
比如,返现发放订单必须关联到原先的商品订单、借款订单必须关联到那个借款合同。

幂等处理必须是全链路的,从开始到最后都贯穿使用相同业务订单号,才能实现最终的支付幂等。

支付操作一般是调用三方支付接口。这些接口都会有商户订单号,相同商户订单号不会重复处理,所以三方公司的接口可实现唯一订单号的幂等。

防刷、幂等其实都是事前手段,若系统正在被攻击或利用,如何发现问题呢?

监控是较好的手段,难点是报警阈值的设置,可以对比昨天同时,上周同时的量,发现差异达到百分比阈值就报警。此外,对于活动可以申请单独的活动监控标签,单独呈现曲线,做好量的预估,超量报警,有的时候大盘很大的话活动给整个大盘带来的变化不明显。
可通过监控实现类似熔断机制,比如数据监控某个功能在被刷,触发报警,同时熔断,暂时把该功能禁掉,减少损失。

任何第三方资源的使用一般都会定期对账,若对账发现:

我方系统记录的调用量 < 对方系统记录的使用量

一般因为啥呢?

  • 可能是在一个事务内调用外部接口,调用超时后事务回滚,导致本地就没有保存数据
  • 我方系统对于第三方调用返回值处理不当,导致有重复调用,即幂等没做好

推荐所有第三方服务的交互,将request和response完整记录到数据库。

以上是关于互联网大厂的支付系统的安全性应该是如何设计的?的主要内容,如果未能解决你的问题,请参考以下文章

互联网电商大厂库存系统设计案例讲解

财务对账系统设计

Java基础学习总结(180)——如何保证API接口安全

Java基础学习总结(180)——如何保证API接口安全

瑞升蓉,不止于支付 工业级可靠性设计 金融级安全性保障

如何做一个对账系统