ZipperDown漏洞怎么處理

本篇內(nèi)容介紹了“ZipperDown漏洞怎么處理”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)公司主營(yíng)江陵網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,app軟件定制開發(fā),江陵h5重慶小程序開發(fā)搭建,江陵網(wǎng)站營(yíng)銷推廣歡迎江陵等地區(qū)企業(yè)咨詢

出發(fā)點(diǎn)與基本策略

我們談的主要是防守，談防守就要基于一定的信任基礎(chǔ)，如果什么都不可信，那也就沒法做防守了。再具體一點(diǎn)，我們現(xiàn)在談的是 iOS App 的防守，我們信任的基礎(chǔ)是 iOS，即：iOS 系統(tǒng)及服務(wù)是可信的，他們的安全性是完整的，沒有被破壞的。對(duì)于 iOS 應(yīng)用而言，操作系統(tǒng)提供的最基本、最重要的安全特性是：代碼簽名、沙盒。代碼簽名是指：iOS 上只能運(yùn)行由蘋果簽名的代碼。沙盒是一種限制程序行為的安全特性，其中包括對(duì)程序可以訪問的文件的限制，如：App1 無法訪問 App2 存儲(chǔ)的數(shù)據(jù)文件。除了代碼簽名與沙盒，iOS 上還有其它的一些安全特性或者安全功能，比如：Keychain、用戶數(shù)據(jù)加密等。我們做防守時(shí)一定要充分利用現(xiàn)有的安全功能與安全特性，換句話說就是：充分利用蘋果提供的資源，這樣可以大大降低我們的防守成本，這就是第一條防守策略：盡量基于現(xiàn)有的防御陣地來搭建我們自己的防線。

防守的第二條策略是：要搭建防線。搭建防線，換句話說就是：沒有銀彈，沒有什么單一的防御點(diǎn)可以從整體上保證我們的 App 的安全。以本地存儲(chǔ)為例，從 iOS 8.4 之后，沒法導(dǎo)出單個(gè)應(yīng)用的存儲(chǔ)在設(shè)備上的文件，那我們還用不用對(duì) App 存儲(chǔ)到本地的數(shù)據(jù)進(jìn)行加密？對(duì)于我們公司的產(chǎn)品，我們是要求加密的，原因是：如果不加密，我們就依賴于 Bundle 不可導(dǎo)出這個(gè)安全特性，但是 Bundle 真的不可導(dǎo)出嗎？！有沒有辦法繞過？實(shí)際上是有辦法繞過的，我們還可以通過備份手機(jī)進(jìn)而獲得應(yīng)用的數(shù)據(jù)。所以，如果做了本地?cái)?shù)據(jù)加密，可以將這個(gè)理解為增加了一條防線，那應(yīng)用就可以抵御后一種攻擊方式。

防守的第三條策略是：要持續(xù)的、牢牢的抓住主要“矛盾”。對(duì)于 iOS 應(yīng)用而言，我們認(rèn)為主要矛盾是：遠(yuǎn)程代碼執(zhí)行。遠(yuǎn)程代碼執(zhí)行的前提是攻擊者可以遠(yuǎn)程的將攻擊 Payload 投放到 iOS 應(yīng)用中。對(duì)于投遞惡意 Payload，首先想到的方式是中間人攻擊（MitM）。為了避免 MitM，我們要求 App 與服務(wù)器的通信使用 HTTPS，并且需要正確的校驗(yàn)證書，這問題我們一直在抓，因?yàn)榭刂谱×?HTTPS 就可以大大的降低程序的遠(yuǎn)程攻擊面。在 HTTPS 之后，我們會(huì)重點(diǎn)關(guān)注用戶可以產(chǎn)生內(nèi)容的 App，這樣又可以將攻擊面降低。

防守的第四條策略是：盡量避免因?yàn)闃I(yè)務(wù)功能而將安全降維。這里的典型例子就是腳本能力（或者說熱補(bǔ)能力），前面我們提過 iOS 平臺(tái)的一個(gè)重要安全特性就是代碼簽名，由于代碼簽名特性、地址隨機(jī)化特性、iOS App 通信特點(diǎn)（由 App 通過 HTTP 的方式請(qǐng)求 Server 上的數(shù)據(jù)），遠(yuǎn)程的在 iOS App 上獲得穩(wěn)定的任意代碼執(zhí)行是非常困難的。而腳本能力恰恰破壞了系統(tǒng)中基本的、重要的代碼簽名安全特性，可以幫助攻擊者獲得穩(wěn)定的遠(yuǎn)程代碼執(zhí)行能力，從而將 App 的防御能力降維。前面有點(diǎn)零散的談了我們對(duì) iOS App 防守的理解以及防守的一些基本策略，下面我們以具體功能點(diǎn)為維度談?wù)勅绾巫龇朗亍?/p>

具體功能點(diǎn)的防守方法

數(shù)據(jù)庫文件安全

安全場(chǎng)景描述

移動(dòng)應(yīng)用程序中通常會(huì)使用 SQLite 數(shù)據(jù)庫來存儲(chǔ)應(yīng)用數(shù)據(jù)，而數(shù)據(jù)庫本身一般存儲(chǔ)在沙盒文件中。盡管在 iOS 8.4 之后，已經(jīng)無法訪問沙盒里面的用戶數(shù)據(jù)，但是在 8.4 以前的設(shè)備或者是越獄設(shè)備上，數(shù)據(jù)庫文件可以輕易地通過助手類工具導(dǎo)出。如果數(shù)據(jù)庫里面存儲(chǔ)的數(shù)據(jù)沒有進(jìn)行復(fù)雜的加密處理，會(huì)是應(yīng)用程序有敏感信息泄漏的風(fēng)險(xiǎn)，同時(shí)也有助于攻擊者進(jìn)行逆向分析。

安全加固實(shí)施建議

使用較復(fù)雜的加密加鹽算法對(duì)敏感數(shù)據(jù)加密后存儲(chǔ)。

NSUserDefaults 安全

安全場(chǎng)景描敘

保存用戶信息和屬性的一個(gè)非常普通方法就是使用 NSUserDefaults。保存在 NSUserDefaults 中的信息在應(yīng)用關(guān)閉后再次打開依然存在。加之 NSUserDefaults 的使用接口非常方便，導(dǎo)致開發(fā)人員有可能不加以區(qū)別的把數(shù)據(jù)存放到 NSUserDefautls 中。事實(shí)上保存到 NSUserDefautls 中的數(shù)據(jù)是沒有加密的，可以很輕易地從沙盒中找到。NSUserDefautls 被存儲(chǔ)在一個(gè)以應(yīng)用 Bundle ID 為名稱的 Plist 文件中。

安全加固實(shí)施建議

重要的敏感數(shù)據(jù)存儲(chǔ)在 Keychain 中。

Keychain 安全

安全場(chǎng)景描敘

iOS 設(shè)備中的 Keychain 是一個(gè)安全的存儲(chǔ)容器，可以用來為不同的應(yīng)用保存敏感信息比如用戶名、密碼、網(wǎng)絡(luò)密碼、認(rèn)證令牌。蘋果用 Keychain 來保存 Wi-Fi 網(wǎng)絡(luò)密碼、VPN 憑證等等。它是一個(gè) SQLite 數(shù)據(jù)庫，位于 /private/var/Keychains/keychain-2.db，其保存的所有數(shù)據(jù)都是加密過的。Keychain 在沙盒之外 App 會(huì)將部分重要數(shù)據(jù)存放在 Keychain 中使用進(jìn)行讀取，但若寫入后未清楚就卸載 App 而下一位用戶安全 App 時(shí)未清除數(shù)據(jù)，則可能到導(dǎo)致下次安全的時(shí)候直接從 Keychain 中讀取密碼登陸或手勢(shì)密碼無法解除等問題。

安全加固實(shí)施建議

首次安裝應(yīng)用程序啟動(dòng)后，進(jìn)行刪除 Keychain 數(shù)據(jù)操作。后臺(tái)快照

安全場(chǎng)景描敘

iOS 系統(tǒng)在程序退出的時(shí)候，會(huì)保存程序當(dāng)前的快照到/Library/Caches/snapshots 中，如果退出的時(shí)候頁面含有密碼等關(guān)鍵信息未進(jìn)行處理則會(huì)導(dǎo)致安全隱患。

安全加固實(shí)施建議

UIApplication 的委托方法 applicationDidEnterBackground: 可用于響應(yīng) App 進(jìn)入后臺(tái)并且修改敏感數(shù)據(jù)顯示。例如，在進(jìn)入后臺(tái)的時(shí)候，把特殊字符用“hidder”屬性隱藏。

Cookie 安全

安全場(chǎng)景描敘

Cookie 是 App 或者網(wǎng)站為了辨別用戶身份，進(jìn)行 Session 跟蹤而存儲(chǔ)在用戶本地終端上的數(shù)據(jù)。如果 Cookie 以明文的形式存儲(chǔ)，那是非常危險(xiǎn)的。iOS 上的 Cookie 數(shù)據(jù)會(huì)被保存在 /Library/Cookies/Cookies.binarycookies 中。在越獄設(shè)備或者iOS 8.4版本之前的設(shè)備上，這個(gè)數(shù)據(jù)是可以被導(dǎo)出并且通過工具 Dump 數(shù)據(jù)出來的。

安全加固實(shí)施建議

1. Cookie 存放前進(jìn)行較復(fù)雜的加密運(yùn)算。
2. 將一部分 Cookie 加密存放在 Keychain 中，增加逆向難度。

HTTPS 安全

安全場(chǎng)景描敘

在 iOS 應(yīng)用程序中，使用 HTTPS 進(jìn)行通信是一種更為安全的做法，也是官方所推薦的做法。但是即使使用了 HTTPS，也有可能因?yàn)闆]有校驗(yàn)服務(wù)器證書的原因?qū)е卤恢虚g人劫持。如果交互請(qǐng)求數(shù)據(jù)處理不當(dāng)，攻擊者可以解密得到明文通信數(shù)據(jù)；甚至進(jìn)一步偽造 App 的請(qǐng)求，這是極大的安全隱患。

安全加固實(shí)施建議

1. App 內(nèi)要對(duì) HTTPS 證書做校驗(yàn)。

2. 避免使用有漏洞的第三網(wǎng)網(wǎng)絡(luò)庫(如 AFNetworking < 2.5.3 版本)。

3. 關(guān)鍵數(shù)據(jù)(如登錄密碼、卡號(hào)、交易密碼等)單獨(dú)加密。

WebView 安全

安全場(chǎng)景描敘

在 iOS 應(yīng)用程序中，WebView 是經(jīng)常使用到的一個(gè)控件，用來加載網(wǎng)頁顯示在終端上，因跨平臺(tái)、動(dòng)態(tài)等特性被廣泛使用。但是與此同時(shí)，很多桌面瀏覽器前端漏洞在 iOS 終端上仍然存在。同時(shí)因?yàn)?iOS 終端上， WebView 可以注冊(cè)一些敏感信息數(shù)據(jù)，比如發(fā)短信、付款、定位信息等等，也帶來了一些新的安全風(fēng)險(xiǎn)。

安全加固實(shí)施建議

1. 對(duì)輸入進(jìn)行過濾和編碼；
2. 服務(wù)端對(duì) App 發(fā)送的數(shù)據(jù)進(jìn)行過濾和編碼；
3. 盡量減少敏感接口的注冊(cè)、盡量不要加載第三方內(nèi)容；如果加載，則必須在 WebView 的 Delegate 方法中，通過白名單機(jī)制實(shí)現(xiàn)對(duì)調(diào)用者的檢驗(yàn)。

加密算法

安全場(chǎng)景描敘

在 iOS 應(yīng)用程序中，經(jīng)常存在敏感數(shù)據(jù)需要加密存儲(chǔ)的場(chǎng)景。例如登陸密碼、通訊錄數(shù)據(jù)等，其加密算法被破解是相當(dāng)危險(xiǎn)的。一旦重要的算法被攻擊者逆向，應(yīng)用的一切數(shù)據(jù)就相當(dāng)于毫無保留的展現(xiàn)在攻擊者面前。

安全加固實(shí)施建議

1. 對(duì)稱加密算法要使用 AES、DES 或 3DES，避免使用 RC4 等目前可能被爆破的算法；2. 對(duì)于數(shù)據(jù)安全性要求較高的場(chǎng)景并且條件允許的情況下，使用非對(duì)稱加密算法如 RSA 等；3. 對(duì)稱加密算法的 KEY 和 IV，應(yīng)避免硬編碼。若加密數(shù)據(jù)僅是本地存儲(chǔ)，可基于設(shè)備相關(guān)的信息來生成 KEY 和 IV。

開發(fā)環(huán)境安全

安全場(chǎng)景描敘

開發(fā)人員可能會(huì)從非官方渠道下載開發(fā)環(huán)境或者開發(fā)工具。被修改過的惡意開發(fā)工具可能會(huì)在打包 IPA 文件時(shí)，插入惡意代碼。另外，由于配置不當(dāng)，打包 IPA 文件時(shí)，可能會(huì)把源碼或者開發(fā)文檔打包進(jìn)入 IPA。

安全加固實(shí)施建議

1. 從官方下載開發(fā)工具 Xcode;
2. 打包 IPA 文件時(shí)，管理好 Xcode 的 Build Phases、Copy Bundle Resources。

系統(tǒng)日志輸出安全

安全場(chǎng)景描敘

開發(fā)過程中通常會(huì)使用 NSLog 來輸出日志，用于調(diào)試 Bug 和測(cè)試功能。因此在打印出來的 Log 中很容易會(huì)泄漏程序的關(guān)鍵邏輯和用戶敏感數(shù)據(jù)，降低了逆向破解的難度，增加了敏感信息泄漏的風(fēng)險(xiǎn)。如果 Release 包里面沒有關(guān)閉系統(tǒng)日志，通過 Xcode Device 等工具，可以很容易地看到應(yīng)用程序 Log 的打印。

安全加固實(shí)施建議

1. 使用宏來控制測(cè)試版和發(fā)布版本的日志輸出；
2. 安全測(cè)試和對(duì)外發(fā)布時(shí)使用 Release 版本，關(guān)閉日志輸出。

“ZipperDown漏洞怎么處理”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

網(wǎng)站標(biāo)題：ZipperDown漏洞怎么處理
路徑分享：http://muchs.cn/article34/jpgcpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、做網(wǎng)站、關(guān)鍵詞優(yōu)化、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站收錄、網(wǎng)站維護(hù)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容