摘要：从应用层面和运维层面（协议层）同时做安全控制
短信平台提供给公司业务系统的短信下发接口是一个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做好配置，服务器层面得到了保障。同时，日后再结合我上面应用层面的安全控制，就比较完美了。
