Retrofit/Okhttp API接口加固技术实践（上）
作者：Tamic
地址：http://blog.csdn.net/sk719887916/article/details/61914609
写这篇文章，我纠结了非常久，究竟是属于app安全系列，还是属于Retrofit系列，终于我还是选择了将本篇文章归类到Retrofit下。
对于retrofit安全相关的刚開始就写了一篇《Retrofit 2.0 超能实践（一），okHttp完美支持Https传输》（http://blog.csdn.net/sk719887916/article/details/51597816。 文章介绍了怎么使用Retrofit，并且在遇到okhttps的使用方式，但对于加密我们还是无法了解太多。对于安全性要求非常高的接口场景还是无法满足，今天就来介绍下对普通api參数的加密！
APP基本安全的文章曾经撸了一篇App安全（一） Android防止升级过程被劫持和换包。兴许没有再继续跟进，今年会加重安全这块的文章。 主要说下支付宝为代表的用的安全策略技术。本篇介绍下API加固的经常使用技术。经常使用的模式是加密-认证身份-鉴别权限-解密过程。
Api加固除了本身支持Https。还会额外进行上图中一系列的加密策略，自己定义对Resquest/Response Data进行加密，对url加密，甚至对request进行校验等。如果你增加RxJava操作符做一系列的加密流程。那将是锦上添花。解密过程也直接使用RxJava ，map操作符转换解密后返回给业务层，RxJava之前也介绍过好几篇，这里不再安利。
加固API主要由四种方案：
- 使用Https
- URL加密
- 參数加密
- 增加权限
- 时效验证
- 数字签名
Https
曾经写过一篇文章能够參考 ：Retrofit 2.0 超能实践（一），完美支持加密Https传输
URL加密
仅仅针对普通get请求，不针对post表单提交及ajax方式
策略：对于暴露在浏览器地址栏中的地址进行加密，如一个属性为name=tamic，
如果对tamic加密后为kadfxarf24saa：
如果真实值在这段字符中间，那么我们能够对前三位进行随机，后三位随机，
再对真实的tamic进行加密转换（base64都行），然后再来个倒序，那么剩下的数字我们能够获取当前时间追加。最后再进行md5都行，这样普通的用户无法感知详细路径真实值是什么，甚至一般黑客都无法轻易解析详细内容，服务端拿到详细值的策略也是一样
仅仅要按约定的好的算法进行解码就可以了。
这样不仅能防止恶意程序请求我们的服务端。并且还能对详细的參数地址进行加密。
參数加密
參数加密一般针对表单中的字段和值进行加密，防止中途第三方进行窥探和篡改。一般我们能够用okhttp的Interceptor 进行处理。 能够在发动报文前，对參数进行加密转码。
案列：
public class EncryptionInterceptor implements Interceptor {
private static final String TAG = EncryptionInterceptor.class.getSimpleName();
private static final boolean DEBUG = true;
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
RequestBody oldBody = request.body();
Buffer buffer = new Buffer();
oldBody.writeTo(buffer);
String strOldBody = buffer.readUtf8();
MediaType mediaType = MediaType.parse("text/plain; charset=utf-8");
String strNewBody = CodeMachine.encrypt(strOldBody);
RequestBody body = RequestBody.create(mediaType, strNewBody);
request = request.newBuilder().header("Content-Type", body.contentType().toString()).header("Content-Length", String.valueOf(body.contentLength())).method(request.method(), body).build();
return chain.proceed(request);
}}
加密算法自己和服务端约定就可以
private static String encrypt(String ){
//your code
}
add到client就可以
client = new OkHttpClient.Builder()
.addNetworkInterceptor(new EncryptionInterceptor()).build();
retrofit = new Retrofit.Builder().client(client).build();
服务端代码也是拿到详细參数进行同步的加密算法来进行反解密。
增加权限
权限控制也是对接口加密的一种业务层策略，比方一个电商APP。有商户，实用户，有中间物流商。还有中间服务商，那么同一个获取商品信息的权限不同的，商家有改动商品信息的权限。用户仅仅能浏览查看的功能。物流商能够有指定物流渠道权限，中间服务商能够拥有协调监督功能，如归有涉及假冒，法律的能够强制下架改商品，那么是相同一个getProductInfo接口 却又不同的信息，那么这个接口定义的时候。服务端和移动端就已经商讨好了协议，赋予不同角色权限.
public enum Permission {
User,
Shop,
Courier,
Platform
}
如上展示了四种角色控制，不同角色Server返回的数据Module也是不同的。 遇到三方恶意攻击，服务端确定并客户端发来的权限并非我们固定的角色。那么服务端也将视这次请求为无效的。
时效验证
时效验证通常是用来校验API是否过期。业内经常使用来做订单是否反复的根据之中的一个。比方用户在某个购物站点下单买东西时，就会生成下单的时间毫秒数，服务端拿到这个下单(Request)动作的网络请求，会检验这个时间是否过期。如果时间差值大于规定的值，就可视这个订单被中途篡改过。或者过期，比方一秒内反复从一个客户端发两个请求（Request），服务端（server）拿到时间发现已经存在一个。就不再处理第二个订单信息。提示用户不要反复提交。
一般时间值參数，不会单纯的在请求中单一传输，一般採用某种算法把客户端的时间戳 加密成一定字符后，在进行发送到SERVICE.这样的策略对于反复恶意刷单，有非常好的防御作用。
支付宝付款实则也是用的这样的策略，时间阀值大约3s左右。
数字签名
每一个Request也应该有响应的数字签名，这个签名不同于SSL机制的中的签名。仅仅是Client和server约定的一种自签名方式。额外校验Request数据有没有被篡改过，也能够称之为每一个Request有一定的唯一区分符-ID,签名算法可能非常复杂，一般根据本地设备ID，UserID,UUID，Token，综合进行计算，本质事实上就是加密。附带给Request。
总结
通过以上Retrofit的api加密列子。
在客户端api加固中，经常使用上面这几种综合来实现。做到万无一失。从数据源的加密，到传输过程中加密，到数据源获取到权限的校验，整个过程都是做了防御的，这样的思维我们能够參考：OAuth 工作原理，那么非常多时候我们也要对服务端返回的数据进行校验，兴许带来对response反校验一文。
阅读推荐
原文：http://blog.csdn.net/sk719887916/article/details/61914609
第一时间获取技术文章请关注公众号！
