接口”安全机制”的设计

Posted 我是谁的谁

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了接口”安全机制”的设计相关的知识,希望对你有一定的参考价值。

1、https:https SSL证书安装的搭配(搭配https ssl本地测试环境)

2、接口参数加密+时效性验证+私钥 :实现方式参考

现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:
1. 用户用密码登录成功后,服务器返回token给客户端;
2. 客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;
3. 服务器检查token的有效性,有效则返回数据,若无效,分两种情况:
• token错误,这时需要用户重新登录,获取正确的token
• token过期,这时客户端需要再发起一次认证请求,获取新的token
然而,此种验证方式存在一个安全性问题:当登录接口被劫持时,黑客就获取到了用户密码和token,后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。
如何优化呢?第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议,自动对数据进行了压缩加密,在一定程序可以防止监听、防止劫持、防止重发,安全性可以提高很多。不过,SSL也不是绝对安全的,也存在被劫持的可能。另外,服务器对HTTPS的配置相对有点复杂,还需要到CA申请证书,而且一般还是收费的。而且,HTTPS效率也比较低。一般,只有安全要求比较高的系统才会采用HTTPS,比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。
我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥,每次请求接口时,将密钥和所有参数组合成源串,根据签名算法生成签名值,发送请求时将签名一起发送给服务器验证。这样,黑客不知道密钥,不知道签名算法,就算拦截到登录接口,后续请求也无法成功操作。不过,因为签名算法比较麻烦,而且容易出错,只适合对内的接口。如果你们的接口属于开放的API,则不太适合这种签名认证的方式了,建议还是使用OAuth2.0的认证机制。
我们也给每个端分配一个appKey,比如androidios、微信三端,每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错,传错了appKey的请求也将报错。这样,安全性方面又加多了一层防御,同时也方便对不同端做一些不同的处理策略。
另外,现在越来越多App取消了密码登录,而采用手机号+短信验证码的登录方式,我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处:
4. 不需要注册,不需要修改密码,也不需要因为忘记密码而重置密码的操作了;
5. 用户不再需要记住密码了,也不怕密码泄露的问题了;
6. 相对于密码登录其安全性明显提高了。

参考文档

以上是关于接口”安全机制”的设计的主要内容,如果未能解决你的问题,请参考以下文章

webapi框架搭建-安全机制

接口的安全机制(中)——基础密码学知识

Kubernetes的安全机制

Kubernetes——安全机制

API安全-常见的安全机制

系统安全——PAM模块