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

前言

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

一丶找到對外短信接口

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

二丶分析外部防御措施

1. 輸入手機(jī)號
   

2. 點(diǎn)擊發(fā)送驗(yàn)證碼
   

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

外部防御措施：無

三丶查看請求報(bào)文

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

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

2. 查看請求方式

3. 查看請求報(bào)文頭

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

5. 查看返回值

四丶分析測試

1. 直接在瀏覽器測試

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

果然可以，那么再試試直接換個(gè)手機(jī)號。

多刷新幾次頁面。

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

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

2. 用代碼進(jìn)行測試

利用Java模擬報(bào)文請求 ，進(jìn)行測試。部分代碼如下：

//配置請求頭
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é)果分析

測試目標(biāo)：

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

測試思路：

1.找到請求接口
2.分析請求報(bào)文
3.模擬請求測試

測試結(jié)果：

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

測試結(jié)論：

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

風(fēng)險(xiǎn)等級： 高

六丶結(jié)語

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

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

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