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反校驗一文。

閱讀推薦

App安全（一） Android防止升級過程被劫持和換包H

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

第一時間獲取技術文章請關注公衆號！