做好的apk文件，被檢測(cè)工具檢測(cè)出一大堆風(fēng)險(xiǎn)問題，是不是感覺自己的付出白費(fèi)了，今天咱就聊聊android的安全防范問題。

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

1，源文件安全問題方面

     1.1篡改和二次打包風(fēng)險(xiǎn)

     1.2應(yīng)用簽名未校驗(yàn)風(fēng)險(xiǎn)

     1.3Java代碼反編譯風(fēng)險(xiǎn)檢測(cè)

     1.4代碼未混淆風(fēng)險(xiǎn)檢測(cè)

     1.5資源文件泄露風(fēng)險(xiǎn)檢測(cè)

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

     2.1 WebView明文存儲(chǔ)密碼風(fēng)險(xiǎn)檢測(cè)

     2.2Internal Storage數(shù)據(jù)全局可讀寫風(fēng)險(xiǎn)檢測(cè)

     3.3加密算法不安全使用風(fēng)險(xiǎn)

     4.4日志數(shù)據(jù)泄露風(fēng)險(xiǎn)

     4.5URL硬編碼風(fēng)險(xiǎn)

3，組件風(fēng)險(xiǎn)

     3.1Activity組件導(dǎo)出風(fēng)險(xiǎn)

     3.2Service組件導(dǎo)出風(fēng)險(xiǎn)

     3.3Content Provider組件導(dǎo)出風(fēng)險(xiǎn)

     3.4Broadcast Receiver組件導(dǎo)出風(fēng)險(xiǎn)

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

     3.6Intent Scheme URL攻擊風(fēng)險(xiǎn)

4，安全防護(hù)能力

      4.1Java層代碼動(dòng)態(tài)調(diào)試風(fēng)險(xiǎn)

      4.2C層代碼動(dòng)態(tài)調(diào)試風(fēng)險(xiǎn)

      4.3動(dòng)態(tài)注入攻擊風(fēng)險(xiǎn)

      4.4模擬器運(yùn)行風(fēng)險(xiǎn)

      4.5啟動(dòng)隱藏服務(wù)風(fēng)險(xiǎn)

      4.6Root設(shè)備運(yùn)行風(fēng)險(xiǎn)

5，內(nèi)容風(fēng)險(xiǎn)

      5.1自定義詞匯

     5.2敏感文本

      5.3敏感圖片

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

檢測(cè)公司API，來讓應(yīng)用的內(nèi)容安全做的更嚴(yán)密些。

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

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

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

3，沒錢，沒辦法啊，那就來個(gè)免費(fèi)的加固服務(wù)吧。

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

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

上代碼：

/**
 * 根據(jù)apk MD5摘要獲取對(duì)應(yīng)的哈希值
 *
 * @param context
 * @return
 */
public static String getApkHashValue(Context context) {
    String apkPath = context.getPackageCodePath(); // 獲取Apk包存儲(chǔ)路徑
    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()); // 計(jì)算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；很多時(shí)候apk被反編譯或被破壞，多通過模擬器或者獲取root權(quán)限來操作

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

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

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

情況3，動(dòng)態(tài)調(diào)試，內(nèi)存讀取......

和情況2思路一致，均是通過代碼來檢測(cè)是否有調(diào)試等工具在調(diào)試程序，然后做出相應(yīng)的判斷處理

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

最后，要是你們公司很有錢，那就不考慮那么多了，來個(gè)專業(yè)機(jī)構(gòu)加密，一下風(fēng)險(xiǎn)就降到最低，只要有money~

沒有絕對(duì)的安全，我們能做的就是把安全風(fēng)險(xiǎn)降到最低，歐力給！

以上就是淺談Android安全風(fēng)險(xiǎn)與防范措施的詳細(xì)內(nèi)容，更多關(guān)于Android安全風(fēng)險(xiǎn)與防范措施的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論