短信接口被攻击的那些经历

短信接口被攻击的那些经历

前几天项目的短信接口被人攻击了. 一天内把短信余额全部用完. 这里记录下修复漏洞过程,思路.
查阅了网络上的各种经验,都觉得不错,但是根据自身实际情况出发.不完全采用网络上相同处理方式, 具体思路如下.

---

由于app端旧版已经发布,后台有漏洞的接口不好直接关闭. 因为会影响到旧版本app的正常使用. 所以在不修改UI界面的基础上,维护好后台业务.

• 对所有网页请求增加filter, 对于所有网页接口的请求, 判断其来源,即header中的referer. 如果是直接通过postman等工具发起的请求,referer值将是”“,而如果通过网站上发起这个请求,那么referer值将是xxx.domain.com, 可以用来过滤掉一部分拦截.

• 通过redis的hash结构,记录用户请求发送验证码的记录.

  key	val	说明
  v.sms.mobile	mft:xxx, mts:1,hft:xxxx,hts:1,dft:xxx,dts:1	请求记录: mft:分内首次时间戳, mts:分内次数,hft:小时内首次时间戳,hts:小时内次数,dft:日内首次访问时间,dts:日内次数
  v.sms.ip	mft:xxx, mts:1,hft:xxxx,hts:1,dft:xxx,dts:1	与 v.black.mobile一致
  v.sms.session	mft:xxx, mts:1,hft:xxxx,hts:1,dft:xxx,dts:1	与 v.black.mobile一致
  v.black.mobile	T	是否在黑名单
  v.white.mobile	T	是否在白名单
  v.black.ip	T	是否黑名单IP

• 用户请求时短信时, 按照白名单->黑名单ip -> 黑名单session->黑名单电话->请求记录->设置黑名单 顺序过滤执行. 其中设置黑名单的规则即按照分->时->日顺序判断规定时间内是否有超出请求次数,如果没有超出,就把次数incr(1), 指定时间段(1分,1小时,1日)后,如果仍没有超出次数,就重置开始时间戳.

• 以上方案都是后手策略. 查阅网上资料后, 需要修改页面UI来增加请求难度的先手策略:
  
  • 1. 先输入验证码,然后再跳出获取手机短信验证码的操作.
  • 1. 用极验动态图片验证码
  • 1. 要求必须先输入部分指定表单后,才能点击获取验证码按钮.
  • 1. 请求2-5次获取验证码后,要求先输入图片验证码.
  • 1. 为了防止用户刷新表单直接进入, 发送验证码的倒计时要保存在本地.
• 新app上线后,UI界面更新,调用新接口. 此时需要记录旧接口的成功请求记录, 几个月后撤掉旧接口. (这里只记录成功请求的,因为那些攻击的记录已经慢慢被拦截,记录下来会影响判断)
• 另外: 后端发送验证码前,先检查原验证码是否还有效,如果还有效,就返回同样的验证码,以保证不会因为短信服务商短信发送延迟, 用户多次点击后影响用户体验.

最后是简单的流程