短信平台接口安全控制

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

 

短信平台作为一个底层支撑系统，为公司业务系统的短信需求提供服务。短信服务暴露的发短信接口是一个HTTP-GET请求地址：

http://sms.mycompany.com/send?account=exampleacc&secret=kx%ek@704xoek@*&mobile=12345678910&content=%E8%BF%99%E6%98

 

这个url暴露了下发短信的系统账号标识和密码。而且，站点配置了二级域名，所以一旦被盗用，很容易出现短信盗刷。安全方面必须要控制一下。

 

我的方案是使用数字签名。url参数去掉secret，不让它作为传输用，让业务系统端保留在自己的服务中。然后，增加一个请求时间reqtime，14位的yyyyMMddHHmmss时间戳。然后基于account、reqtime、mobile的值，再加上secret来进行md5运算作为通讯的签名（sign参数）。即最终将上面的url改为：

http://sms.mycompany.com/send?account=exampleacc&reqtime=20180711202552&sign=64558E73E36581D74C6B708BB5E840EF&mobile=12345678910&content=%E8%BF%99%E6%98

 

考虑到公司里调用短信接口的业务系统较多，而且一些老的系统也没有人在维护，所以这个方式只对目前在运营的系统的短信账号来做改造，同时兼容老系统的调用。

 

今天跟另一个同事讨论。他同时提了个建议。鉴于短信平台只服务于公司内部的业务系统，所以让运维在服务器上做IP白名单即可，非法IP的请求会直接被拒之门外。

这样，我把上面的短信接口（http://sms.mycompany.com/send）提供给运维，他在Nginx做好配置，服务器层面得到了保障。同时，日后再结合我上面应用层面的安全控制，就比较完美了。