防止app的安全漏洞
防止app的安全漏洞
行動應用程式(app)的安全性已成為各企業重視的問題。雖然移動設備的安全性不會特別受到人們的重視，但是行動app的安全性漏洞已成為詐騙和企業侵害的主要原因，通常這些是公開的app可能是能夠與其中的客戶或合作夥伴進行互相合作的主要方法或唯一方法。由於它們可以在任何移動設備上執行，因此這些應用程式可以在攻擊者的控制下的惡劣環境中繼續運行。安全和風險管理(SRM)負責人必須保護行動應用程式，以向數位化轉型邁進。
1. 選擇正確的架構
在選擇架構之前，要先考慮到app是要發布於商業應用平台還是企業發行進行分發，對於面向消費者的app來說是很容易選擇的，但是對於面向員工和面向合作夥伴的app則不容易選擇。另外，部屬和實施安全也有多種選擇，例如透過UEM(統一端點管理)的應用程式管理和獨立的應用管理解決方案。
app開發中主要有三種的體系結構選項：原生架構、混合架構或web架構。在這三個類別中，添加新出現的PWA(漸進式網路應用程式)，每一個體系結構選擇會導致不同的安全性考量，並且在安全性和性能之間需要進行不同的考量。
2. 保護app
在確保app開發在網域中不變，但是移動應用程式會將軟體邏輯傳輸到移動設備上，這也表示需要特別加強某些應用程式的安全性。
3. 不要寫死憑證
app開發人員在開發過程中容易把app中的憑證寫死，因此為了app使用的服務提供身分驗證憑證，而不是讓用戶使用簡單的身分驗證和憑證去進行身分驗證。舉例來說，當API開發人員使用他們自己的身分驗證數據，應用程式與第三方交換資料時，攻擊者就可以從API竊取這些數據(特別是專屬憑證)任意使用，而該應用應改為透過API進行身分驗證，才能確保安全。
4. 避免給予app過多的權限
權限授權給app會增加許多風險，有些不需要權限的合法的app不僅會對隱私有合法規範，還會成為攻擊者的目標。在默認情況下，app不需要任何設備的權限。當需要執行特定功能時，應該要有選擇性地添加權限。由於大多數開發人員重複是用現有資料庫進行開發，因此他們的app最終要求的權限遠遠超出實際需要的權限。SRM負責人可以在測試過程中加入確保所使用的資料庫具有良好的品質，並且要求他們不要使用沒用到的權限的審查。
5. 保護重要數據
移動設備最常見的隱患是在沒有適當保護的情況下將重要訊息儲存在app中，攻擊者可以針對代碼進行反向竊取訊息，如果訪問憑證和加密密鑰必須留在設備上，則應將其安全的儲存，IOS和Android都提供憑據和重要數據的專用存儲位置，分別稱為蘋果iCloud鑰匙圈(keychain)和安卓密鑰儲存庫(Keystore)，另一種選擇是最小化駐留在設備上的敏感數據。但如上所述，透過評估客戶端到服務器傳輸性能影響來做決定。使用比密鑰存儲更複雜的替代方法是白盒機制，在討論哪些部分哪些是不需要用到。除了使用加密外，應該還能夠透過遠端命令刪除其數據，以彌補設備洩漏資料的風險。
6. 使用固定證書
由於app都是在移動各環境中使用，因此與web應用程式相比，app比較常連接到不安全的網路，固定證書是一種防止可能在此網路上發生的網路中間人攻擊的技術，有些瀏覽器可能不支援固定證書，這對混合開發app是一個很大的挑戰。
7. 確保開發週期
app安全性測試是生命週期的主要組成部分，在進行測試之前，為應用程式建立一個紀錄範圍，列出使用的權限，依資料的重要性做分級這方法非常有用的，例如該app是在商業應用程式商店上發布給消費者下載，還是在合法性的設備提供下載？這個決定會讓開發團隊確定要將花費多少時間來確保app和可以使用哪種額外保護。
8. 執行app安全性測試
app安全性測試是生命週期的主要組成部分，在進行測試之前，為應用程式建立一個紀錄範圍，列出使用的權限，依資料的重要性做分級是個非常有用的方法，例如該app是在商業應用程式商店上發布給消費者下載，還是在合法性的設備提供下載?這項決定會讓開發團隊確定要將花費多少時間來確保應用程式和可以使用哪種額外保護。另外必須執行風險模擬練習。
9. 外部安全控制
除非有了解安全內部知識的組織應避免建立和執行自己的安全控件。移動app識別的大多數安全問題都與密碼技術、身份驗證和其他安全功能都和錯誤執行有關。SRM負責人應該識別並標準化關鍵安全組件。查看現有的多經驗開發平台和訪問管理解決方案，以實現如完整性檢查、身份驗證、授權、標記化和加密等功能。使用Git環境還可以幫助建立和管理應用程序開發和部署過程
10.強化app防範反向工程
在應用程序中特別是在商業應用程式商店中發布的app經常是逆向工程的受害者。攻擊者對應用程序進行反向工程，以了解應用程序的工作方式後進行反擊，竊取app中的數據或是複製app。攻擊者之後再重新打包惡意程式進去，然後重新發布該app。意識不足的用戶可能會認為他們正在下載並使用合法app，導致用戶不小心交出他們的銀行憑證等重要數據。
11.混淆代碼
為了防止被app被重新包裝，SRM負責人可以混淆代碼使得代碼混亂(而不是指加密)，這可以讓審查和重新利用代碼變得更加困難。重新命名部分代碼或更改其順序到添加未使用的代碼和許多其他代碼，是其多種方式的其中的一種方式。另外提醒，混淆只是一種防範性措施。大多數的情況下，有決心的老練攻擊者能夠重新組成應用程式，不過付出的精力和時間可能不合效益。
12.白箱加密
白箱加密是用來隱藏和保護敏感應用程序數據(例如儲存在設備上的app的金鑰和憑據)的一種技術，當不想依賴本機資源時，可以將其用作代替方法。當為了提高採用率允許其應用程序在越獄設備上運行，而這些設備無法受益於IOS鑰匙圈保護的情況。在正常情況下，攻擊者嘗試攻擊設備上的憑據的第一個默認位置時，儘管憑證儲存在設備的IOS鑰匙圈保護裡，白箱將憑證移動到其他位置可避免遭受攻擊。
12.監控行動app
為了安全起見，加強app以防止逆向工程的替代方法或添加尋找應用程續的修改和複製版本。
建議
從開始選擇移動應用程序架構時(原生架構，混合架構或網頁app架構)，應該同時把安全性的權衡考量進去。實施app安全性最佳實踐，重點注意移動設備及其相關後端和可能的API的特性。特別是排除寫死的證書，縮減app的權限，加密重要數據並根據情況下使用固定證書，最後反覆行動app安全測試，並在此過程中通過ISV(獨立軟體供應商)的標準，多經驗開發平台和UEM(統一端點管理)功能使用的移動安全組件。除了有效的控制之外，針對高安全性應用程序透過強化和混淆代碼，以防範反向工程襲擊和竄改，例如靜態加密。
