![]()
背景
去年团队招聘需求比较大，本人参与了近百次的面试工作。今天来跟大家聊聊，面试候选人过程中，一个常见的开放类设计题目的解题思路，以及候选人的理解设计误区分析。
![]()
话不多说，咱们直接奔主题。
问题其实很简单，是一个手机绑定验证的场景。大概描述就是：
用户手机验证场景下，正常会给用户手机号码发验证短信，用户收到验证短信后填写验证码进行提交，完成验证。
第一个问题
正常短信发送逻辑没有问题，但由于短信资源宝贵，防止被恶意攻击，你有什么好的控制策略呢？
在面试交流过程中，收集到的答案无外乎这样几种，收集整理归类如下：
1. 发送时间间隔
设置同一个号码重复发送的时间间隔（前端置灰，后端设置间隔锁），一般设置为60-120秒。该手段可以在一定程度上防止短信接口被恶意攻击，且对用户体验没有什么伤害。但是不能防止更换手机号方式进行攻击，防护等级较低。
2. 获取次数限制
是指限制某个手机号在某个时间段内获取短信验证码次数的上限值。
采用这种策略时在产品设计过程中，有几点需要注意：
1）上限值的定义。需要根据业务真实的情况，甚至需要考虑到将来业务的发展定一个合适的上限值，避免因用户无法收到短信验证码而带来的投诉。
2）锁定时间段的定义。需要根据业务情况进行定义，可以是6小时，可以是12小时、24小时。
3. IP限制
设置单个IP地址某个时间段内最大的发送量。
该手段可很好的预防单一IP地址的攻击，但是也有很明显的缺点：
1）对于经常变更IP地址进行攻击的攻击者，该手段几乎没有很好的效果。
2）IP的限制经常会造成误伤。如在一些使用统一无线网的场所，很多用户连接着同一个无线网，这个IP地址就容易很快达到上限，从而造成连接该无线网的用户都无法正常的收到验证码。
4. 图形验证码
在发送短信验证码之前，必须通过通过图形验证码的校验。
这种手段相对来说可以防止某些攻击，因此也是目前非常普遍的短信防攻击机制。但是在使用过程中涉及到用户体验问题，不能简单粗暴地套用这一策略。
以下两个点值得仔细考虑：
1）是不是每次获取短信验证码之前都需要用户输入图形验证码，一般来说这样做会极大地影响用户体验，虽然是相对安全，但是用户用着不爽了。
2）可以给一个安全范围。
结合手机号限制、IP限制来考虑，比如同一个手机号当天第3次获取短信验证码的时候，出现图形验证码；比如同一个IP地址当天获取验证码次数超过100次后，出现图形验证码。
5. 加解密控制
通过对传向服务器各项参数进行加密，到了服务器再进行解密，同时用token作为唯一性识别验证，在后端对token进行验证，验证通过才能正常将短信发送。该手段可以在保证用户体验的情况下，可以有效防止某些攻击，因此也是目前比较常见的短信防攻击机制。
同时也有很明显的缺点：
1）使用的加解密算法可能会被识别，需要考虑使用识别难度较大的加解密算法。
2）在算法不被识别的情况下可以有效防止报文攻击，但是无法防止浏览器模拟机式攻击。
第二个问题
假如需要对用户请求发短信接口进行限制，具体策略针对同一用户手机号发送短信验证码，10分钟之内请求超3次则需要图形验证码（即先验证图形验证码通过后再发送短信），你会如何设计并实现呢？
好多同学听完题目后，就会就能很快给出一个解题思路，大概描述如下：
![]()
实现思路：利用Redis KV存储方式，用手机号作为Key，Value记录短信成功发送次数，同时设置过期时间10min。
假设发送时间如下所示：
![]()
到10.07时候申请发送，判断value的值已为3，发送失败，需要出现图形验证码进行补充验证。
上面的逻辑看似没有问题，其实它将时间自然切片处理了。
![]()
1）按照上面的逻辑，在10.00-10.10这个时间段周期内：10.01、10.07、10.08 分别发送三次短信，是OK的。
2）接着在10.10-10.20这个时间段周期内：10.11、10.13、10.15 也是可以成功发送短信的。
这样就出现了问题：
在10.07、10.08、10.11、10.13、10.15 这十分钟时间里，竟然发送了5条短信！
这样就绕过了发送短信超3次需要图形验证码验证的操作，这显然是不合理的。
其实好多候选人看到10min 和次数限制后，就陷入到了思维定势中去了。
那有什么好的解题思路么？
在此，针对此种问题，提供一种解题思路：
利用Redis List数据格式；Key：send_msg_phone Value：请求时间戳。
直接上实现代码吧：
/** * Redis 单位时间内请求次数限制 * User: 架构精进之路 * Date: 2021/03/11 * Time: 10:23 */
$key = 'send_msg_xxx'; //xxx 指具体手机号$listLen = lLen($key);if($listLen < 3){ // 直接将当前时间戳插入List尾部 Lpush($key, now());} else { $index0Time = Lindex($key); if((当前时间 - $index0Time) < 10min){ // 触发10min内请求大于3次，提醒，“请求过多，请稍后再试。” echo "请求过多，请稍后再试。"; exit; } else { // 将当前时间戳插入List尾部 // 取出List头部首元素 Lpush($key, now()); Ltrim($key, 0, 9); }}
总结
随着目前安全问题造成的影响日趋严重，Web 安全控制对于研发人员来说是一个非常重要的课题。
通过上面的问题，想要了解到大家对安全防控的认知有哪些，有什么好的处理方案，以及对不同方案之间的优劣比较有怎样的认知。
有了好的方案之后，那如何设计实现呢？在具体落地过程中，还有什么需要补充和注意的事项呢？
......
一系列连续的开放性问题走下来，你就能很好的判断候选人在这部分的能力水平了。
![]()
对于此类问题，此文抛砖引玉，相信大家还有其他解题思路，欢迎留言区一起探讨交流~
- END -
作者：架构精进之路，专注软件架构研究，技术学习与个人成长，关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。
往期热文推荐：
![]()
「技术架构精进」专注架构研究，技术分享
Thanks for reading!
