用蜜罐参数抵御搞事儿的——前奏识别与多参数一致性校验

在写这个标题的时候,我首先想到的是统计学上的“一致性检验”。在这里我没有使用“检验”(test)这个词,而使用“校验”(check)。这两个词虽然大体同义,不过仍然各有侧重,检验更倾向于对判断某个事物是否达到了参照标准,而校验则是希望通过观察找出一些特殊的情况。

在有时候的对抗中,我们会发现攻击者能够很精确的掌握到防守方作出的相关调整,并及时修正自己的策略。这对我们来说十分尴尬,因为一条策略的应用,往往需要经过现象抽象、规则编码(实现)、部署测试、正式上线等等好几个阶段。这个过程往往会消耗一部分时间,而在新规则尚未发生作用之前,我们对目标系统的保护能力实质是不自信或无法掌握详情的。

为了防止工资、奖金和福利被这些家伙搞走,我们开始考虑使用其他的方案来提升“被发现”的难度——于是想到了蜜罐参数。

我们这里定义蜜罐参数为:显式可见或易得知的、存在表面意义和合理性的、但不进入业务逻辑运算过程中的参数。比如,某订单支付的表单,提交的信息如下:

item_id=10086&address=xxxxx&mobile=13800138000&amount=100.00&bank_id=10

有些不安好心或者别用用心的小朋友就会关注“amount”这个参数,弄不好会去尝试修改它为0.01或是其他一些数字。一般情况下,业务在实现逻辑的时候应当从DB中取得订单信息,在服务器侧计算得出最终需要的支付金额,签名后提交给银行支付网关。所以,amount这个参数要么变的没有任何意义,如果有意义再加上没有签名的话,就当然存在一个明显的支付漏洞。

然鹅,事实上,我们在处理支付逻辑的时候,对amount是关心的,它是一个我们刻意留在这里的“蜜罐参数”。

amount的真实作用是“用于检测改动”和“意图识别”。

如果服务器发现amount计算出来的结果与自己从DB中计算出来的结果不符合,则立即向风控系统或用户标签系统中的用户标记为“有问题”,同时拒绝这个修改。

在用户侧理解起来可能就是:啊,贵司的这个地方没有漏洞。然后,继续试验下一个功能点。但殊不知,其后续行为已经被打上“不靠谱”的标签,往往在领取优惠券或参与活动的时候就提示“呀,手一滑没领到~”“很遗憾手气不佳,明天再试试吧”。

当然了,有人可能会说这个过程可能会封杀正常用户:用户因为某种合法的原因(通常是客服人工处理)产生了订单数据可能和浏览器上已经打开的页面不一致的情况。这种场景出现时通常需要基于“我方主动触发”某一机制的前提条件,当我们把这一条件真实发生了的情况同步给风控,可以完成对这个正常用户的洗白。

以上是一个特定的简化版场景描述,实际中我们用到的方案不是那么直白,其中会有些有趣的花花肠子,这里不方便一一展开。

总结一下,所谓的“蜜罐参数”其实是基于一个假设:任何人都无法闭着眼睛从一堆蜡笔中完全选出某一特定颜色的蜡笔而不出错。换句话讲,绕过一个地雷简单,穿过一片雷区则尤为困难。通过大量放置一些实质一直或表意一致的参数在整个业务过程中,并对这些参数的异常变动做好识别和监控,往往可以发现到许多有趣的现象。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*