Retrofit/OkHttp API接口加固技术实践(上)

RxJava+Retrofit 系列文章

Posted by Tamic on 2017-01-15

作者/Tamic
http://www.tamicer.com

写这篇文章,我纠结了很久,到底是属于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加固.png

Api加固除了本身支持Https,还会额外进行上图中一系列的加密策略,自定义对Resquest/``Response`` Data进行加密,对url加密,甚至对request进行校验等。如果你加入RxJava操作符做一系列的加密流程,那将是锦上添花。解密过程也直接使用RxJavamap操作符转换解密后返回给业务层,RxJava之前也介绍过好几篇,这里不再安利。

加固API主要由四种方案:

  • 使用Https
  • URL加密
  • 参数加密
  • 加入权限
  • 时效验证
  • 数字签名

##Https

以前写过一篇文章可以参考 :Retrofit 2.0 超能实践(一),完美支持加密Https传输

##URL加密

只针对普通get请求,不针对post表单提交及ajax方式

策略:对于暴露在浏览器地址栏中的地址进行加密,如一个属性为name=tamic

假设对tamic加密后为kadfxarf24saa
假设真实值在这段字符中间,那么我们可以对前三位进行随机,后三位随机,
再对真实的tamic进行加密转换(base64都行),然后再来个倒序,那么剩下的数字我们可以获取当前时间追加,最后再进行md5都行,这样普通的用户无法感知具体路径真实值是什么,甚至一般黑客都无法轻易解析具体内容,服务端拿到具体值的策略也是一样

只要按约定的好的算法进行解码就行了。这样不仅能防止恶意程序请求我们的服务端。而且还能对具体的参数地址进行加密。

##参数加密

参数加密一般针对表单中的字段和值进行加密,防止中途第三方进行窥探和篡改。一般我们可以用okhttp的Interceptor 进行处理。 可以在发动报文前,对参数进行加密转码。

案列:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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);
}
}
```
加密算法客户端自己和服务端约定;code如下:

private static String encrypt(String str) {
//your code

}

1
2
`add` 到 `OkHttpclient` 即可

client = new OkHttpClient.Builder()
.addNetworkInterceptor(new EncryptionInterceptor()).build();
retrofit = new Retrofit.Builder().client(client).build();

1
2
3
4
5
6
7
8
9
10
11
12
服务端代码也是拿到具体参数进行同步的加密算法来进行反解密。
**这种加密只是比较简单的对称加密,如果要想提高破解难度请使用非对称加密算法**
加入权限
---
权限控制也是对接口加密的一种业务层策略,比如一个电商APP,有商户,有用户,有中间物流商,还有中间服务商,那么同一个获取商品信息的权限不同的,商家有修改商品信息的权限,用户只能浏览查看的功能,物流商可以有指定物流渠道权限,中间服务商可以拥有协调监督功能,如归有涉及假冒,法律的可以强制下架改商品,那么是同样一个`getProductInfo`接口 却又不同的信息,那么这个接口定义的时候,服务端和移动端就已经商讨好了协议,赋予不同角色权限.
 public enum Permission {

  User,
  Shop,
  Courier,
  Platform
}

```

如上展示了四种角色控制,不同角色Server返回的数据Modle也是不同的。 遇到三方恶意攻击,服务端确定并客户端发来的权限并不是我们固定的角色,那么服务端也将视这次请求为无效的。

时效验证

时效验证一般是用来校验API是否过期,业内常用来做订单是否重复的依据之一。比如用户在某个购物网站下单买东西时,就会生成下单的时间毫秒数,服务端拿到这个下单(Request)动作的网络请求,会检验这个时间是否过期,如果时间差值大于规定的值,就可视这个订单被中途篡改过,或者过期,比如一秒内重复从一个客户端发两个请求(Request),服务端(server)拿到时间发现已经存在一个,就不再处理第二个订单信息,提示用户不要重复提交。

一般时间值参数,不会单纯的在请求中单一传输,一般采用某种算法把客户端的时间戳 加密成一定字符后,在进行发送到SERVICE.这种策略对于重复恶意刷单,有很好的防御作用。支付宝付款实则也是用的这种策略,时间阀值大约3s左右。

数字签名

每个Request也应该有响应的数字签名,这个签名不同于SSL机制的中的签名,只是Client和server约定的一种自签名方式,额外校验Request数据有没有被篡改过,也可以称之为每个Request有一定的唯一区分符-ID,签名算法可能很复杂,一般依据本地设备ID,UserID, UUIDToken,综合进行计算,本质其实就是加密,附带给Request

总结

通过以上Retrofit的api加密列子。在客户端api加固中,常用上面这几种综合来实现,做到万无一失,从数据源的加密,到传输过程中加密,到数据源获取到权限的校验,整个过程都是做了防御的,如过需要个三方提供接口 可以参考:OAuth 工作原理,那么很多时候我们也要对服务端返回的数据进行校验,后续带来对response反解密一文。

阅读推荐

App安全(一) Android防止升级过程被劫持和换包


第一时间获资讯请关注微信公众号!

开发者技术前线