短信平台接口安全控制

摘要：从应用层面和运维层面（协议层）同时作安全控制

 

短信平台提供给公司业务系统的短信下发接口是一个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作好配置，服务器层面获得了保障。同时，往后再结合我上面应用层面的安全控制，就比较完美了。