剖析App漏洞，實現Python無限轟炸目標手機

在日常生活中，由於越來越多的平台在註冊會員，找回密碼，以及手機支付的時候，為了防止他人冒用，惡意盜號，資金的安全往往都會使用簡訊驗證碼來驗證，從而提升帳號的安全性，資金的安全。

但是，每樣東西都有他的兩面性，簡訊驗證碼在提升安全性的同時，往往也會帶來一些不可避免的麻煩。比如簡訊的一個轟炸。

1.簡訊轟炸的形成

第一種情況:（私信小編007獲取各類Python學習資源）

來看一下這張圖，當客戶端發送了一個getpost請求給伺服器的時候，伺服器在接收到該數據包後，像某簡訊介面平台發送一串字元串getpost請求，某簡訊平台介面在接收到該請求之後，返回某數值（通常值為4-6位數字）給伺服器，方便伺服器在客戶端輸入驗證碼之後做驗證。同時簡訊介面向手機發送我們所看見的驗證碼。此時，手機輸入驗證碼給伺服器進行驗證。

在這裡，通常在客戶端對伺服器發送請求的時候，有些程序猿未對請求的次數做驗證，或者是僅僅在本地客戶端進行了一個時間的限制（比如時間相隔60秒），在這樣的情況下，本地可以進行一個加速器對該APP的倒計時進行加速倒計，從而在短時間內多次的快速發包，形成第一種類型的簡訊轟炸。也可以進行對APP的數據包抓包之後，進行在web瀏覽器裡面進行多次的快速的重放，形成第二種簡訊轟炸。

來看一個廠商的案例：

POST數據包

首先是來分析一下這個POST數據包

在這裡我們可以看到一些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=支付校驗）

這裡我在短時間內進行多次快速的發送數據包之後，我的手機就接收到了不少同樣的信息。

第二種情況

來看一下這張圖，首先是客戶端進行getpost請求，但是這回他之前利用內置的介面，直接發送給了某平台的簡訊介面，在某平台的簡訊介面收到該請求之後，同時把所發送出去的驗證碼發給了伺服器的某介面（這裡我們忽略一下客戶端在發送驗證碼時對伺服器的請求），這樣伺服器接收到了待驗證的字元串，同時，手機也接收到了該字元串。在這裡我們可以看到，由於省去了對伺服器的請求，所以程序猿可能也就忘了對次數進行一個限制，或者說僅僅是在本地進行一個限制，同樣的我們可以截取該數據包，在瀏覽器裡面可以進行快速的多次的進行該請求，從而導致簡訊轟炸。

來看一個案例：

Get數據包

簡單的對該url分析一下，

Sendcode=發送驗證碼命令

Username=手機號

From=類型

通過構造username然後進行簡訊轟炸

來看效果圖

來看第三種情況

這樣的情況有兩種小類型這裡我就不上建議的圖片進行解釋了。

1.同樣的第一種情況的基礎上，本地生成的一個數據包裡面直接含有驗證碼字元串，通過伺服器，在發送到介面。

來看一個數據包：

在post內容裡面可以看到兩個欄位

Mobile=手機號

SmsCodeRand=可愛的驗證碼

同時在這裡我們也能意識到，這串數字是可以篡改的~如果伺服器未對這串數字進行賦值為int的話，為varchar類型的話我們甚至可以發送文字呢~

同樣的快速的多次發送數據包之後，我心愛的小手機，在此受到了摧殘。

2.第二種類型的情況

在最後可以看到發送的mobile欄位

發送出去之後，我們可愛的伺服器給我返回了一段雖然我看不懂但是我能解密的字元串

然後依舊這樣，我的心愛的小手機~就被再次的無情的轟炸了一波。

我就不上圖了。

但是同樣的，我們該去怎麼利用呢

這裡有段Python代碼（單線程）

這樣的話，我把手裡的這些介面集合一下，也製造出了我自己的小型簡訊轟炸機了

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！