短信平臺接口安全控制

摘要：從應用層面和運維層面（協議層）同時作安全控制

 

短信平臺提供給公司業務系統的短信下發接口是一個get方式的http協議的url：

http://a.b.com/SmsSend?acc=exampleacc&pwd=kx%ek@704xoek@*&phone=12345678910&content=%E8%BF%99%E6%98

 

這個url暴露了下發短信的系統帳號和密碼。並且，站點配置了二級域名，因此一旦被盜用，很容易出現短信盜刷。安全方面必需要控制一下。

 

我想的是使用信息簽名。url參數去掉pwd，不讓它做爲傳輸用，讓消費端保留在本身的服務器中。而後，增長一個請求時間reqtime，14位的yyyyMMddHHmmss時間戳。而後基於acc、reqtime、phone的值，再加上pwd來進行md5運算做爲通信的簽名（sign參數）。即最終將上面的url改成：

http://a.b.com/SmsSend?acc=exampleacc&reqtime=20180711202552&sign=64558E73E36581D74C6B708BB5E840EF&phone=12345678910&content=%E8%BF%99%E6%98

 

考慮到調用短信接口的業務系統較多，並且一些老的系統也沒有人在維護，因此這個方式只對目前在運營的系統的短信帳號來作改造，同時兼容老系統的調用。

 

今天跟另外一個同事討論。他同時提了個建議。讓運維作IP白名單。由於短信平臺只提供給公司內部的業務系統，因此作個IP白名單就行了，其餘非法IP的請求直接拒之門外。

這樣，我把上面的短信接口（http://a.b.com/SmsSend）提供給運維，他在Nginx作好配置，服務器層面獲得了保障。同時，往後再結合我上面應用層面的安全控制，就比較完美了。