写点什么

我用一个小小的开放设计题,干掉了 40% 的面试候选人

发布于: 2021 年 03 月 11 日
我用一个小小的开放设计题,干掉了40%的面试候选人

背景

去年团队招聘需求比较大,本人参与了近百次的面试工作。今天来跟大家聊聊,面试候选人过程中,一个常见的开放类设计题目的解题思路,以及候选人的理解设计误区分析。


话不多说,咱们直接奔主题。

问题其实很简单,是一个手机绑定验证的场景。大概描述就是:

用户手机验证场景下,正常会给用户手机号码发验证短信,用户收到验证短信后填写验证码进行提交,完成验证。

第一个问题

正常短信发送逻辑没有问题,但由于短信资源宝贵,防止被恶意攻击,你有什么好的控制策略呢?


在面试与候选人交流过程中,收集到的答案无外乎这样几种,收集整理归类如下:


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 -


往期热文推荐:



Thanks for reading!


发布于: 2021 年 03 月 11 日阅读数: 49
用户头像

坚持分享接地气儿的架构技术文章! 2018.02.26 加入

同名微信公众号「架构精进之路」,专注软件架构研究,技术学习与职业成长!坚持原创总结、沉淀和分享,希望能带给大家一些引导和启发,感谢各位的支持(关注、点赞、分享)!

评论

发布
暂无评论
我用一个小小的开放设计题,干掉了40%的面试候选人