淺談Android開發中需要注意的安全問題
什麼是安全問題?
從黑客的角度定義,只要黑客能夠從app中找到一些方法獲取我們的原始碼根據某些明顯的欄位得到重要資訊從而修改程式以達到一定目的;竊取使用者資訊;竊取本地重要資訊間接可以修改使用者資訊的,都是安全問題。
安全的意義?
安全問題,在Web開發中很重要,同樣在安卓開發中,安全也很重要。安全就像空氣,看不見摸不著,一旦出現安全,沒有及時修復,對於公司將是致命的傷害。但是也有公司故意巧妙地利用安全漏洞做一些營銷,效果非常好,當然,這個是基於可控的基礎之上。
安全的分類
大的分類分兩種:
一、資料通訊安全
二、本地app程式安全
資料通訊安全又分兩類:
app與伺服器通訊安全和app本地資料通訊安全
資料通訊安全
app與伺服器通訊安全
與伺服器進行資料互動,資料肯定要加密。加密主要有對稱加密、非對稱加密,不可逆加密。從安全性考慮可選擇對稱加密AES加密方式。AES主要是用在資料本身的加密,即使傳輸過程中被截取了,也是加密過後的資料。但AES的弊端的是,客戶端加密的話,金鑰肯定是儲存在app中,如果app被成功破解了,資料也就被暴露了。所以只有app本身程式的安全也解決了,app才能相對安全。
非對稱加密最普遍的就是RSA加密,因為RSA加密有個長度限制,這就導致了RSA加密不能用於所有的資料互動。但是可以用到一些短資料,比如使用者個人資訊之類的,在交易中,一次訂單的資料也不是很大等。
不可逆加密,比如MD5加密、SHA加密等。所謂的不可逆加密就是,只能單向加密,不能反向解密。MD5把資料加密,最後得到固定長度的16進位制編碼。這個加密的作用一般是匹配驗證,驗證某個資料是否改變。比如密碼,在向伺服器儲存密碼,一般不會儲存明文密碼。安卓本地儲存個標誌也一般不會明文儲存。
在通訊上,有時並不一定對資料本身進行加密。比如可以使用令牌的方式,具體做法是:使用者登入成功後,伺服器生成一個訪問令牌給客戶端,此伺服器設定令牌的有效期。客戶端的所有請求都攜帶這個令牌去請求資料。當令牌時效的時候,客戶端使用者所有請求都請求不到,客戶端使用者退出登入狀態。令牌時效都是由伺服器來判斷,時效的方式:1、令牌過期。這個一般是使用者長期不登入,伺服器設定的過期時間已經到了。2、令牌錯誤,一搬是黑客拿未知令牌惡意請求資料3、令牌更換,一般是客戶端在另一臺裝置上登入重新獲取了最新令牌。另外,令牌也可以使使用者不用再次輸入密碼再次登入。
從安全方式來看,請求資料最好使用https進行請求。
app本地資料通訊安全
主要是指元件之間的通訊,廣播,某個圖片或者資料標記,攜帶的明顯關鍵字,有可能被反編譯之後smali中查到,比如sharedpreferces儲存的xml檔案資料
本地app程式安全
APK破解
程式開發中都會去混淆打包,但是對於逆向工程的高手來說,APK 包非常容易被反編譯成可讀檔案,稍加修改軟體邏輯或者插入惡意程式碼,替換廣告商 ID就能重新簽名打包成新的 APK。
建議應對方法:
使用 ProGuard、DexGuard 等工具混淆程式碼;是給程式加固,第三方加固工具都可以用。重要邏輯用 NDK 實現。.so庫相對來說很安全了。做三方庫的公司,大都把sdk重要的打成.so庫,我認為不光是因為Java不能夠完成而只能c++完成,還有保密安全這一措施。
資料的儲存
外部儲存(SD 卡)上的檔案沒有許可權管理,所有應用都可讀可寫。開發者把敏感資訊明文存在 SD 卡上,或者動態載入的 payload 放在 SD 卡上;sharedpreferces儲存的xml檔案資料,本地資料儲存是在手機的本地儲存data檔案下,雖然訪問需要系統許可權,但對於root的手機,這些在本地的資料很容易暴露出來。
建議應對方法
不建議全域性可讀寫的內部儲存方式,不要把敏感資訊放在外部儲存上面;在動態載入外部資源的時候驗證檔案完整性;一些重要資料(使用者賬號密碼等),或者標記儲存本地的時候也應該進行加密,或者直接儲存hash碼,而不能直接儲存明文。有些儲存本地的資料,比如令牌,就需要進行加密處理。登入成功後的重要資訊,如需要儲存本地,也需要加密。
元件暴露 (Activity, Service, Broadcast Receiver, Content Provider)
元件在被呼叫時或呼叫其他元件時未做驗證,通過呼叫獲取某些資訊,構造某些資料。(比如:呼叫暴露的元件發簡訊、微博等)。
建議應對方法
驗證輸入資訊、驗證元件呼叫等。android:exported 設定為 false。使用 android:protectionLevel="signature" 驗證呼叫來源。
如果是非常重要的組建,不要在這裡面進行配置,如果可以用fragment完成的,最好用fragment來做。並且重要的資訊不要在配置檔案裡面配置。
WebView
惡意 App 可以注入 JavaScript 程式碼進入 WebView 中的網頁,網頁未作驗證。惡意網頁可以執行 JavaScript 反過來呼叫 App 中註冊過的方法,或者使用資源。這些惡意程式嵌入 Web App,然後竊取使用者資訊,遠端呼叫 App 程式碼。更有甚者,通過 Java Reflection 呼叫 Runtime 執行任意程式碼。
建議應對方法
不使用 WebView 中的 setJavaScriptEnabled(true),或者使用時對輸入進行驗證。
總結
Android 應用的漏洞大部分都是因為開發人員沒有對輸入資訊做驗證造成的,另外因為 Intent 這種特殊的機制,需要過濾外部的各種惡意行為。再加上 Android 應用市場混亂,開發人員水平參差不齊。再加上 root 對於 App 沙箱的破壞,Android 升級的限制。如果想要保證你的應用沒有安全漏洞,就要記住:永遠不要相信外面的世界。
支援我的話可以關注下我的公眾號,每天都會推送新知識~
歡迎關注公眾號:Android技術大全