app 安全性測試概覽

標籤：情況   簽名   例子   sig   混淆   add   修改   登出   roi   

 

目錄

一、安裝包測試

1.1、關於反編譯

1.2、關於簽名

1.3、完整性校正

1.4、使用權限設定檢查

二、敏感資訊測試

三、軟鍵盤劫持

四、賬戶安全

五、資料通訊安全

六、組件安全性測試

七、服務端介面測試

一、安裝包測試

1.1、關於反編譯

目的是為了保護公司的智慧財產權和安全方面的考慮等，一些程式開發人員會在源碼中寫入程式碼一些敏感資訊，如密碼。而且若程式內部一些設計欠佳的邏輯，也可能隱含漏洞，一旦源碼泄漏，安全隱患巨大。

為了避免這些問題，除了代碼審核外，通常開發的做法是對代碼進行混淆，混淆後原始碼通過反軟體產生的原始碼是很難讀懂的，測試中，我們可以直接使用反編譯工具（dex2jar和jd-gui工具）查看原始碼，判斷是否進行了代碼混淆，包括顯而易見的敏感資訊。

1.2、關於簽名

這點IOS可以不用考慮，因為APP stroe都會校正。但Android沒有此類權威檢查，我們要在發布前校正一下籤名使用的key是否正確，以防被惡意第三方應用覆蓋安裝等。可使用下列命令檢查：

jarsigner -verify -verbose -certs apk包路徑

若結果為“jar 已驗證”，說明簽名校正成功。

1.3、完整性校正

為確保安裝包不會在測試完成到最終交付過程中因為知足者趾問題發生檔案損壞，需要對安裝包進行完整性校正，通常做法是檢查檔案的md5值，而且一般可以通過自動化做校正。

1.4、使用權限設定檢查

一般使用者對自己的隱私問題十 分敏感，因此，我們需要對APP申請某些特定許可權的必要性進行檢查，如訪問通訊錄等。對於沒有必要的許可權，一般都建議開發 直接支除。

Android：直接檢查manifest檔案來讀取應用所需要的全部許可權，並結合需求進行校正此許可權是否為必須的。manifest檔案的修改也需要關注，在增加新許可權前需要進行評估。

IOS：沒有類似manifest檔案來查看，IOS的使用者權限只有在使用者使用APP到了需要使用的許可權時，系統才會彈出提示框，提示使用者當前APP需要訪問照片、連絡人清單等組件。我們可以掃描碼來查看項目工程中有哪些使用權限設定。通過搜尋關鍵類名，如通訊錄一般需要訪問ABAddressBookRef，照片是UIImagePickerController等。如果是純黑箱測試，則必須覆蓋到所有代碼路徑才能保證沒有遺漏，也可使用程式碼涵蓋範圍測試判斷是否覆蓋。

二、敏感資訊測試

資料庫是否儲存敏感資訊，某些應用會把cookie類資料儲存在資料庫中，一旦此資料被他人擷取，可能造成使用者賬戶被盜用等嚴重問題，測試中在跑完一個包含資料庫操作的測試案例後，我們可以直接查看資料庫裡的資料，觀察是否有敏感資訊儲存在內。一般來說這些敏感資訊需要使用者進行登出操作後刪除。如果是cookie類資料，建議設定合理的到期時間。

日誌是否存在敏感資訊，一般開發在寫程式的過程中會加入日誌協助高度，所有可能會寫入一些敏感資訊，通常APP的發布版不會使用日誌，但也不排除特殊情況。

設定檔是否存在敏感資訊，與日誌類似，我們需要檢查設定檔中是否包含敏感資訊。

三、軟鍵盤劫持

如果使用者安裝了第三方鍵盤，可能存在劫持情況，對此，我們在一些特別敏感的輸入地方可以做檢查，例如金融類APP登入介面的使用者名稱密碼輸入框等，看是否支援第三方IME，一般建議使用應用內的軟鍵盤。

四、賬戶安全

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）應用程式必須能夠處理不可預知的使用者操作，例如錯誤的操作和同步選取多個鍵。

app 安全性測試概覽