一、安裝包測試
1.1 關於反編譯
目的是爲了保護公司的知識產權和安全方面的考慮等，一些程序開發人員會在源碼中硬編碼一些敏感信息，如密碼。而且若程序內部一些設計欠佳的邏輯，也可能隱含漏洞，一旦源碼泄漏，安全隱患巨大。
爲了避免這些問題，除了代碼審覈外，通常開發的做法是對代碼進行混淆，混淆後源代碼通過反軟件生成的源代碼是很難讀懂的，測試中，我們可以直接使用反編譯工具（dex2jar和jd-gui工具）查看源代碼，判斷是否進行了代碼混淆，包括顯而易見的敏感信息。
1.2 關於簽名
這點IOS可以不用考慮，因爲APP stroe都會校驗。但Android沒有此類權威檢查，我們要在發佈前校驗一下簽名使用的key是否正確，以防被惡意第三方應用覆蓋安裝等。可使用下列命令檢查，若結果爲“jar 已驗證”，說明簽名校驗成功。
jarsigner -verify -verbose -certs apk包路徑
1.3 完整性校驗
爲確保安裝包不會在測試完成到最終交付過程中因爲知足者趾問題發生文件損壞，需要對安裝包進行完整性校驗，通常做法是檢查文件的md5值，而且一般可以通過自動化做校驗。
1.4 權限設置檢查
一般用戶對自己的隱私問題十 分敏感，因此，我們需要對APP申請某些特定權限的必要性進行檢查，如訪問通訊錄等。對於沒有必要的權限，一般都建議開發 直接支除。
Android：直接檢查manifest文件來讀取應用所需要的全部權限，並結合需求進行校驗此權限是否爲必須的。manifest文件的修改也需要關注，在增加新權限前需要進行評估。
IOS：沒有類似manifest文件來查看，IOS的用戶權限只有在用戶使用APP到了需要使用的權限時，系統纔會彈出提示框，提示用戶當前APP需要訪問照片、聯繫人列表等組件。我們可以掃描代碼來查看項目工程中有哪些權限設置。通過搜索關鍵類名，如通訊錄一般需要訪問ABAddressBookRef，照片是UIImagePickerController等。如果是純黑盒測試，則必須覆蓋到所有代碼路徑才能保證沒有遺漏，也可使用代碼覆蓋率測試判斷是否覆蓋。
二、敏感信息測試
數據庫是否存儲敏感信息，某些應用會把cookie類數據保存在數據庫中，一旦此數據被他人獲取，可能造成用戶賬戶被盜用等嚴重問題，測試中在跑完一個包含數據庫操作的測試用例後，我們可以直接查看數據庫裏的數據，觀察是否有敏感信息存儲在內。一般來說這些敏感信息需要用戶進行註銷操作後刪除。如果是cookie類數據，建議設置合理的過期時間。
日誌是否存在敏感信息，一般開發在寫程序的過程中會加入日誌幫助高度，所有可能會寫入一些敏感信息，通常APP的發佈版不會使用日誌，但也不排除特殊情況。
配置文件是否存在敏感信息，與日誌類似，我們需要檢查配置文件中是否包含敏感信息。
三、軟鍵盤劫持
如果用戶安裝了第三方鍵盤，可能存在劫持情況，對此，我們在一些特別敏感的輸入地方可以做檢查，例如金融類APP登錄界面的用戶名密碼輸入框等，看是否支持第三方輸入法，一般建議使用應用內的軟鍵盤。
四、賬戶安全
4.1 密碼是否明文存儲在後臺數據庫
在評審和測試中需要關注密碼的存儲。
4.2 密碼傳輸是否加密
測試中我們需要查看密碼是否被 明文傳輸，如果是HTTP接口，我們可以使用FIddler等工具直接查看。
4.3 賬戶鎖定策略。
對於用戶輸入錯誤密碼次數過多的情況，是否會將賬戶臨時鎖定，避免被暴力破解。
4.4 同時會話情況。
一些應用對同時會話會有通知功能，這樣至少可以讓用戶知識他的賬戶可能已經被泄漏了。在一定程度上能免提升用戶體驗。
4.5 註銷機制。
在客戶端註銷後，我們需要驗證任何的來自該用戶的，需要身份驗證的接口調用都不能成功。
五、數據通信安全
5.1 關鍵數據是否散列或加密。
密碼在傳輸中必須是加密的，其他敏感信息傳輸前也需要進行散列或者加加密，以免被中間節點獲取並惡意利用。
5.2 關鍵連接是否使用安全通信，例如HTTPS。
在獲知接口設計後我們需要評估是否其中內容包含敏感信息，如果未使用安全通信，需要知會開發修改。
5.3 是否對數字證書合法性進行驗證。
即便使用了安全通信，例如HTTPS，我們也需要在客戶端代碼中對服務端證書進行合法性校驗。測試中可以使用Fiddler工具 模擬中間人攻擊方法。如果客戶端對於Fiddler證書沒有校驗而能正常調用，則存在安全隱患。
5.4 是否校驗數據合法性。
在一些情況下，我們需要有方法來確保服務端下發的明文數據不被篡改。通常開發側的實現方式是對數據進行數字簽名並在 客戶端進行校驗。我們可以模擬後臺返回進行相關的測試工作。此外，對於其他一些客戶端未進行數據校驗的接口，我們也 需要有意識地思考如果不進行校驗是否會產生問題，並通過模擬後臺返回驗證。
六、組件安全測試
這裏主要是指Android平臺各個組件是否能被 外部應用惡意調用從而帶來一些安全問題。包括Activity、Service、ContentProvider、Broadcast等等。採用的測試方法是通過使用drozer工具結合查看代碼的方式。
七、服務端接口測試
主要關注服務端接口是否存在以下問題
7.1 SQL注入
7.2 XSS跨站腳本攻擊
7.3 CSRF跨站請求僞造
7.4 越權訪問
除了上述服務端問題外，我們還需要結合實際的需求，設計和代碼，分析是否需求或設計本身就會帶來安全問題。
舉個例子：如一個購物的應用，下單地的流程包含兩個接口，接口A返回訂單詳情，其中包括訂單號碼和金額總價。調用接口A後用戶在客戶端看到一個訂單頁面。用戶點擊提交後調用接口B，客戶端傳給接口B的參數爲接口A返回的訂單號碼和金額總價，接口B的後臺根據傳給接口B的金額總價從用戶賬戶中扣款，扣款成功後即根據訂單號碼發貨。
這一設計有什麼問題呢？那就是接口B完全信任了客戶端傳入的金額總價而未做校驗。惡意用戶可以直接調用接口B，傳入僞造的金額和真實訂單號，這樣就能以便宜的價格購物。
八、附錄
1.軟件權限
1）扣費風險：包括短信、撥打電話、連接網絡等。
2）隱私泄露風險：包括訪問手機信息、訪問聯繫人信息等。
3）對App的輸入有效性校驗、認證、授權、數據加密等方面進行檢測
4）限制/允許使用手機功能接入互聯網
5）限制/允許使用手機發送接收信息功能
6）限制或使用本地連接
7）限制/允許使用手機拍照或錄音
8）限制/允許使用手機讀取用戶數據
9）限制/允許使用手機寫入用戶數據
10）限制/允許應用程序來註冊自動啓動應用程序
2.數據安全性
1）當將密碼或其它的敏感數據輸入到應用程序時，其不會被存儲在設備中，同時密碼也不會被解碼。
2）輸入的密碼將不以明文形式進行顯示。
3）密碼、信用卡明細或其他的敏感數據將不被存儲在它們預輸入的位置上。
4）不同的應用程序的個人身份證或密碼長度必須至少在4-8個數字長度之間。
5）當應用程序處理信用卡明細或其它的敏感數據時，不以明文形式將數據寫到其他單獨的文件或者臨時文件中。以防止應 用程序異常終止而又沒有刪除它的臨時文件，文件可能遭受入侵者的襲擊，然後讀取這些數據信息。
6）敏感數據輸入到應用程序時，其不會被存儲在設備中。
7）應用程序應考慮或者虛擬機器產生的用戶提示信息或安全警告
8）應用程序不能忽略系統或者虛擬機器產生的用戶提示信息或安全警告，更不能在安全警告顯示前，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶。
9）在數據刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作。
10）應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況。
11）當進行讀或寫用戶信息操作時，應用程序將會向用戶發送一個操作錯誤的提示信息。
12）在沒有用戶明確許可的前提下不損壞刪除個人信息管理應用程序中的任何內容。
13）如果數據庫中重要的數據正要被重寫，應及時告知用戶。
14）能合理的處理出現的錯誤。
15）意外情況下應提示用戶。
3.通訊安全性
1）在運行軟件過程中，如果有來電、SMS、藍牙等通訊或充電時，是否能暫停程序，優先處理通信，並在處理完畢後能正常恢復軟件，繼續其原來的功能。
2）當創立連接時，應用程序能夠處理因爲網絡連接中斷，進而告訴用戶連接中斷的情況。
3）應能處理通訊延時或中斷。
4）應用程序將保持工作到通訊超時，進而給用戶一個錯誤信息指示有鏈接錯誤。
5）應能處理網絡異常和及時將異常情況通報用戶。
6）應用程序關閉網絡連接不再使用時應及時關閉，斷開。
4.人機接口安全測試
1）返回菜單應總保持可用。
2）命令有優先權順序。
3）聲音的設置不影響使用程序的功能。
4）應用程序必須能夠處理不可預知的用戶操作，例如錯誤的操作和同時按下多個鍵。