溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“ZipperDown漏洞怎么處理”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
防守的第二條策略是：要搭建防線。搭建防線，換句話說就是：沒有銀彈，沒有什么單一的防御點可以從整體上保證我們的 App 的安全。以本地存儲為例，從 iOS 8.4 之后，沒法導出單個應用的存儲在設備上的文件，那我們還用不用對 App 存儲到本地的數據進行加密？對于我們公司的產品，我們是要求加密的，原因是：如果不加密，我們就依賴于 Bundle 不可導出這個安全特性，但是 Bundle 真的不可導出嗎？！有沒有辦法繞過？實際上是有辦法繞過的，我們還可以通過備份手機進而獲得應用的數據。所以，如果做了本地數據加密，可以將這個理解為增加了一條防線，那應用就可以抵御后一種攻擊方式。
防守的第三條策略是：要持續的、牢牢的抓住主要“矛盾”。對于 iOS 應用而言，我們認為主要矛盾是：遠程代碼執行。遠程代碼執行的前提是攻擊者可以遠程的將攻擊 Payload 投放到 iOS 應用中。對于投遞惡意 Payload，首先想到的方式是中間人攻擊（MitM）。為了避免 MitM，我們要求 App 與服務器的通信使用 HTTPS，并且需要正確的校驗證書，這問題我們一直在抓，因為控制住了 HTTPS 就可以大大的降低程序的遠程攻擊面。在 HTTPS 之后，我們會重點關注用戶可以產生內容的 App，這樣又可以將攻擊面降低。
防守的第四條策略是：盡量避免因為業務功能而將安全降維。這里的典型例子就是腳本能力（或者說熱補能力），前面我們提過 iOS 平臺的一個重要安全特性就是代碼簽名，由于代碼簽名特性、地址隨機化特性、iOS App 通信特點（由 App 通過 HTTP 的方式請求 Server 上的數據），遠程的在 iOS App 上獲得穩定的任意代碼執行是非常困難的。而腳本能力恰恰破壞了系統中基本的、重要的代碼簽名安全特性，可以幫助攻擊者獲得穩定的遠程代碼執行能力，從而將 App 的防御能力降維。前面有點零散的談了我們對 iOS App 防守的理解以及防守的一些基本策略，下面我們以具體功能點為維度談談如何做防守。
移動應用程序中通常會使用 SQLite 數據庫來存儲應用數據，而數據庫本身一般存儲在沙盒文件中。盡管在 iOS 8.4 之后，已經無法訪問沙盒里面的用戶數據，但是在 8.4 以前的設備或者是越獄設備上，數據庫文件可以輕易地通過助手類工具導出。如果數據庫里面存儲的數據沒有進行復雜的加密處理，會是應用程序有敏感信息泄漏的風險，同時也有助于攻擊者進行逆向分析。
使用較復雜的加密加鹽算法對敏感數據加密后存儲。
保存用戶信息和屬性的一個非常普通方法就是使用 NSUserDefaults。保存在 NSUserDefaults 中的信息在應用關閉后再次打開依然存在。加之 NSUserDefaults 的使用接口非常方便，導致開發人員有可能不加以區別的把數據存放到 NSUserDefautls 中。事實上保存到 NSUserDefautls 中的數據是沒有加密的，可以很輕易地從沙盒中找到。NSUserDefautls 被存儲在一個以應用 Bundle ID 為名稱的 Plist 文件中。
重要的敏感數據存儲在 Keychain 中。
iOS 設備中的 Keychain 是一個安全的存儲容器，可以用來為不同的應用保存敏感信息比如用戶名、密碼、網絡密碼、認證令牌。蘋果用 Keychain 來保存 Wi-Fi 網絡密碼、VPN 憑證等等。它是一個 SQLite 數據庫，位于 /private/var/Keychains/keychain-2.db，其保存的所有數據都是加密過的。Keychain 在沙盒之外 App 會將部分重要數據存放在 Keychain 中使用進行讀取，但若寫入后未清楚就卸載 App 而下一位用戶安全 App 時未清除數據，則可能到導致下次安全的時候直接從 Keychain 中讀取密碼登陸或手勢密碼無法解除等問題。
首次安裝應用程序啟動后，進行刪除 Keychain 數據操作。 后臺快照
iOS 系統在程序退出的時候，會保存程序當前的快照到/Library/Caches/snapshots 中，如果退出的時候頁面含有密碼等關鍵信息未進行處理則會導致安全隱患。
UIApplication 的委托方法 applicationDidEnterBackground: 可用于響應 App 進入后臺并且修改敏感數據顯示。例如，在進入后臺的時候，把特殊字符用“hidder”屬性隱藏。
Cookie 是 App 或者網站為了辨別用戶身份，進行 Session 跟蹤而存儲在用戶本地終端上的數據。如果 Cookie 以明文的形式存儲，那是非常危險的。iOS 上的 Cookie 數據會被保存在 /Library/Cookies/Cookies.binarycookies 中。在越獄設備或者iOS 8.4版本之前的設備上，這個數據是可以被導出并且通過工具 Dump 數據出來的。
1. Cookie 存放前進行較復雜的加密運算。 2. 將一部分 Cookie 加密存放在 Keychain 中，增加逆向難度。
在 iOS 應用程序中，使用 HTTPS 進行通信是一種更為安全的做法，也是官方所推薦的做法。但是即使使用了 HTTPS，也有可能因為沒有校驗服務器證書的原因導致被中間人劫持。如果交互請求數據處理不當，攻擊者可以解密得到明文通信數據；甚至進一步偽造 App 的請求，這是極大的安全隱患。
1. App 內要對 HTTPS 證書做校驗。 2. 避免使用有漏洞的第三網網絡庫(如 AFNetworking < 2.5.3 版本)。 3. 關鍵數據(如登錄密碼、卡號、交易密碼等)單獨加密。
在 iOS 應用程序中，WebView 是經常使用到的一個控件，用來加載網頁顯示在終端上，因跨平臺、動態等特性被廣泛使用。但是與此同時，很多桌面瀏覽器前端漏洞在 iOS 終端上仍然存在。同時因為 iOS 終端上， WebView 可以注冊一些敏感信息數據，比如發短信、付款、定位信息等等，也帶來了一些新的安全風險。
1. 對輸入進行過濾和編碼； 2. 服務端對 App 發送的數據進行過濾和編碼； 3. 盡量減少敏感接口的注冊、盡量不要加載第三方內容；如果加載，則必須在 WebView 的 Delegate 方法中，通過白名單機制實現對調用者的檢驗。
在 iOS 應用程序中，經常存在敏感數據需要加密存儲的場景。例如登陸密碼、通訊錄數據等，其加密算法被破解是相當危險的。一旦重要的算法被攻擊者逆向，應用的一切數據就相當于毫無保留的展現在攻擊者面前。
1. 對稱加密算法要使用 AES、DES 或 3DES，避免使用 RC4 等目前可能被爆破的算法；2. 對于數據安全性要求較高的場景并且條件允許的情況下，使用非對稱加密算法如 RSA 等；3. 對稱加密算法的 KEY 和 IV，應避免硬編碼。若加密數據僅是本地存儲，可基于設備相關的信息來生成 KEY 和 IV。
開發人員可能會從非官方渠道下載開發環境或者開發工具。被修改過的惡意開發工具可能會在打包 IPA 文件時，插入惡意代碼。另外，由于配置不當，打包 IPA 文件時，可能會把源碼或者開發文檔打包進入 IPA。
1. 從官方下載開發工具 Xcode; 2. 打包 IPA 文件時，管理好 Xcode 的 Build Phases、Copy Bundle Resources。
開發過程中通常會使用 NSLog 來輸出日志，用于調試 Bug 和測試功能。因此在打印出來的 Log 中很容易會泄漏程序的關鍵邏輯和用戶敏感數據，降低了逆向破解的難度，增加了敏感信息泄漏的風險。如果 Release 包里面沒有關閉系統日志，通過 Xcode Device 等工具，可以很容易地看到應用程序 Log 的打印。
1. 使用宏來控制測試版和發布版本的日志輸出； 2. 安全測試和對外發布時使用 Release 版本，關閉日志輸出。
“ZipperDown漏洞怎么處理”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
