Java 业务开发常见错误 100 例
朱晔
贝壳金服资深架构师
51940 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 48 讲
代码篇 (23讲)
Java 业务开发常见错误 100 例
15
15
1.0x
00:00/00:00
登录|注册

28 | 安全兜底:涉及钱时,必须考虑防刷、限量和防重

你好,我是朱晔。今天,我要和你分享的主题是,任何涉及钱的代码必须要考虑防刷、限量和防重,要做好安全兜底。
涉及钱的代码,主要有以下三类。
第一,代码本身涉及有偿使用的三方服务。如果因为代码本身缺少授权、用量控制而被利用导致大量调用,势必会消耗大量的钱,给公司造成损失。有些三方服务可能采用后付款方式的结算,出现问题后如果没及时发现,下个月结算时就会收到一笔数额巨大的账单。
第二,代码涉及虚拟资产的发放,比如积分、优惠券等。虽然说虚拟资产不直接对应货币,但一般可以在平台兑换具有真实价值的资产。比如,优惠券可以在下单时使用,积分可以兑换积分商城的商品。所以从某种意义上说,虚拟资产就是具有一定价值的钱,但因为不直接涉及钱和外部资金通道,所以容易产生随意性发放而导致漏洞。
第三,代码涉及真实钱的进出。比如,对用户扣款,如果出现非正常的多次重复扣款,小则用户投诉、用户流失,大则被相关管理机构要求停业整改,影响业务。又比如,给用户发放返现的付款功能,如果出现漏洞造成重复付款,涉及 B 端的可能还好,但涉及 C 端用户的重复付款可能永远无法追回。
前段时间拼多多一夜之间被刷了大量 100 元无门槛优惠券的事情,就是限量和防刷出了问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Java 业务开发常见错误 100 例》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 那时刻
    1.对于防重,防刷。可以通过数据监控来实现类似熔断机制,比如数据监控某个功能在被刷,触发报警,同时熔断,暂时把该功能禁掉,减少损失。 2.想到一种情况,我们系统对于第三方调用返回值处理不当,导致有重复调用,也就是我们系统防重没有做好。

    作者回复: 问题二,之前遇到的情况是,在事务内调用外部接口,调用超时后事务回滚本地就没有留下数据,对账的时候要对两边,不管哪方数据缺失都可能是因为有bug需要重视

    4
    23
  • 👽
    安全兜底 的问题,我的理解是分级别。 我的初步分级是 1,无限额涉及钱的问题(类似于退款),2,限额设计钱的问题(为用户提供的红包奖励等,这部分钱通常有限额) 3,无门槛虚拟货币(无门槛优惠券,无门槛积分等,因为这部分基本与货币可以等值,但是由于存在可以追回的机会,所以尚存一些容错) 4,有门槛虚拟货币(这部分,基本上,因为其目的就是促销,并不会带来实质上的经济损失,所以就并没有那么敏感了) 分级之后,再进一步划分处理的级别。因为人力和时间都是有限的,很难将所有的安全兜底都控制的那么完美,那就优先保证一些损失影响可能较大的业务上。 权重更高的业务,可以予以更严谨的测试,以及附加的人工审核机制,更频繁的监控等。相对权重较低的,就可能重视程度不那么高,仅保留较低限度的兜底。

    作者回复: 分析的不错

    2
    18
  • 👽
    对于,我方调用记录和对方调用记录不符,个人认知,假设,对方系统记录是正确的。 我猜测的点:我调用对方,对方存了,我没存。或者请求重发了,但是我方仅保存了一次。 首先需要通过日志来看。调用前日志,调用后结果日志,以及重发日志。综合来看自己请求是否存在问题。 甚至,中间部分时候,己方的服务器挂掉了,也会形成记录不一致的问题。 个人思路,以日志为切入点解决问题。

    作者回复: 所有涉及到三方服务的交互,我建议request和response全部记录到(NOSQL)数据库中

    2
    12
  • 2019
    调用第三方服务进行支付金币,我们的做法是不管支付成不成功都把数据放入本方数据库,只不过增加一个状态字段来判断是否支付成功。如果支付成功一定是接口三方返回成功,如果失败有可能三方服务有问题或者网络问题。支付失败的情况,给用户友好提示,让用户再次支付,由于三方支付是幂等的,用上次调用的业务号直接支付,支付成功就修改状态。这样两方进行对账不会产生重复入账的情况。

    作者回复: 没错,先落地,再调三方

    10
  • 大胖子呀、
    最近正好要做小程序发放红包的功能,学习了,后面实施的时候一定要注意。 第一次回答下问题,经验不足,有错误之处还请指出。 问题一:如果系统正在被攻击的话,应该会出现几种异常情况,比如短时间内会有大量资金流出(涉及金额实时扣除的)、同一个用户短时间内有大量的数据重复,等等。系统可以根据具体业务情况,针对可能出现的异常情况进行监控,如果出现的话及时预警。 问题二:可能是因为调用第三方接口成功了,但是存入自己系统数据库出现错误,没有及时发现处理,造成了数据丢失,有可能就会导致这种情况。

    作者回复: 问题一,的确监控是较好的手段,关键在于报警阈值怎么设置,我觉得可以对比昨天同时,上周同时的量,发现差异达到一定百分比报警。此外,对于活动可以申请单独的活动监控标签,单独呈现曲线,做好量的预估,超量报警,有的时候大盘很大的话活动给整个大盘带来的变化不明显。

    5
  • 郑思雨
    说到安全手段,最先想到的是校验+对账。 校验要注意的一点是 对业务case的穷举,在业务流程比较复杂的情况,需要多考虑边界情况,比如两条指令共同决定一个行为,那么两条指令的先后顺序、两条指令同时到达的校验有很大的差异。 而对账更多的是及时发现问题,及时止损。公司内部可以做准实时对账,与外部平台有对接时,只能做成T+1的,实时性差,发现问题也就更晚。 举2个例子: 用户提现时需要传递 token 和 账户ID,这时我们就可以做一个 token 和 账户ID关系的校验,看看token对应的User 和 账户ID 是否能对应上,防止攻击者用一个token 提现多个账户的余额。毕竟获取多个token比获取多个账户ID要困难很多。(这个例子是一个用户可以有多个账户的设计) 账户出金的安全性:可以通过设计来规避问题,比如 设计 冻结、解冻 等功能。

    作者回复: 安全方面设计上的确可以考虑很多:双向对账、多步流程整体考虑安全校验、兜底策略、防止外部猜测业务逻辑、不但在内部校验通过外部再实现一套业务逻辑实现校验、设定业务策略常识作为底线

    2
  • 睁眼看世界
    老师,请教下,全链路幂等处理的话,如果是web请求,除了前端防抖的话,后端可以如何处理?

    作者回复: 其实幂等考虑2方面: 1、幂等依据,可以是每次交互生成的token,可以是客户端的序列号,可以是有意义的业务订单号 2、根据幂等依据进行防重处理: 1)限制:比如锁方式、状态机控制 2)去重方式

    1
  • 玩帆船的东郭君
    课程买了挺久,今天才看。说到限量、防重复,以我之前在国内某top金融公司5年开发经验谈,实际的金融风控规则,更加细腻。限量:我的账户里面只有100块钱,那么客户的贷款金额或者取数金额就不能高于这个钱。系统的利息计算批处理,产生的利息不能大于本金,财务系统每支出的一笔钱需要与业务系统的业务数据,对应上等 防重复:有些财务系统,对中间件的可信度还是持有怀疑,最终还是采用数据库一笔交易,唯一 一笔流水号进行定义。
    归属地:江苏
    1
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部