安卓應用程式滲透測試（十二）
前不久為大家介紹了安卓應用程式滲透測試checklist的第一部分，今天與大家分享第二部分。
M6—不安全的授權
為了測試設計存在問題的授權方案，測試員可以嘗試對移動app發起二進位制攻擊，在app處於離線模式下執行只有高階許可權使用者才能執行的功能，看看是否能成功。
測試員可以嘗試在向後端伺服器發起敏感功能的POST/GET請求中使用低許可權的session來執行高許可權的功能。
授權方案設計存在缺陷或者缺失，讓攻擊者能夠使用通過app身份驗證的低許可權使用者執行他們原本無權執行的功能。
手機有一個需求就是要保證離線時的可用性，所以授權通常是在移動裝置本地完成的，而不是通過遠端伺服器，如此一來，授權問題就更加容易遭受攻擊。
如果授權被繞過，依據所執行的高許可權的功能，可能會產生嚴重而廣泛的影響。例如，能夠執行遠端或本地管理員的許可權，那危害可就大了，可以直接破壞系統，當然，獲取敏感資訊也就不在話下了。
以下是一些檢查項及其描述：
M7—客戶端程式碼質量問題
客戶端程式碼注入導致可以通過手機app在移動裝置上執行惡意程式碼。
查詢app是否存在注入最好的方法是檢查輸入源，檢查使用者輸入是否進行了輸入驗證，是否做了防程式碼注入。檢查原始碼是檢視app是否正確處理資料最快最準確的方式。
另請閱讀： ofollow,noindex">最重要的安卓安全滲透測試工具清單
程式碼審計工具可以幫助安全分析師使用直譯器的方法並通過應用程式追蹤資料流。手工測試人員也可以通過精心構造exp來發現漏洞。
由於手機app中的資料來源有很多，所以列舉出它們的目的十分重要。總的來說，移動裝置上的程式碼注入攻擊包括下面幾種：
裝置上的資料：
SQL%E6%B3%A8%E5%85%A5/">SQL注入：
SQlite容易遭受注入攻擊，就跟web應用一樣。SQlite是很多手機中的預設儲存機制。如果你的應用中包含多個使用者或付費的內容時，通過SQL注入漏洞是可以檢視到所有使用者資料的，威脅非常之大。
本地檔案包含(LFI)：
移動裝置上的檔案處理也會導致資料洩露，不過它只能讀取你的應用程式目錄中能夠檢視的檔案。
手機使用者會話：
JavaScript注入(比如XSS)。手機瀏覽器也會有JavaScript注入漏洞。通常情況下，手機瀏覽器可以訪問手機app的cookies，這可能會導致會話竊取。
應用程式介面和函式：
一些應用程式介面和語言函式能夠接受資料，並且可以進行模糊測試導致程式崩潰。由於手機平臺的程式碼是進行託管的，所以這些漏洞一般不會造成溢位，但是有幾個漏洞已經被用作exp來攻擊經過root和越獄過的裝置。
二進位制程式碼：
手機惡意軟體或其他惡意軟體能夠執行鍼對錶示層(HTML，JavaScript，CSS)的二進位制攻擊，或者是對手機app可執行檔案底層的二進位制檔案進行攻擊。這些程式碼注入是在執行時通過手機app的框架或者二進位制檔案本身來執行的。
下表是一些檢查項及其描述：
M8—程式碼篡改
篡改檢測是手機app中使用的一種預防措施，有些第三方會未經過你的同意就重新編譯程式碼並在他們的商店中釋出app，而程式碼篡改檢測措施就是防止他們這種行為的。
檢測安卓app程式碼篡改和降低風險，需要做到以下兩點：
·檢查app是否重新命名
· 檢查app是否未經過你的同意進行釋出
M9—逆向
要從原始碼對apk檔案進行逆向，你需要執行下面幾點：
· 分離apk檔案
· 提取java類
· 反編譯java原始碼
· 檢查APK內容
M10—額外的功能
這類漏洞主要是關於會話處理，很多的會話處理方法並不安全。會話處理不恰當導致的結果跟糟糕的身份驗證結果一樣。一旦認證成功並且得到了一個session，這個session就允許你訪問移動app。移動app程式碼必須非常小心的保護使用者的會話，就像身份驗證機制一樣。
以下是幾個會話處理不當的例子：
· 後端沒有及時終止會話
· 缺乏足夠的超時保護
· 沒有正確重置cookies
· 不安全的token生成
後端沒有及時終止會話
很多開發者並沒有在伺服器端終止會話，而是在手機app中進行終止。這就給攻擊者打開了攻擊的大門，他們可以使用HTTP控制工具來發起攻擊。確保所有的會話終止事件都是在伺服器端執行的，而不僅僅是在手機app中。
缺乏足夠的超時保護
你開發的任何手機app在後臺元件中都必須有足夠的超時保護。這能夠防止圖謀不軌的未授權使用者獲取當前會話並偽裝成那個使用者進行訪問。
根據應用程式的敏感程度和風險程度，合理的超時保護時間也各不相同，可以參考下面的超時保護時間：
· 安全性高的應用程式設定為15分鐘
· 安全性中等的應用程式設定為30分鐘
· 安全性較低的應用程式設定為1小時
隨著使用者與手機app互動越來越頻繁，移動app的會話超時也變得越來越長。通常，使用者在使用手機app時，同時也會做很多其他事情。
與傳統的web應用相比，人們與移動app的互動往往是斷斷續續的，不可預測的，且持續的時間更長。從某種程度上來說，由於互動時間的間隔變長了，所以會話超時時間更長也就合情合理了。
然而，如果會話處理不當的話，隨著超時時間的加長，風險也會隨之增加。不過這種風險的提升也會讓人們意識到問題的存在，從而採取措施來確保會話得到正確的處理。
無法正確重置Cookies
會話管理的另一個問題是當身份驗證狀態發生改變時，無法正確的重置cookies。身份驗證狀態改變包括以下這些事件：
· 從匿名使用者切換到登陸使用者
· 從任何登陸使用者切換到另一個登陸使用者
· 從普通使用者切換到特權使用者
· 會話超時
對於這些事件來說，在伺服器端終止會話而且不再接受前一個會話的cookies是至關重要的。最理想的情況是，你的應用程式能夠檢測到前面提到的任何cookies的使用，並將其報告給相應的安全團隊。
不安全的令牌生成
除了在關鍵應用程式事件期間從伺服器端終止tokens之外，還必須正確的生成令牌。跟加密演算法一樣，開發者應該使用體系成熟而且是行業標準的方法來生成tokens。tokens必須要足夠長，足夠複雜，且具有偽隨機性，這樣才不會被輕易猜測到。
以下是一些檢查項及其對應的描述：
