**
  安全對一些涉及到直接的金錢交易或個人隱私相關的應用的重要性是不言而喻的。Android系統由於其開源的屬性，市場上針對開源代碼定制的ROM參差不齊，在系統層面的安全防范和易損性都不一樣，Android應用市場對app的審核相對iOS來說也比較寬泛，為很多漏洞提供了可乘之機。市場上一些主流的app雖然多少都做了一些安全防范，但由於大部分app不涉及資金安全，所以對安全的重視程度不夠；而且由於安全是門系統學科，大部分app層的開發人員缺乏安全技術的積累，措施相對有限。

  本文將重點分析Android APP面臨的安全問題、防范措施以及一系列安全技術方案的實施。

**

---

面臨的安全問題

病毒

Android病毒就是手機木馬，主要是一些惡意的應用程序。比如去年央視曝光的一款名為“銀行悍匪”的手機銀行木馬，模仿真正的手機銀行軟件，通過釣魚方式獲取用戶輸入的手機號、身份證號、銀行賬號、密碼等信息，並把這些信息上傳到黑客指定服務器。盜取銀行賬號密碼後，立即將用戶賬戶裡的資金轉走。手機木馬有的獨立存在，有的則偽裝成圖片文件的方式附在正版App上，隱蔽性極強，部分病毒還會出現變種，並且一代比一代更強大。

這些病毒有一些通用的特征：

母包+惡意子包的運行機制。 通過技術手段防止用戶通過正常途徑卸載。 以竊取用戶賬戶資金為目的。 以短信作為指令通道。

關鍵信息洩露

雖然java代碼一般要做混淆，但是Android的幾大組件的創建方式是依賴注入的方式，因此不能被混淆，而且目前常用的一些反編譯工具比如apktool等能夠毫不費勁的還原java裡的明文信息，native裡的庫信息也可以通過objdump或IDA獲取。因此一旦java或native代碼裡存在明文敏感信息，基本上就是毫無安全而言的。

APP重打包

即反編譯後重新加入惡意的代碼邏輯，從新打包一個APK文件。重打包的目的一般都是上面提到和病毒結合，對正版apk進行解包，插入惡意病毒後重新打包並發布，因此偽裝性很強。截住app重打包就一定程度上防止了病毒的傳播。
　

進程被劫持

這個幾乎是目前針對性最強的一種攻擊方式了，一般通過進程注入或者調試進程的方式來hook進程，改變程序運行的邏輯和順序，獲取程序運行的內存信息，也就是用戶所有的行為都被監控起來，這也是盜取帳號密碼最常用的一種方式。

 當然 hook行為不一定完全是惡意的，比如有些安全軟件會利用hook的功能做主動防御（比如 LBE和我們移動安全實驗室最新的apkprotect線上加固產品）。一般來說，hook需要獲取root權限或者跟被hook進程相同的權限，因此如果你的手機沒有被root，而且是正版apk的話，被注入還是很困難的。　

數據在傳輸過程中遭劫持

傳輸過程最常見的劫持就是中間人攻擊。很多安全要求較高的應用程序要求所有的業務請求都是通過https，但是https的中間人攻擊也逐漸多了起來，而且我們發現在實際使用中，證書交換和驗證在一些山寨手機或者非主流ROM上面存在一些問題，讓https的使用碰到阻礙。

鍵盤輸入安全隱患

支付密碼一般是通過鍵盤輸入的，鍵盤輸入的安全直接影響了密碼的安全。鍵盤的安全隱患來自三個方面：

使用第三方輸入法，則所有的點擊事件在技術上都可以被三方輸入法截取，如果不小心使用了一些不合法的輸入法，或者輸入法把采集的信息上傳並且洩露，後果是不堪設想的。 截屏，該方法需要手機具有root權限，才能跑起截屏軟件 getevent，通過讀取系統驅動層dev/input/event1中的信息，獲取手機觸屏的位置坐標，在結合鍵盤的布局，就能算出來事件跟具體數字的映射關系，這也是目前比較常用的攻擊方式。

  之前做過一套安全鍵盤的方案，就是自定義話鍵盤+數字布局隨機化。但是隨機化的鍵盤很不符合人性的操作習慣。所以之後的隨機話也去掉了。

  還需要說明下，還有一種更為安全的方式就是現在trustzone的標准已經有GlobalPlatform_Trusted_User_Inteface,也就是說在trustzone裡實現安全界面的一套標准，如果安全鍵盤在trustzone裡彈出，則黑客不管通過啥手段都無法拿到密碼，是目前最為安全的方式，但是trustzone依賴於設備底層實現，如果設備不支持trustzone，或者trustzone不支持GlobalPlatform_Trusted_User_Inteface標准，我們也無能為力。*

Webview漏洞

由於現在hybrid app的盛行，Webview在app的使用也是越來越多，Android 系統Webview存在一些漏洞，造成js提權。最為著名的就是傳說中js注入漏洞和webkit xss漏洞，下面的章節我們會詳細介紹。

服務器未做處理，遭到滲透攻擊

這個最多的就是防重放攻擊和注入攻擊，這個不在本次文文討論范圍內。

Android APP安全體系架構

熟悉Https

從本質上講，https就是一個雙向身份驗證的過程，但是由於Android設備太多太亂，Android設備證書也不統一，一般只有客戶端驗證服務器端證書，而服務器端在https層是不會驗證客戶端證書的，所以實際應用場景是一個單向身份驗證的過程。

schemeRegistry.register(new Scheme(https, SSLSocketFactory.getSocketFactory(), 443));

這個是利用google API來對https進行校驗，主要檢查四個方面的內容：

簽名CA是否合法 域名是否匹配 是不是自簽名證書 證書是否過期

如果服務器所使用的根證書是自簽名的，或者簽名機構不在設備的信任證書列表中，這樣使用httpclient進行https連接就會失敗。解決這個問題的辦法有幾種：

最簡單的做法就是httpclient不開啟證書校驗，信任所有證書的方式。這種辦法相對來說簡單很多，但安全性就相當於http一樣差，黑客可以輕易偽造證書進行中間人攻擊，造成用戶交易數據等敏感信息洩露。現在大部分的手機浏覽器為了兼容各個證書參差不齊的網站，就是采取的這樣的方式，但是也有些主流浏覽器對非根的證書，只檢查host和有效期，如果失敗，給用戶提示，還能繼續浏覽嗎還是中斷了的提示來保證用戶體驗的同時來提升安全性。

采用了覆蓋google默認的證書檢查機制（X509TrustManager）的方式，在發起https連接之前將服務器證書加到httpclient的信任證書列表中，這個相對來說比較復雜一些，很容易出錯，而且每個網站的自定義證書都不一樣，很難找到統一的辦法對所有非根證書進行證書檢查。

支付密碼安全

支付密碼只是一個比較有代表性的數據，它其實是代表了客戶端的一些敏感數據，比如銀行卡號，手機號，密碼，cvv，有效期等。特別對比密碼和cvv這樣的強敏感數據，為了提高應用程序的性能和防止別人的破解。

我們采用了RSA和AES兩套加密方式對這些數據進行加密，如下圖：

  首先我們會生成x位的隨機秘鑰，要加密的數據data用該隨機秘鑰去加密，最後將秘鑰進行Base64編碼，此時的數據才是我們要上傳到服務器的敏感數據，大家都知道AES是一個對稱加密算法，服務端必須知道秘鑰才能解密。

  但是我們的秘鑰是一個隨機的，服務端是怎麼知道的呢，如上圖所示，我們將這個隨機秘鑰進行了RSA公鑰加密，加密後的數據也進行了一下Base64編碼，並上傳到了服務器，因為服務器有RSA的私鑰，所以服務端就可以拿到AES加密的那個隨機秘鑰了。

  由於我們AES每次都是通過隨機秘鑰去加密，並沒有一個固定的秘鑰，所以AES的加密是安全的，另外因為RSA是非對稱加密，我們的so只存儲了RSA的公鑰，所以也是安全的。<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPiZlbXNwOyZlbXNwO9fc1q6jrNa70qq3/s7xtsvLvdS/srvQucK2vs2/ydLUsaPWpMr9vt21xLCyyKvQ1KGjPC9wPg0KPGJsb2NrcXVvdGU+DQoJPHA+yv2+3bK7udzKx7SryuS7ucrHtOa0ora80OjSqrzTw9yjrLzTw9zL47eosru9odezu+HI3dLXsbvGxr3iu/LV38SjxOKjrMyrvaHXs7W81sLNqNG2t/7O8cb3s8Wyu9ehuN+yoreius2438H3wb+jrMv50tS8073iw9zL47eotcTRocih0rK63NbY0qqho87Sw8fV4sDvy7Ox473iys3Pws7Sw8e21LzTw9zL47eotcTRocihv7zCx6GjPC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+JmVtc3A7JmVtc3A7zqrKssO0ssnTw1JTQbzTw9zE2KO/0vLOqlJTQcrHt8e21LPGvNPD3KOsv827p7bL1rvEw7W9wcu5q9S/o6zL/Na7xNzTw8C0vNPD3KOstavKx8O7t6jTw8C0veLD3KOs1eLR+b7Nv8nS1LGj1qTK/b7dtcSwssiro6zS8s6qw7vT0Mu91L/Kx8O7t6i94sPctcShozwvcD4NCjxwcmUgY2xhc3M9"brush:java;"> 為什麼不都用RSA加密？既然RSA加密這樣安全，為什麼不都用RSA加密的，因為RSA加密也是有一些弊端： － RSA的加解密對性能開銷很大，所以不建議大量使用，以增加服務端壓力； － RSA對加密的數據長度有限制，具體長度是與RSA秘鑰位數有關系，所以對於比較長的數據RSA沒法加密。 不管RSA加密還是AES加密都進行了一下Base64編碼，這個是需要注意的地方，因為RSA和AES加密出來的都是二進制流，在轉化成字符串時候可能出現空格造成數據的截斷，所以必須編碼一下不要讓它出現空格。

應用加固

    應用加固包括病毒掃描模塊，防注入，防調試，防篡改模塊四個模塊，目前行業內已經出現了很多的應用加入解決方案，入愛加密、梆梆加密、百度加密、360應用加固等等。

病毒掃描模塊

    病毒掃描模塊和目前市面大多的安全衛士類app一樣，摒棄了傳統的依賴本地病毒庫的殺毒引擎，采用了百度手機衛士的雲掃描殺毒引擎。雲掃描殺毒引擎在雲端有一個定期更新的病毒庫，掃描主要是通過收集本地安裝的 App的信息，通常是apk裡包名、簽名、so、dex等信息，上傳到雲端,　雲端通過比較程序簽名和病毒庫中的簽名判斷是否為病毒，然後將掃描結果返回給本地。　
    現在有些病毒掃描還結合人工智能深度學習利用服務器端的病毒數據庫進一步查詢可疑程序。還有些掃描作了一些主動防御，通過監控敏感api進行防御，例如監控以下敏感操作：更改浏覽器主頁，注冊開機啟動的行為，應用程序的內存注入等。　

反調試模塊

調試指當前 app被其他程序使用特定方法（調試器、 ptrace等）跟蹤劫持，被調試後的app的一切行為都可以被其他程序查看和修改, 大家可以聯想下平時通過gdb調試程序。

反調試功能分兩個步驟：首先檢測當前 app是否正在被調試。如果 app正在被調試，則返回調試器所在進程的進程名。 如果 app沒有被調試，則保護該 app不再被其他程序調試。

保護app不被調試的方法有兩種：

一個是內核裡有一個調試的debug選項關掉，但是作為app我們沒辦法改內核態的東西。 另外一個是雙進程實現反調試。

我們知道一個進程只允許有一個調試器，所以在進程起來的同時，會fork
一個daemon(守護進程)，並ptrace被保護的app進程，守護進程會攔截調試器的入口，保證其他程序無法再調試當前app。守護進程一旦激活，就會一直存在，直到當前應用退出,
如果強行關閉守護進程，當前 App也會隨之關閉。這裡要注意信號的處理。

反注入模塊

注入是指當前 App進程被其他程序使用特定方法(ptrace、 dlopen等)插入不屬於當前 App的模塊。一般來講，注入不是目的，只是手段，所以注入後的模塊一般都具有特殊行為，如收集 App的隱私數據，使用 Hook等方法劫持 App的正常運行流程等。其中 Hook是最主要的安全風險。

從技術手段來講，注入的前提是需要調試的。所以如果當前 App已經被保護為不可被調試，那麼理論上就不存在被注入的風險。但是，如果反調試模塊激活得較晚，那麼在激活之前， App還是存在被注入的可能。反注入功能就是檢測出當前 App被哪些模塊注入和劫持(Hook)了。

Android平台中 hook的方法分為兩大類： Java Hook和 So Hook. 其中 Java Hook分為靜態成員
Hook和函數 hook，可以通過檢查vm dex 內存的fields域和method域來判斷是否有java注入。So Hook
也是所有linux系統的hook方式，分為 GOT Hook、 Symbol Hook和 Inline Hook. Inline
Hook一般是通過匯編注入的方式， Symbol
Hook一般是采用LD_PRELOAD的方式給函數加hook，這兩種注入目前都不太能防，主要防的還是GOT hook.
筆者就曾經在若干年前通過GOT hook原理在不刷機、沒有root權限的情況下，在系統裡植入了su程序，把系統給強行root了。GOT
Hook的原理是簡單說就是通過cat
/proc/pid/maps拿到app進程的so加載地址，然後通過分析GOT表拿到so裡各個函數的偏移地址，計算得出函數入口的絕對地址，然後把該地址得函數替換成注入函數。所以防native注入的方法是：通過app
進程空間，查看加載的庫是不是都在/system或/data/data/app底下，如果不是，則一定有注入。

反篡改模塊

傳統判斷 App是否盜版的方法，業界慣用做法是事先收集大量正版應用的信息做白名單，然後利用當前 App的包名、簽名等信息去做匹配。該方法的准確度依賴於白名單庫的大小，並且需要網絡連接。反篡改功能根據重新打包的 App和正版 App的dex的排列特征來判定 App是否被重新打包，速度快、精確度高。

Android安全編程

針對Android特有的一些語法和設計，也存在被攻擊的危險，通常我們代碼在正式發布前都會進行安全掃描，安全掃描最主要是掃面以下點：

日志信息的安全

這個比較簡單了，不允許打印敏感數據，再在發版前必須關閉打印日志的開關。

Intent 信息洩露

為了啟動另個一個應用程序的Activity，我們經常會使用一些隱式的Intent，如果裡面包含一些敏感信息，第三方app只要注冊相同的Intent Filter，就有可能截獲到敏感信息，所以發送隱式Intent，必須要指定接收方和權限。

安全組件的安全

Android 包括四大組件：Activitie、Service、Content Provider、Broadband Receiver，它們每一個都可以通過外面隱式的Intent方式打開，所以這些組件只要不是對外公開的必須在manifest裡面注明exported為false，禁止其他程序訪問我們的組件，對於要和外部交互的組件，應當添加一下訪問權限的控制，還需要要對傳遞的數據進行安全的校驗。

IPC空引用

這種情況主要出現在對外開放的組件中，因為對外開放的組件可以接收Intent，一般裡面會包含一些數據，當我們沒有對這些數據判空時候，app一般會crash，攻擊者可能發送數據為空的Intent來攻擊。

WebView漏洞攻防

js注入漏洞

這個問題最早是可以追溯到2011年的一篇paper《Attacks on WebView in the Android System》http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf ，這篇文章指出了addJavascriptInterface的方式在功能上帶來的一些風險，比如你的app裡實現了一個讀寫文件的類，然後使用addJavascriptInterface接口允許js調用，那麼就可能導致攻擊者直接調用這個class實現讀寫文件的操作。這種方式是最原始的風險，並沒有直接指出getClass()方法的利用。後來百度安全組在2013年也正式的發布這個漏洞的高危工單：http://security.baidu.com/risk/findNewsDetail.do;jsessionid=B09405787822801D67251543B2B8C5CB.security_client-web01?id=336。這個漏洞主要是通過getClass()的方法直接調用java. lang. Runtime接口執行系統命令，讓任何js具有app相同的操作權限！

解決辦法主要是兩個：

對於Android 4.2及其以上版本，google 已經fix該漏洞，只需要native
interface上增加@addJavaInterface標示即可。 對於Android4.2以前的版本，則需要重寫addJavaInterface，自己實現js調用和native調用的映射關系。這也是cordova的一個經典設計，值得學習一下。

WebView釣魚漏洞

釣魚這個事一直都安全界最常用的攻擊，也是最難通過技術手段解決的一類問題，而且釣魚的手段也是千奇百怪，要防釣魚除了讓用戶提高安全意識，不點擊來路不明的鏈接外，技術層面可以做到如下兩點：

檢查WebView加載目標URL是否存在釣魚欺騙等安全風險 對webview關閉腳本環境

WebView跨域漏洞

主要是由於 JS 的 XmlHttpRequest 可以讀取本地文件，從而讀取到app data 數據庫目錄下的webviewCookiesChromium.db, 這個db通常是系統存放cookie的地方，相當於變相的為讀取cookie開了權限，具體可以看一下烏雲的鏈接：烏雲鏈接

針對 Android 4.1 以及以上系統，本身不存在這個跨域漏洞，沒有針對性修改。 對所有版本都 setAllowFileAccess（false），禁止從本地 html 加載頁面。

其他

弱加密：
  很多Android應用的加密存儲方式都比較簡單，只是一個簡單的md5, 很容易被破解。

簽名校驗方向：
  每一個apk都會有個簽名，簽名只有這個開發者才擁有，如果別人修改了代碼，也必須要簽名才能運行，但是修改者的簽名與官方簽名是不一致的，我們在so裡面存儲了應用程序官方簽名的hashcode值，在應用啟動後so就會檢查簽名是不是官方的簽名，如果不是，應用程序直接關閉，so裡面的加密函數也都不起作用。