java restfull加密,一种简单的REST API接口加密实现，只允许自己的产品调用后台，防止接口被刷...

在项目上线后，后台接口很容易通过抓包工具看到， 难免被人为构造恶意请求攻击我们的系统，相信大家都或多或少都遇到过短信验证码被刷、疯狂留言灌水、数据被恶意爬取等问题，这种直接抓接口然后写个循环调用的行为门槛极低，本文重点提供一种提高安全门槛的方法供大家参考。

后台接口很容易暴露

1.实现思路:

客户端通过将本地时间戳client_time_sign加密传给后台，后台通过解密后和服务端时间server_time进行对比，在有效时间范围内的话则说明是有效请求

流程图2.改造点:

老接口请求方式: http://www.abc123.com/getUserInfo?id=1

新接口请求方式: http://www.abc123.com/getUserInfo?id=1&client_time_sign=MEejo6tNI0aVlRrcKdOqDZAf

原来老接口抓到URL地址后可以任意调用，新接口URL地址调用过一次后，第二次再调用会提示请求非法，即使抓到了也不能重复发起请求。

2.1.前端控制器

在APP或者WEB应用的接口请求工具类或者拦截器中，拼接上client_time_sign参数，规则是直接对客户端本地时间做AES加密(简单做法，可以修改为非对称RSA加密或者使用更多盐值一起加密)

2.2.后端拦截器

后端收到request请求后，获取client_time_sign，通过服务端对参数AES解密拿到本次请求的客户端时间戳，和服务端时间戳进行对比，server_time - client_time < ${legal_time} ，有效时间可以根据系统自身需要调高或调低，例如设置为10s ，意思就是请求有效时间持续10秒， 在10秒内这个URL可以重复请求。

如果条件不成立，则可以直接返回异常提示给请求方。

注意事项:

这种实现方式有一个地方需要考虑，就是客户端时间可能不一样，本地时间是可以随便被修改的，可能会导致正常请求无法被处理，这种情况下需要补正客户端时间差，做法是在后端接口返回值字段中增加一个服务端系统时间server_time， 客户端计算与服务端时间差值，补齐后再进行加密。

//客户端时间补正方法

var globle = 0; //全局，并在app启动时生成

function getGloble(sys_timestamp){ //入参为后台返回体中的t_

if(globle == 0){

var timestamp = (new Date()).getTime();

globle = sys_timestamp - timestamp

}

return globle ;

}

按照方案改造后， 只有自己的客户端知道规则， 其他不知道校验规则的拿到URL地址也没用， 这样基本能避免90%的滥刷接口行为。