[轉]Android安全防禦 [很好介紹和應對]

時間 2019-12-02

標籤 android 安全防禦很好介紹應對欄目 Android 简体版

原文原文鏈接

Android安全防禦

標籤： android 安全 app安全 app防禦

2017-08-04 15:33 536人閱讀評論(15) 收藏舉報

分類：

android安全

目錄(?)[+]html

各位大佬好，今天談一下我在實際項目開發中遇到的APP安全以及我作的防禦

Android開發者經常面臨的一個問題就是防破解、防二次打包。現現在,安全問題愈來愈重要,愈來愈多的Android開發者也開始尋求安全的保護方案。首先說一下，我作的是保險行業的應用。因此有不少安全監測的東西要過。其實通常的公司，外包什麼的不多管APP的安全的。即便你的應用中集成了微信支付寶的支付。也不須要你自身作什麼太多的安全性的東西
今天我根據綠盟和360監測出來的報告說一下（因爲國企，因此是花錢請綠盟和360進行監測的。有大佬要笑了，固然這個檢測不是碼雲上面的檢測，後面我也會給新手說一下碼雲的檢測）

接下來細講一下每一個安全監測的點。文章最後給你們介紹一些監測工具，你們能夠玩玩

這裏先說一下APK加固
- 防止二次打包（盜版）
- 防止逆向分析
- 防止調試及注入
- 防止應用數據竊取
- 防止木馬病毒
- 防篡改（APK篡改工具：APK改之理，AndroidKiller）
以上的防禦均可以用APP加固來實現，這裏先說一下最簡單的反編譯，相信不少人都用過反編譯工具。其實咱們正常打包出來的apk就是一個壓縮包，你解壓縮或者反編譯基本就拿到了你這個應用的源代碼。反編譯工具:dex2jar(ApkToolkit) jd-gui 等。我使用的是
對你的apk解壓縮後，你能夠看到以下：

當你對你的應用進行加固之後，你再嘗試着去反編譯，我這裏以360加固爲例，你反編譯以後的獲得東西以下
未加固APK:

加固APK:

這裏你們百度確定能看到一些什麼360脫殼聖戰啊什麼的文章介紹，我想說那是扯淡的。不相信的朋友能夠按照那些文章去試試。這裏介紹一下國內的幾個加固商

固然還有其餘的加固廠商，好比百度、騰訊、阿里、通付盾、網易易盾。這裏你們喜歡用哪一個就用哪一個。騰訊和阿里雖然是IT巨頭，可是畢竟有些廠商是專業作這個的。這裏我就不作推薦了，有些加固自帶崩潰日誌，數據分析等等。使用加固後可對以上進行有效的防禦。加固APK以後：篡改後沒法正常運行、沒法正常動態調試、反動態注入沒法注入、反編譯沒法獲取到原dex代碼或完整的dex代碼、So文件的總體加密，使用自定義連接器的技術,對SO文件進行總體的加密,徹底阻止 IDA等逆向工具的靜態分析。java

App採用加固(加殼)的最終目的是爲了防止盜版、反編譯、動態調試以及惡意注入行爲等,但加固後仍有被脫殼的風險,可能這個時候你們可能就有疑惑了,還有必要進行加固嗎?答案是確定的,咱們舉個例子:咱們的房子都會安裝防盜門,但全世界幾乎天天都會有一些家庭失竊,但人們並無由於安裝了防盜門還被小偷偷了東西,今後放棄安裝防盜門,加固其實就比如防盜門,並不能百分百保證不被脫殼,固然加固技術也在不斷的提升和更新,咱們須要選擇一款安全性高的加固產品。咱們能夠過濾掉絕大部分人的惡意攻擊

如今說一下安全檢測的項目

1）客戶端安全測試包含

客戶端程序保護
– 描述：判斷是否能反編譯爲源代碼，是否存在代碼保護措施
– 測試：是否能經過用反編譯工具查看源代碼
– 建議：建議客戶端進行加殼處理防止攻擊者反編譯客戶端，同時混淆客戶端代碼，而且必定要對核心代碼進行代碼混淆。
安裝包簽名
– 描述：客戶端安裝包是否正確簽名。經過簽名，能夠檢測出安裝包在簽名後是否被修改過。
– 檢測：利用二次打包工具可否成功打包運行
– 建議：客戶端使用從屬方證書進行簽名後進行發佈而不是使用第三方開發商的證書進行簽名，以防開發商內部監管異常，證書濫用的狀況出現。
應用完整性校驗
– 描述：測試客戶端程序安裝後，在每次啓動時是否對自身文件進行完整性校驗。
– 檢測：修改資源文件，二次打包可否運行
– 建議：建議客戶端在每次開機啓動時進行客戶端自身的應用完整性校驗，在驗證邏輯中不使用MANIFEST.MF中的數據做爲驗證憑證，同時需驗證是否有不屬於該客戶端版本的新文件添加，驗證過程於服務器端完成。
組件安全
– 描述：測試客戶端是否包含後臺服務、Content Provider、第三方調用和廣播等組件，Intent權限的設置是否安全。應用不一樣組成部分之間的機密數據傳遞是否安全。程序是否竊取手機用戶的隱私信息。
– 建議：建議在開發客戶端時不要暴露內部組件，若是有特殊需求也需進行權限控制，令使用這些組件時須要申請相應權限。android
總體解決：以上客戶端程序保護可經過代碼混淆配合apk加固所有解決git

2）敏感信息安全包含

私有目錄下的文件權限
– 描述：測試客戶端私有目錄下的文件權限是否設置正確，非root帳戶是否能夠讀，寫，執行私有目錄下的文件。
– 檢測：

– 建議：私有目錄下文件不可讀寫
SQLite數據庫文件的安全性
– 描述：敏感信息是否明文存儲
– 檢測：檢測數據庫裏面的重要信息，好比帳號密碼之類的是否明文存儲
– 建議：重要信息進行加密存儲
Logcat日誌
– 描述：檢測客戶端對應的Logcat日誌是否會打印一些用戶或服務器的敏感信息。
– 檢測：用ddms工具尋找敏感信息輸出
– 建議：具備敏感信息的調試信息開關必定要關閉。
總體解決：對於安卓開發來說，咱們解決敏感信息問題就是對重要數據進行加密存儲，log日誌不打印敏感信息。我是真的見過帳號密碼保存在本地明文存儲的，因此切記加密存儲重要信息

3）密碼軟鍵盤

鍵盤劫持測試
– 描述：測試客戶端程序在密碼等輸入框是否使用自定義軟鍵盤。安卓應用中的輸入框默認使用系統軟鍵盤，手機安裝木馬後，木馬能夠經過替換系統軟鍵盤，記錄應用的密碼。
– 檢測：這個應該經過看就能看出來
– 建議：建議客戶端開發自定義軟鍵盤而不是使用系統軟件盤以防止鍵盤劫持攻擊。
軟鍵盤安全性測試
– 描述：測試客戶端是否使用隨機佈局的密碼軟鍵盤。
– 檢測：仍是眼睛看
– 建議：建議客戶端對自定義軟鍵盤進行隨機化處理，同時在每次點擊輸入框時都進行隨機初始化。
屏幕錄像測試
– 描述：測試經過連續截圖，是否能夠捕捉到用戶密碼輸入框的密碼。
– 檢測：經過連續截圖，是否能夠捕捉到用戶密碼輸入框的密碼。
– 建議：建議客戶端針對第三方或系統截屏編寫抵抗邏輯，例如屏蔽和截屏相關的函數或是當客戶端處於進程棧頂層時將截屏圖片用純黑色圖片對象進行覆蓋。
總體解決：鍵盤劫持通常都是要自定義鍵盤的，並且自定義的鍵盤不要長的和系統鍵盤同樣就行，每次點擊輸入框時都進行隨機初始化卻是不必。由於不少銀行的也沒有這樣作，並且作起來我認爲困難仍是有的。以手機銀行例,大多數銀行採用自繪鍵盤代替系統鍵盤,防止了系統鍵盤監聽行爲,但有些開發者忽略了截屏保護，這樣連續快速截屏，或者視頻錄製就能夠獲取用戶的密碼。下面代碼是防截屏、視頻錄製的代碼

getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE);// 防止屏幕截屏

4）安全策略

密碼複雜度
– 描述：測試客戶端程序是否檢查用戶輸入的密碼，禁止用戶設置弱口令
– 測試：修改設置用戶名密碼時，能夠設置111111相似弱口令
– 建議：建議在服務器編寫檢測密碼複雜度的安全策略，並將其運用到帳號註冊，密碼修改等須要進行密碼變動的場景，以防止攻擊者經過弱密鑰遍歷帳戶的方式進行暴力猜解。
帳戶鎖定策略
– 描述：測試客戶端是否限制登陸嘗試次數。防止木馬使用窮舉法暴力破解用戶密碼
– 測試：錯誤密碼登陸請求屢次（10次以上尚未就有問題了，通常都是3次）
– 建議：建議在服務端編寫帳戶鎖定策略的邏輯，當一天內屢次輸入密碼錯誤時進行帳號鎖定以防止攻擊者經過暴力猜解密碼。
會話安全設置
– 描述：測試客戶端在必定時間內無操做後，是否會使會話超時並要求從新登陸。超時時間設置是否合理。
– 檢測：客戶端在必定時間內無操做（20分鐘足夠），是否會話超時登陸
– 建議：建議在客戶端編寫會話安全設置的邏輯，當10分鐘或20分鐘無操做時自動退出登陸狀態或是關閉客戶端。
界面切換保護
– 描述：檢查客戶端程序在切換到後臺或其餘應用時，是否能恰當響應（如清除表單或退出會話），防止用戶敏感信息泄露
– 檢測：應用切換到後臺但程序沒有結束運行，再返回應用的時候是否有身份驗證，手勢密碼或者登錄密碼。
– 建議：建議客戶端添加響應的邏輯，在進行進程切換操做時提示用戶確認是否爲本人操做。
界面劫持保護
– 描述：檢查客戶端是否對非正常的界面切換進行檢測，並對用戶進行提示。
– 檢測：界面被劫持時是否有提示
– 建議：因爲Activity界面劫持攻擊一般是將本身的頁面附着在客戶端之上，所以須要進行界面切換操做，所以使用界面切換保護的安全建議能夠達到必定的效果。除此以外，由於Android進程棧的工做原理，建議開發客戶端時針對進程棧進行相應的保護，可禁止其餘進程放置於客戶端之上。
UI信息泄露
– 描述：檢查客戶端的各類功能，看是否存在敏感信息泄露問題。
– 檢測：好比登陸時，密碼輸入錯誤，APP是否會提示密碼輸入錯誤
– 建議：建議用戶名或密碼輸入錯誤均提示「用戶名或密碼錯誤」，若客戶端同時還但願保證客戶使用的友好性，能夠在登錄界面經過舒適提示的方式提示輸入錯誤次數，密碼安全策略等信息，以防用戶屢次輸入密碼錯誤致使帳號鎖定。
帳號登陸限制
– 描述：測試可否在兩個設備上同時登陸同一個賬號。
– 檢測：測試可否在兩個設備上同時登陸同一個賬號。
– 建議：建議在服務器進行帳號登錄限制相應邏輯代碼的編寫，經過Session或數據庫標誌位的方式控制同一時間只有一個設備能夠登錄某一帳號。
安全退出
– 描述：驗證客戶端在用戶退出登陸狀態時是否會和服務器進行通訊以保證退出的及時性
– 檢測：客戶端在用戶退出登陸時，查看session是否可用
建議：保證客戶端和服務器同步退出，APP退出時服務器端的清除會話
密碼修改驗證
– 描述：驗證客戶端在進行密碼修改時的安全性
– 檢測：是否存在原密碼驗證
– 建議：建議在修改密碼時，客戶端及服務器系統增添原密碼輸入驗證身份的邏輯，以防Cookie登錄修改密碼的攻擊。
私密問題驗證
– 描述：驗證客戶端是否存在忘記密碼時的私密問題驗證
– 檢測：相似於QQ的私密問題驗證
– 建議：我以爲這個根據需求走，也不必定說這個就好。一個普通的APP這樣搞，用戶體驗會不好。除非你作到了QQ那種地步github
總體解決：無，一個一個搞吧，須要和後臺配合着。這裏只說一下界面劫持
@Override protected void onPause() { // 若程序進入後臺不是用戶自身形成的，則須要彈出警示 if (needAlarm) { // 彈出警示信息 Toast.makeText(getApplicationContext(), "XX的登錄界面被覆蓋，請確認登錄環境是否安全", Toast.LENGTH_SHORT).show(); } super.onPause(); }
就是在登陸界面重寫onPause方法。這個界面劫持只須要在登陸界面作防禦。needAlarm是定義的變量，初始化爲true，而後監聽home鍵和返回鍵以及你自身登陸界面的其餘activity的跳轉。若是用戶執行了監聽的操做needAlarm賦值爲false，說明是用戶自身的操做，不是界面劫持。算法

5）手勢密碼

手勢密碼複雜度
– 描述：測試客戶端手勢密碼複雜度，觀察是否有點位數量判斷邏輯
– 檢測：這個應該沒有明確的，就是自身感覺吧
– 建議：本身定標準吧數據庫
手勢密碼修改和取消
– 描述：檢測客戶端在取消手勢密碼時是否會驗證以前設置的手勢密碼，檢測是否存在其餘致使手勢密碼取消的邏輯問題
– 檢測：檢測客戶端在取消手勢密碼時是否會驗證以前設置的手勢密碼，檢測是否存在其餘致使手勢密碼取消的邏輯問題
– 建議：不該該存在其餘致使手勢密碼取消的邏輯，客戶端在取消手勢密碼時應驗證以前設置的手勢密碼數組
手勢密碼本地信息保存
– 描述：檢測在輸入手勢密碼之後客戶端是否會在本地記錄一些相關信息，例如明文或加密過的手勢密碼。
– 檢測：找到存儲文件，看其是否加密
– 建議：應該進行加密瀏覽器
手勢密碼鎖定策略
– 描述：測試客戶端是否存在手勢密碼屢次輸入錯誤被鎖定的安全策略。防止木馬使用窮舉法暴力破解用戶密碼。由於手勢密碼的存儲容量很是小，一共只有9！=362880種不一樣手勢，若手勢密碼不存在鎖定策略，木馬能夠輕易跑出手勢密碼結果。手勢密碼在輸入時一般以a[2][2]這種3*3的二維數組方式保存，在進行客戶端同服務器的數據交互時一般將此二維數組中數字轉化爲相似手機數字鍵盤的b[8]這種一維形式，以後進行一系列的處理進行發送。
手勢密碼抗攻擊測試
– 描述：驗證是否能夠經過插件繞過手勢密碼的驗證頁面
總體解決：手勢密碼的後面兩個檢測我也沒有遇到過。並且如今手勢密碼怎麼說，可能我接觸的不是不少吧。有興趣的朋友能夠找相關資料研究下

6）通訊安全

通訊加密
– 描述：驗證客戶端和服務器以前的通訊是否使用加密信道。
– 檢測：能夠利用抓包軟件進行查看
– 建議：使用https或者是http+403端口進行通訊。
關鍵數據加密和校驗
– 描述：測試客戶端程序提交數據給服務端時，密碼等關鍵字段是否進行了加密和校驗，防止惡意用戶嗅探和修改用戶數據包中的密碼等敏感信息。
– 檢測：抓包
– 建議：建議帳號，密碼，卡號，金額等進行加密處理，同時整個數據包進行二次加密，返回的敏感信息進行加密，同時返回數據包進行二次加密，而且使用增長隨機因子的校驗字段，而且肯定服務器邏輯標誌位正確，在刪除校驗字段時服務器不響應提交的數據包。
證書有效性驗證
– 描述：驗證客戶端和服務器之間是否存在雙向驗證的機制，同時確認此機制是否完善，服務器是否以白名單的方式對發包者的身份進行驗證
– 檢測：抓包
– 建議：建議客戶端和服務器進行雙向認證，而且服務器經過白名單的方式驗證客戶端證書以保證證書的有效性。
訪問控制
– 描述：測試客戶端訪問的URL是否僅能由手機客戶端訪問。是否能夠繞過登陸限制直接訪問登陸後才能訪問的頁面，對須要二次驗證的頁面（如私密問題驗證），可否繞過驗證。
– 檢測：利用截包工具獲取url，能用瀏覽器打開該url。
– 建議：建議服務器進行相應的訪問控制，控制對應頁面僅能經過手機客戶端訪問。同時進行頁面訪問控制，防止繞過登錄直接訪問頁面的非法訪問。
短信重放攻擊
– 描述：檢測應用中是否存在數據包重放攻擊的安全問題。是否會對客戶端用戶形成短信轟炸的困擾。
– 建議：抓包
– 建議：token和手機號一塊兒，重放沒法形成短信轟炸

7）業務安全

這個須要根據業務進行檢測

8）這裏我多介紹一個，通常黑客進行攻擊確定不會是用手機進行，多用模擬器進行攻擊。如今的模擬器基本和手機同樣。咱們沒法過濾全部的模擬器，可是能夠過濾免費的模擬器，也就是必定程度上進行防禦

實踐大多數免費的模擬器，都沒有藍牙的功能

BluetoothAdapter blueadapter = BluetoothAdapter
                                .getDefaultAdapter();
                        if ((blueadapter == null)
                                || (blueadapter.getAddress() == null && blueadapter
                                        .getName() == null)) {
                            MessageBox.promptDialog("請使用真實手機登錄",
                                    LoginActivity.this);
                        }

固然else以後我是登陸操做，可是登陸前作了一些東西。這個就像消息推送同樣，手機的惟一標識cid之類的綁定。這裏只是給出個思路

9）短信驗證，最好是作60秒倒計時。

10）App測試安全等級劃分

11）工具及相關資源

工具名稱 Apktool
工具用途 GOOGLE提供的APK編譯工具，可以反編譯及回編譯apk。
相關信息 https://code.google.com/p/android-apktool/
工具名稱 Dex2jar
工具用途將Android的dex文件反編譯爲java源碼。
相關信息 https://code.google.com/p/dex2jar/w/list
工具名稱 Jd-gui
工具用途反編譯代碼閱讀工具。
相關信息 http://jd.benow.ca/
工具名稱 Portecle
工具用途證書管理工具，能夠進行證書維護。
相關信息 http://www.oschina.net/p/portecle
工具名稱 SuperOneClick
工具用途 Android手機root工具
相關信息 http://www.superoneclick.cc/
工具名稱 Proxydroid
工具用途 Android手機用代理軟件。
相關信息 https://github.com/madeye/proxydroid
工具名稱 MemSpector
工具用途 Android手機內存修改工具
相關信息 http://www.nosec.org
工具名稱 BurpSuite
工具用途 HTTP數據包修改、轉發工具
相關信息 http://portswigger.net/burp/
工具名稱 Fiddler
工具用途 HTTP數據包修改、轉發工具
相關信息 http://www.fiddler2.com/fiddler2/
工具名稱 Xposed框架
工具用途系統級框架，用於開發底層插件進行測試
相關信息 http://repo.xposed.info/module/de.robv.android.xposed.installer
工具名稱 SwipeBack
工具用途 Xposed插件，用於繞過登錄界面
相關信息 http://repo.xposed.info/module/us.shandian.mod.swipeback
工具名稱 Android Development Tools
工具用途支持Android開發的工具
相關信息 http://developer.android.com/tools/help/adt.html

12）說了以後會說一下代碼檢測

eclipse 使用插件findbugs
studio 使用lint
至於碼雲，是你把代碼上傳上去，碼雲會爲你檢測你的代碼。
這個我隨便截兩張圖給你們看一下，你們瞭解一下。一看大家就知道是什麼了

13）在這簡單提一下加密
加密分爲對稱加密和非對稱加密
區分對稱加密和非對稱加密。對稱加密的加密密鑰和解密密鑰是相同的。非對稱加密的加密密鑰和解密密鑰不一樣
對稱加密
– 特色：高效，存在密鑰交換問題，安全度不如RSA，可是能勝任大部分加密
– 明文P 加密方法E 密文E(P) 解密方法D 加密密鑰K 解密密鑰K’
DK’(EK(P)) = P K = K’
EK(P)：這是加密
對稱加密是基於乘積加密的（乘積加密是結合了置換算法和轉置算法，有興趣能夠了解一下）。而AES和DES都是基於乘積加密。AES加密比DES要高。可是如今也有3DES加密。
非對稱加密
– 特色：安全性高，沒有密鑰交換問題，效率低
– 明文P 加密方法E 密文E(P) 解密方法D 加密密鑰K 解密密鑰K’
DK’(EK(P)) = P K ！= K’（公鑰和私鑰不同，可是同時產生）
你們若是以爲還能看，頂下鼓勵一下，謝謝。有不妥之處也歡迎你們評論