手機App安全性測試初探

　　

　　

 　　目前手機App測試仍是以發現bug爲主，主要測試流程就是服務器接口測試，客戶端功能性覆蓋，以及自動化配合的性能，適配，壓測等，對於App安全性測試貌似沒有系統全面統一的標準和流程，其實安全性bug也能夠是bug的一種，只不過更加隱祕，難以發現，尤爲針對於手機App。近期時間比較充裕，研究了一下安全性相關的東西，並對於咱們自身的產品測試了一下(更主要的目的是遊戲做弊刷分)，發現了很多問題，總結一下。
　　個人理解，包括以webview爲主體的app，站在入侵或者攻擊的角度來說，安全隱患在於http抓包，逆向工程。談這以前先講講webview相關的app，前一段時間有個曝工資的軟件很火，但有查詢次數的限制，抓包研究了一下，發現其主要仍是webview，經過抓包詳細分析，才明白他記錄查詢次數的手段，每個用戶都會分配一個id，以及一個表明查詢次數count以cookie的形式保存到本地，經過維護cookie達到限制查詢次數的目的，因此清除cookie就能夠無限制的查詢了，我的以爲，webview相關的app安全性測試應該仍是web測試那一套，xss攻擊，sql注入等（沒搞過web安全測試，僅推測）。
　　大部分app仍是走的http或者https，因此防http抓包泄露用戶信息以及系統自身漏洞是必要的，畢竟像騰訊那種經過自身通訊協議增長安全性的仍是少數的（抓過微信和qq的沒抓着，不知道有沒有相關工具能夠抓手機tcp的包）。既然有接口測試爲何還須要單獨對客戶端進行抓包驗證安全性呢？這麼說吧，接口測試其實最主要的驗證接口邏輯，可用性，邊界值，異常檢查，但並不能預先保證客戶端調用不出問題，一個針對多個app抓包都發現的問題能夠說明：抓了好多社交性app，發現對於用戶資料隱私泄露仍是很嚴重的，當你查看一個陌生用戶信息時，一些手機號，qq等信息頁面上應該不顯示的，但這些信息不顯示並不表明服務器沒有下發，好多都是客戶端限制的，經過抓包，徹底能夠查看到陌生用戶的app。再如好多發帖，push消息的應用，若是沒有消息有效性的驗證，抓到包以後篡改消息，服務器一點反應都沒，這就會留有極大的隱患。
　　至於逆向工程這點，對於android就很好理解了，反編譯，修改或者插入本身的代碼，以達到相應目的。真見過幾個沒有代碼混淆的app，包括咱們本身的以及大名鼎鼎snapchat，記得有個遊戲特搞笑，遊戲主題是C#寫得，結果java的代碼混淆了，C#的代碼沒有，修改了幾個參數值，插了幾段本身的代碼，就做弊成功了。尤爲好多開放平臺的遊戲，經過開放平臺sdk文檔，再加上反編譯後些許信息，即便代碼混淆了，也能推測出好多東西。這些都是安全性隱患。
以上這些只是最近一段時間對於手機app安全性測試的一點認識，很膚淺，安全性測試對於測試人員素質要求仍是很高的，尤爲好多都是經驗性的東西，只有經過不斷增長經驗，才能更好的作好測試。