前后端分离场景应用接口安全考虑

接口安全指标分类

类别	是否认证	是否授权	是否防篡改	是否再加密传输	是否防重放	是否防模拟
公共接口	否	否	否	否	否	否
一般安全接口	是	是	是	否	是	否
安全接口	是	是	是	是	是	否
绝对安全接口	是	是	是	是	是	是

注意： 是否再加密传输 是针对ssl 协议上 再加上一层加密策略

指标分析

认证和授权

认证指：该请求接口的用户是否登录
授权指：该请求接口的用户是否有权限访问该接口
一般通过应用的安全框架即可完成，例如 spring-security , shiro 等

防篡改

防篡改是指接口报文是否能防止别人修改个别参数后重新请求（这里主要关注是否能发现报文被修改，重放后面再聊）。
这里我们暂时只考虑防篡改。
普遍大家采取的措施是：请求方生成签名，后端进行验签的方式 检查报文是否被篡改。
签名方式一：对请求参数进行排序，拼接参数和客户私钥，进行md5加签，后台同样的拼接参数和后台保存的私钥进行md5加签比对是否和上送的一致。
签名方式二：客户端 RSA 私钥加签，后台使用客户端公钥验签

签名逻辑，除了防篡改，而且因为签名串中必须包含应用秘钥，所以在一定程度上也可以防模拟。

加密传输

接口的业务数据报文是否整体加密传输，这里的加密是在ssl 协议上自己再定义一层加密。
这里不要使用非对称的加密方式，最好采用对称方式，对称方式的话，要思考秘钥共享保存的问题

防重放

防重返是指被别人截获报文后再次发起请求。 常见的方案 timestamp+ nonce

防模拟

防模拟是指不使用官方提供的前端应用来模拟与后台交互。
模拟请求场景我的理解，不论是官方的前端，还是黑客自己实现的前端，只要我们接口进行了有效了上下文逻辑控制，是不是我们的终端发过来的请求，其实没太大的关系。为什么没太大关系有以下几点：

1. 模拟只能模拟自己的账号，如果登录自己的账号却操作了别人的 数据，这说明业务接口有越权的漏洞
2. 客户端的存在就是 方便用户 人性化的提交业务数据，作为开发我们可能自测的时候根本不需要客户端，客户端的逻辑也不需要关心。

但是允许模拟请求，并不是无底线的。我们还要做一些防止暴力攻击的措施，比如 一秒进行了几十次请求给服务器造成了巨大压力。 这样的我们要在系统安全层面做出控制，比如网关流控。

必须防模拟怎么办

如果就是要防模拟怎么办呢（比如一些安全级别高的应用）
首先我们要理解整个接口交互的对象的最上层抽象：

防模拟就是要确认 ① 的位置是否是我们的应用而不是模拟的终端程序。
每个程序包都是一样的，任何人安装之后都是一样的，如何区分，依赖系统的一些唯一设备信息与程序包进行绑定。
然后 用户再与拥有唯一设备信息的应用程序进行认证，首次认证必须是安全系统高的认证。
常规做法在应用启动时，进行系统信息收集并上报，用户首次登陆 判断系统是否是已认证过的设备，如果是新设备必须添加再次进行认证（认证的手段必须是能直达用户的，比如验证码方式），并通知用户新设备，用户可以进行授信设备管理。
补充： 其实前面提到的签名可以很好的防模拟手段，就是在客户端生成签名的时候必须使用 后台下发的应用秘钥。这样只有有正确秘钥的客户端可以发起有效请求，但是要注意秘钥的保存，要求客户端使用其他手段保存秘钥。不然客户端破解也是很容易就拿到秘钥的。

在各个前端上怎么做（TODO）

IOS APP （TODO）

android APP（TODO）

WEB 浏览器（TODO）