做好的apk文件，被檢測工具檢測出一大堆風險問題，是不是感覺自己的付出白費了，今天咱就聊聊android的安全防范問題。

一，先說安全檢查方面的吧

1，源文件安全問題方面

     1.1篡改和二次打包風險

     1.2應用簽名未校驗風險

     1.3Java代碼反編譯風險檢測

     1.4代碼未混淆風險檢測

     1.5資源文件泄露風險檢測

2，數(shù)據(jù)存儲安全問題方面

     2.1 WebView明文存儲密碼風險檢測

     2.2Internal Storage數(shù)據(jù)全局可讀寫風險檢測

     3.3加密算法不安全使用風險

     4.4日志數(shù)據(jù)泄露風險

     4.5URL硬編碼風險

3，組件風險

     3.1Activity組件導出風險

     3.2Service組件導出風險

     3.3Content Provider組件導出風險

     3.4Broadcast Receiver組件導出風險

     3.5WebView遠程代碼執(zhí)行漏洞

     3.6Intent Scheme URL攻擊風險

4，安全防護能力

      4.1Java層代碼動態(tài)調試風險

      4.2C層代碼動態(tài)調試風險

      4.3動態(tài)注入攻擊風險

      4.4模擬器運行風險

      4.5啟動隱藏服務風險

      4.6Root設備運行風險

5，內容風險

      5.1自定義詞匯

     5.2敏感文本

      5.3敏感圖片

這種類型的風險存在于發(fā)布文章類或信息類應用，“涉黃”，“賭博”等詞匯與圖片需要進行敏感內容識別或過濾。為了節(jié)約成本，可以人工審核信息來完成，當然，這樣工作量太大，要是有Money的話可以介入專業(yè)的

檢測公司API，來讓應用的內容安全做的更嚴密些。

二，在自己沒錢的情況下，看我們能做哪些事吧

1，打包應用，基本要加的就是混淆了，當然，我們還要再創(chuàng)建一個簽名文件

2，要是我們應用體積大了，還可以再壓縮一下資源文件，我用 的是 AndResGuard

3，沒錢，沒辦法啊，那就來個免費的加固服務吧。

做到這些，是不是大家都覺得，我也是這樣做的。是的，一般我們程序都會做這些基本的操作，但是我們還可以再做些什么？

情況1，應用被反編譯后二次打包了----apk在正式打包后生成hash簽名保存在服務端。應用每次啟動后校驗當前應用hash與服務端保存的是不是一致，以此來校驗應用是不是合法的。嘿嘿，是不是解決問題的一種方法了

上代碼：

/**
 * 根據(jù)apk MD5摘要獲取對應的哈希值
 *
 * @param context
 * @return
 */
public static String getApkHashValue(Context context) {
    String apkPath = context.getPackageCodePath(); // 獲取Apk包存儲路徑
    try {
        MessageDigest dexDigest = MessageDigest.getInstance("MD5");
        byte[] bytes = new byte[1024];
        int byteCount;
        FileInputStream fis = new FileInputStream(new File(apkPath)); // 讀取apk文件
        while ((byteCount = fis.read(bytes)) != -1) {
            dexDigest.update(bytes, 0, byteCount);
        }
       /* BigInteger bigInteger = new BigInteger(1, dexDigest.digest()); // 計算apk文件的哈希值
        String sha = bigInteger.toString(16);*/
        //解決MD5在特殊情況下丟失0的情況
        StringBuffer buf = new StringBuffer();
        byte[] b = dexDigest.digest();
        int i;
        for (int offset = 0; offset < b.length; offset++) {
            i = b[offset];
            if (i < 0) {
                i += 256;
            }
            if (i < 16) {
                buf.append("0");
            }
            buf.append(Integer.toHexString(i));
        }
        fis.close();
        return buf.toString();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
        return "";
    } catch (FileNotFoundException e) {
        e.printStackTrace();
        return "";
    } catch (IOException e) {
        e.printStackTrace();
        return "";
    }
}

情況2；很多時候apk被反編譯或被破壞，多通過模擬器或者獲取root權限來操作

沒辦法，只能給模擬器說再見了。正式發(fā)布程序后，代碼檢測運行設備是否是模擬器，如果是的話，就不讓運行了，root 設備一樣的驗證邏輯，簡單粗暴!!!

但是root或模擬器檢測并沒有官方的或權威的檢測代碼，誰讓android品牌太多太雜了捏，沒辦法。真遇到這種兼容性問題的話，沒事，我們可以再做檢查邏輯時，留一手服務端驗證，

由服務端來控制這個版本或者某個用戶走不走這部分驗證邏輯額~~~~~，后邊的可以自行發(fā)揮解決。

情況3，動態(tài)調試，內存讀取......

和情況2思路一致，均是通過代碼來檢測是否有調試等工具在調試程序，然后做出相應的判斷處理

其他情況都比較常見了，隨便百度就能找到解決方法，這里就不啰嗦了。嘿嘿

最后，要是你們公司很有錢，那就不考慮那么多了，來個專業(yè)機構加密，一下風險就降到最低，只要有money~

沒有絕對的安全，我們能做的就是把安全風險降到最低，歐力給！

以上就是淺談Android安全風險與防范措施的詳細內容，更多關于Android安全風險與防范措施的資料請關注腳本之家其它相關文章！

最新評論