Retrofit/Okhttp API接口加固技术实践（上）

Posted 2020-09-04 Tamic大白

作者：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反校验一文。

阅读推荐

App安全（一） Android防止升级过程被劫持和换包H

原文：http://blog.csdn.net/sk719887916/article/details/61914609

第一时间获取技术文章请关注公众号！