8

有个短信接口给用户注册时发送验证码的,然后现在发现有人每次用不同ip 不同号码进行恶意调用,现在接口被调爆,如何解决这个问题呢。
补充一下:目前APP已经发布出去了,能不能再服务器做相关的限制呢,因为在接口做限制,它不停的调的话,还是导致了该接口出现卡的现象

徐小说 323
2017-01-10 提问
25 个回答
8

已采纳

大家的答案大部分都有一定作用,可以提升被攻击的难度,可以过滤掉一些低端的攻击。但是实质上在专业的hacker面前都是徒劳。

本质上就是客户端一个请求发给服务器,请求的所有参数都是来自客户端,所有在客户端做防护的措施都是浮云。有1000种方式防,就有1001种方式破。有这个功夫,不如先在服务端检查一下HTTP请求的合法性,举个例子,一个由Firefox浏览器对你APP服务器发起的短信请求User-Agent: Firefox,你要给它发吗?一个请求的Referwww.duanxingongzhaji.com,你应不应该拦截呢?

最经济有效的其实是加验证码,因为攻击者即使是对接打码平台,也是有固定经济成本的。有大把的裸接口跑在外面,短信轰炸机这种工具是不会盯上你的,除非是有人故意要搞你。但加验证码随之而来的就是用户体验的下降。

APP已经发版了,没办法加怎么办? 凉拌呗! 要么强升要么就继续忍受攻击吧

回答对IP和手机号做次数限制的亲们,你们认真审题了吗???

每次用不同ip 不同号码 不同ip 不同号码 不同ip 不同号码

IP可以考虑对代理和机房IP的识别,自己识别成本太高,可以对接第三方的saas服务,但也没有谁能100%识别代理,70%~80%是差不多的。另外有一些攻击行为是众包的,由中了木马的肉鸡发起,机器本身是在正常不过的个人PC,这种方式基本不要想怎么防了。

手机号只能考虑空号检测了,这个也不要试图自己做了,找供应商吧,同样的,没有100%的准确率,并且不是实时的。技术上讲可以有一些帮助,但是产品层面可能不太优雅。

从攻击者攻击方式考虑:

  • 对于短信轰炸机这种无攻击目的性的情况来说,一般手机号都是存在的,并且IP都是分散的正常IP,除了验证码,真的没什么手段可以防。除非你能事先知道这个号码正在被攻击

  • 对于恶意的黑客攻击行为,一般会伴随大量空号和代理IP,一定要防的话,需要一定成本,否则只能认栽。

题目限制比较死,以上,交卷~

4

最常用的方式有几种
1.可以增加图文验证码
2.可以针对手机号做过滤
3.ip限制,单点时间范围可请求时长

2

图片验证码一点用没有,低端一点可以用打码平台,高端直接识别二维码。

建议完善ip验证,抓取用户真实ip而非代理ip地址

遇到这种情况,没办法防,从开发的角度来看,无论对面怎么做,我们都可以刷api

2

图文验证码+参数经过加密生成sign+参数去服务端做校验

2

之前遇到过。前端没办法立即加验证码,而那边却在呼呼的耍短信。
当时的解决办法是:
服务器关掉端关掉对短信验证码的请求。
对向服务器请求短信验证码的接口,服务器直接把返回的errorCode设置为异常代码,可以被前端捕获,然后把验证码写到错误信息中,弹出来。这样用户还是可以看到验证码的。


然后再坐下来加图片验证等等

1

ip与手机绑定的形式不好,正常的用户可能会无法使用
1、限制手机号发送验证码的次数
2、验证码
3、token

1

以下思路仅供参考:

  1. APP发版出去了,别人却能够用脚本来跑接口,第一感觉这是安全性没做好,线上的接口一定要开启https访问。这样别人来抓包的难度也会大很多。

  2. 我个人感觉,发送短信的接口可以不暴露给前端,也就是说无法通过直接调用某个接口来发送短信,可以作为一个后端服务,仅暴露给API来访问。发送短信的逻辑可以写在注册,登陆等的逻辑里面。

  3. 对参数进行一次校验,比如可以将请求参数以某种规则组合成某个唯一的值,服务端拿到参数后以相同的规则组合出来看下是不是和校验值一样,如果一样则继续进行操作,如果不一样报错给客户端,这样别人在调用你的接口的时候还需要破解你的这个校验规则,这个规则越难破解,别人通过接口调用也就越难。

  4. 其他的限制可以参考楼上各位大神的思路。

5

APP被反编译的话其实你说的每一条都没用。。。

码农小兴 · 2017年02月16日

展开评论
1

这个情形我遇到过,我怀疑是专业的公司做的,他们的IP非常多,然后模拟普通用户让你难以预防,封杀的太死会误伤自己的客户.简单的就是请求接口前加大验证的难度.比如我就引入极验和把短信商给换为阿里大鱼(因为阿里做好了限制,比较方便),这两个大大的减少了被爆的几率.

不过,最后烦不胜烦,这种抓了一堆肉鸡来攻击你的接口是很难干过他的,我把手机接口给去了,由于面向的用户基本都是年轻人,索性直接强制绑定微信,利用微信的模板消息来推送了.

1

告诉你们个内幕: 很多是短信提供商给刷的, 创业公司很少有那闲功夫去搞竞争对手!

更别说有集群的服务器切换IP去刷, 那是个地下产业链

另外, 简单的图片验证码, 还是能破解的

1

你瞎说什么大实话,而且这类捞钱思路也是从各种广告联盟那边出来的。。。突然感觉互联网黑产无处不在啊

昌维 · 2017年02月16日

添加评论
1

楼主写的接口是对android和ios的app开放的吗?
如果是这个就比较简单了。
首先攻击方如果是手动刷的话,那就没办法了。但是攻击方这么做的效率也很低,我判定他们一定是通过程序进行攻击的。
下面是针对程序攻击破解的方法:
在客户端中添加一个私钥字符串,服务器端也有相同的私钥字符串。
客户端向服务器端请求短信接口时,客户端将“私钥字符串+手机号码”md5加密生成一个token的字段。然后将token与手机号码发给服务器端。
服务器端在接受到请求后,将存在服务器端的“私钥与手机号码“md5加密,如果相同则发送短信。
这种方式攻击方,就需要破解你们的私钥,这个代价很大。

1
回复 fooklook

你做过破解吗?想法太天真了吧

習習不懂 · 2017年03月09日

展开评论
1

之前我们也遇到过相同的问题,当时的也是不能改前端,后来分析一下请求数据包的共性,因为是用工具批量发的,请求头上有一些特征,我们的接口判断到这些特征后直接返回200,不走后面的业务逻辑。

直接返回200的原因是不想让对方知道我们已经采取了防御措施,避免他们进一步攻击。

1

调用付费接口加上验证码是对公司财务最基本的尊重。

所幸我用的短短信服务商自带防攻击。

0

我原来想的是有同源策略就不会有外域能调用,但是后面发现还是有人能用工具搞定,我司采用的是

  1. 将用户的当前ip+mobile 存入memcachedkey里 ,value 为时间戳大家知道怎么玩,到时候取出来算算

  2. 禁止可能出现的跨域请求

  3. 服务端在页面对前端生成类似CsrfToken的令牌,在提交时与后端验证,一次只能验证1个,成功你需要生成新的令牌给前端,因为要考虑可爱的用户有时等待时间什么的,不然用户体验差

但是看到楼主说的有人能换ip 换号码调用,我想的是这样的话就复杂了,啥样的都能搞出来的赶脚

坐等楼下精彩解答

0

增加发送前验证,必须手动才能生成的那种,比如拖动验证码、拼图验证码;token令牌验证,让每个表单提交只能使用一次

0

额 我猜你是用ajax去发送的验证码吧,一般这种用表单令牌,当然这种对于是真的用脚本来搞你的验证码一样挂掉,最保险的是,去发送手机验证码的时候先验证一次图片验证码过后,再用表达令牌来搞,这样就大大的降低了这种可能性,不过这种呢,用户体验不好,风险总是有的,就看你如何控制了

0

感觉你们都out了……
这个情况我们也遇到过,短信验证码会被别人无限制的重复调用,其实出现这个问题很简单,就是那些 短信轰炸、手机轰炸 软件编写者利用了网站的短信API。
我们的解决方案是,第一次调用没有问题,随后的操作就需要输入验证码,验证码输入成功了,才会去请求,这样能有效的防止api恶意调用;如果连第一条都不想给他发,那就每次发短信之前都先验证一下 验证码【前提是,这个验证码最好是隐藏的,单点击某个按钮或者元素的时候在显示出来】

0

那就要看你们当初有没有设计验证码功能,先输验证码才能调用。。这是最简单的方法

0

使用图片验证码获取短信的验证码应该是比较适合的

0

APP已经发出去了的话,只能先对同一IP和同一手机号的调用做限制吧,在下一个版本再做图形验证码

0

1.每个手机号每天只能调用10次短信接口.
2.每个手机号每分钟只能调用1次.
3.采用token,做好效验.

0

先确认一个事情,刷的是同一个用户,还是刷小号注册。这是两个不同的处理方向,同个用户或者固定一群用户在刷的,这个比较简单,你限用户就行了。若是刷小号注册,这里就涉及攻防战了,可以逆向考虑一下,对方刷小号注册的利益在什么地方,比如对新用户有一些优惠券之类的,那么可以往这方面去做限制,或者提高注册门槛。临时方案可以做一些规则性质的限制(就是攻防战,打游击),但是最终还是要掐住关键点的。临时方案也很多,这种刷接口的,都是会有一定的行为特征的,按照行为特征去针对处理。(治标不治本)

0

关于怎样去避免这种问题楼上说的已经很多了,我就透露一种贵公司的短信接口被滥用的可能场景:短信轰炸机。

现在有一种服务叫短信轰炸机,说白了就是使用这个轰炸机软件的人只需要填写一个手机号码,这个手机号码就会源源不断的收到一大堆垃圾短信,烦不胜烦。但这些短信的内容是什么呢?打开看看只会发现基本上是各种网站、APP 的注册验证短信、密码找回短信、登录验证短信等,尤其以注册验证短信居多。从原理上看其实这个短信轰炸机非常简单,就是大量收集一些网站或 APP 的发送验证码的短信接口,然后利用这些接口去给指定的手机号码发送验证短信,一旦收集的接品多了,就会产生短信源源不断发送到指定手机号码的现象。

这种一般发送验证短信的 IP 就是使用轰炸机软件的人的 IP 地址,所以很难根据 IP 地址去过滤短信。不过相信一点,搞这种恶作剧软件的人一般是懒的破解验证码的(他们要的是接口的数量尽量多),一个小小的验证码很多时候还是很有用的。

0

验证码不能太简单,注意过滤ip,小项目推荐引入第三方验证服务。

0

想到一种方式,仅供参考。

在不可逆向APP源码的前提下

  • APP
    请求短信接口getSms?phone=手机号&sec=加密串&time=时间戳。比如加密用简单的md5,加密串sec=md5(手机号+时间戳+约定秘钥)。
  • 服务器
    收到请求,判断传时间戳time和当前时间戳now_time,约定X秒外不可发送(X=now_time-time),X防止网络延迟和时间差,同样加密方式然后判断和传递sec是否一致,如果一致允许发送。
  • 存在问题
    X秒时间内,用户可以抓包到请求然后刷取验证码,所以,后台再进行限制频率限制,10秒/y秒内不允许重复获取。这样基本可以防止。

wap和pc页面目前用图片验证码大概是最好的解决方案吧。

0

上面的回答都是废话,既然是恶意的,肯定使用的是vps这样就有用不完的ip,我们可以设置一个策略就是单个ip每秒或者每分钟post达到多少,动态封禁,注意是应用层的封,不在网络层也不在传输层.配合redis自动解禁,ngx_dynamic_limit_req_module 此模块就足以满足多种需求千万级pv环境使用,只需要在服务端配置即可https://github.com/limithit/n...

撰写答案

推广链接