纪录一次面对ddos盗刷微信企业支付的经历

这次的文章属于对于之前在工作中发生的一次ddos攻击应对分析和应对经验.很有意思.虽然可能对于大多数的读者和我本人来说这样的事件可能不会在一次发生.但是有一句话说的很好(ps这一句话是我经常看的一个公众号架构师之路里面写的,给大佬的公众号打一个广告).

思路比结论重要，有收获就是好的。

事件

这次是我们公司开发的一个微信公众号,里面有一个答题抢红包的模块.需要用户答题成功后,领取红包,按照设定的代码是根据设置,每天最多拿一个.但是某一天,商务那边拿了微信企业钱包的纪录过来说被别人盗刷了,在短时间内同一个用户密集的领取红包.

然后开始查询日志,确实在凌晨,有用户使用同一个ip密集的访问领取红包的接口,并顺利躲过每日领取一个的检查.

分析

如果当时ddos的攻击的话,可以购买对应的云服务进行防御.但是代码里面肯定还是存在问题.

我个人还怀疑,这些黑客,只是顺手进行尝试盗刷.当然这些也只是猜测

并不准备放上原始的代码.只是大体描述一下代码的逻辑

• 首先是数据库.这里有一张领取记录表,大概是字段是用户id,领取金额,领取时间

然后发放红包代码逻辑的伪代码是这样的

$count = $this->countpackactive( ['member_id' => $memberid, '@date_format(createtime,"%Y-%m-%d")'=>date('Y-m-d')]);//获取当前用户当日获取的次数
 if($packactiveinfo['pack_membernum'] - $count == 0){
         $this->dataerror('今日答题次数已用完！');
 }

 ...
 ...

 //调用企业支付接口.
 $this->addquestionmember_datetime (['quest_tradenumber'=>$tradenumber,'status'=>1]);//insert领取表,增加当前用户的当日的领取次数

...

上面的代码的思路还是蛮清晰的.但是在并发测试下就出现了盗刷的问题.原本的检查完全失败.那么问题出在哪里?我们在简化上面的代码

$count = $db->count('question_member',$where);
if ($count ....)
.....
$db->insert('question_member',$set);
.....

我们看到这么一个逻辑先检查question_member表,在插入question_member.用一定的数据库经验的朋友可以看出来来这里出现了资源的占用的问题.在之一次访问question_member插入完成之前,第二个接口访问到来,要求检查当前question_member的情况.这里有点类似事务处理里面的幻读.

资源的占用与并发访问的一致性

这里其实并不像夸夸奇谈,我先说的是这一类的问题其实在计算机的各个层面的都是通用的,不仅仅是数据库中,在操作系统中也见到过注入资源的强占问题,在 *** 层中出现的一致性问题.而这些问题的解决思路往往很详尽.

而在这里的方案是增加一个锁,在增加当前用户日领取记录时候使用锁,而在读取时候必须等待之前的记录插入完毕才能读取.

上面的是之一套方案,当然很快被领导否定了.技术主管提出现在的行业中不流行使用锁(我对于这一点抱有疑问)

然后提出第二套方案,使用redis进行每天的日访问记录进行检查.大概的逻辑是这样的

$count = $redis->get( 'question_member:' . $time . ':' $memberid );//获取当前的访问数目
if($packactiveinfo['pack_membernum'] - $count == 0){
        $this->dataerror('今日答题次数已用完！');
...
...
$redis->set('question_member:' . $time . ':' $memberid, $count+1);
发放红包,如果失败回滚;

这里的使用逻辑是通过redis原子访问特性(redis是原子化,必须等一个访问结束后才有第二个发文),速度快的特性避免了高并发下出现的资源占用问题.
其实这里还是会出现资源的占用,只不过因为redis的响应特别快,从而不会轻易出现,在一次插入结束前,继续访问接口.(平心而论还是有地雷的).但是配合ddos防御还是效果很好.

经验

在这次的事件后我进行了总结

• 对于关键性质的代码,尤其是涉及到金钱的代码要慎之又慎
• 在测试,可以借助ab之类的工具,检查这一类关键接口是否会在高并发访问下出现问题