一、背景
公司新產品體驗，發現不少交互、UI、功能設計上的小問題。於是花了點時間隨意挑了幾個功能深入的玩了一下，順手提了BUG。接口層，看了一下接口文檔，簡單測了一下接口，BUG其實還挺嚴重的，后面詳細分析，為了顧及服務器后台大佬（架構師）的面子，費時費力在APP測試短信驗證碼服務器與APP整體處理邏輯，提交BUG如下：
- BUG：
- 解決結果：
哎！TX背景的架構師的解決結果，讓我稍許失望。
二、BUG分析
1、先說結論：重點是可以短時間（1、2分鍾）之內把短信平台的預充值費用全部用完
1). 單手機號碼可發送短信：40條+
2).可多手機號，短時間操作無限制發送短信驗證碼
3).對用戶影響：可做短信炸彈惡意騷擾用戶
4).對公司影響：短時間耗盡充值平台費用，導致注冊、登錄功能不可用；大量垃圾短信影響公司形象
2、第一個問題：單號碼沒有限制條數
a、06.12號當天實測，可以30來條，每15條換了一個通知號碼而已
b、06.14號當天實測，確實超過15條是提示超出頻率限制。（內心OS：我有當時短信截圖，並有12號的其中部分日志在手，日志在手...）
測試想要不背鍋，哥就大發慈悲教一條：不管大小BUG均記錄在案，嚴重問題盡可能全的保留界面截圖、日志文件等直接證據。
補充：一般第三方短信平台已有限制每個號碼每天發送頻率與條數：一般10條左右/天，1分鍾內不超過2條
3、第二個問題：同設備、同IP、多號碼請求無限制
a、文檔設計，我們直接看業務層接口設計就能發現致命的缺陷！
- 接口文檔
- 模擬請求
b、設計缺陷簡單分析
1)、此接口為直接請求，基本沒有其它前置接口處理（除了接入層路由）。
協議說明：APP請求走socket協議到接入層，再由其將請求內容改成http轉發給業務層 --本次不討論這個
缺陷1：無請求來源識別
缺陷2：同設備、同IP惡意請求，無法做限制 --此處原以為接入層有做，但我今天實測了一下未發現
缺陷3：無數據篡的改校驗
缺陷4：單號碼有加發送頻率限制(剛加)，同設備更換號碼發送頻率無限制
缺陷5：單號碼有加15條/天的限制(剛加)，同設備多號碼(不停更換號碼)短信發送可無限制
以上接口沒有對外暴路，相對安全一點。但安全隱患是存在的，后面會講實操如何實際測試，對是測試！
4、第三個問題：短信炸彈
之前沒有單號碼的條數限制、發送頻率的限制，
現在有了，就不能任性發，此問題作廢，但稍稍解釋一下。
- 無條數限制：一天發個幾十條給你，一個網站幾十條，多幾個網站你就跪了，有沒有經歷過某寶賣家的騷擾？
- 無發送頻率的限制：一分鍾2條，如果沒有限制，段時間就可以給你來個幾十上百條，手機響個不停，15條一個號碼，黑名單你都拉不過來
5、第四個問題：浪費錢，影響形象
短信驗證碼是為了用戶快速登錄，沒有達到預期，都是浪費錢！故從這個角度說，沒有安全措施，就是浪費錢！還不停給用戶不需要的垃圾短信！
6、第五個衍生的問題：驗證碼與登錄邏輯的安全缺陷
- 登錄接口的Bug：
在測登錄接口時試了，輸錯試過250次短信驗證碼（數字是巧合，嗯！），最后一次正確，依舊可以登錄成功！what？怎么有這么牛X的操作？？？
- 驗證碼是4位數：
單看4位數驗證碼，沒有一點問題對吧？
手機在用戶手里，你也收不到，幾位還是不一樣？NO！！！
首先，4位驗證碼有10^4=10000種可能，驗證碼3分鍾內有效。
其次，登錄無錯誤次數限制
就問一句：你能不能在180秒破解登錄，就1W種可能！
答案：so eazy!
三、如何浪費公司的錢
其他扯淡的吹噓的玩意都不說，實操怎么浪費公司錢（短信費用）！！！（啊！~~老板聽我解釋，不是你想的那樣！）
假設我非公司員工，不了解協議與邏輯，有什么辦法呢，多的是，先提兩種：
- 第一種方式（笨方法）：
第一步：隨機生成10W+手機號碼
第二步：裝Android虛擬機，安裝產品APP
第三步：adb模擬（android自動化工具appnium什么的也行）
1)、app啟動 : adb shell am start -n com.xxx.xxx/.xxx
2)、輸入手機號: adb shell input text 15900000000 --手機號可以從文件中讀取
3)、點擊發送驗證碼：adb shell input tap 100 300 --發送驗證碼按鈕位置是固定的
4)、Kill APP(可繞過60秒倒計時) ：adb shell am force-stop com.xxx.xxx
第四步：循環以上三個步驟
說明：
1、可以寫成bat，mac可以寫成sh
2、吃飽了，試了一下，一個虛擬機大約5秒左右一條短信，可以啟多個虛擬機一起跑，達到1秒1條
3、多個虛擬機使用以下命令: "adb -s 虛擬機 shell 命令"
4、以上adb還是有些慢，最好的方法是用monkeyrunner寫(python語言)
5、這兩次測試浪費了公司不少錢，少說也有10RMB++大大額巨款
- 第二種方式（抓包模擬）：
第一步：隨機生成10W+手機號碼
第二步：Android手機(或虛擬機)安裝產品APP
第三步：抓包模擬
1)、Android手機連接電腦共享wifi
2)、開啟抓包工具，比如wireshark
3)、輸入手機號,點擊發送驗證碼
4)、重得以上步驟多次，找到規律破解
5)、python腳本或其他工具模擬請求
說明：
1、此方法成功率靠運氣，不少APP都是有加密等各種措施防止中間人攻擊
2、此方法需要一定實力，有代碼或其它功底，第一種方式，完全不有壓力
3、如里是不小心得到了接口協議文檔的，直接跑接口，完美！！！
四、感觸
想了很多，有很多想說，
寫到這時突然發現，准備寫的感觸稍稍過於偏激，
好久不曾熱血與沖動。
深呼吸...1分鍾....................................................................................
還是來點雞湯！
安全無小事，認真對待你發現的每一個BUG，也許錯過它，就是公司破產的第一步！
BUG不分大小均記錄，有利於經驗的整理、線上回題回溯、背鍋時的有理有據反駁！
努力提升知識廣度，開拓眼界，增加思維的深度！
祝各位端午節快樂！