亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

昨天傍晚盤古實驗室負責(zé)任的披露了針對 iOS 應(yīng)用的 ZipperDown 漏洞，并提供了檢索、查詢受影響應(yīng)用的平臺： zipperdown.org。基于目前公開的信息，該漏洞的影響面比較大，15000 多個應(yīng)用可能受此漏洞影響。 并且，結(jié)合應(yīng)用中的其它安全缺陷，可以在某些應(yīng)用上獲得遠程任意代碼執(zhí)行能力，即：遠程控制目標應(yīng)用，危害也較大。由于目前官方?jīng)]有公開 ZipperDown 的詳細信息，所以這里會跟大家分享、探討一下針對 iOS 應(yīng)用的防守策略以及針對具體功能點的防守方法。

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

我們談的主要是防守，談防守就要基于一定的信任基礎(chǔ)，如果什么都不可信，那也就沒法做防守了。再具體一點，我們現(xiàn)在談的是 iOS App 的防守，我們信任的基礎(chǔ)是 iOS，即：iOS 系統(tǒng)及服務(wù)是可信的，他們的安全性是完整的，沒有被破壞的。

對于 iOS 應(yīng)用而言，操作系統(tǒng)提供的最基本、最重要的安全特性是：代碼簽名、沙盒。代碼簽名是指：iOS 上只能運行由蘋果簽名的代碼。沙盒是一種限制程序行為的安全特性，其中包括對程序可以訪問的文件的限制，如：App1 無法訪問 App2 存儲的數(shù)據(jù)文件。

除了代碼簽名與沙盒，iOS 上還有其它的一些安全特性或者安全功能，比如：Keychain、用戶數(shù)據(jù)加密等。我們做防守時一定要充分利用現(xiàn)有的安全功能與安全特性，換句話說就是：充分利用蘋果提供的資源，這樣可以大大降低我們的防守成本，這就是第一條防守策略：盡量基于現(xiàn)有的防御陣地來搭建我們自己的防線。

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

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

防守的第四條策略是：盡量避免因為業(yè)務(wù)功能而將安全降維。這里的典型例子就是腳本能力（或者說熱補能力），前面我們提過 iOS 平臺的一個重要安全特性就是代碼簽名，由于代碼簽名特性、地址隨機化特性、iOS App 通信特點（由 App 通過 HTTP 的方式請求 Server 上的數(shù)據(jù)），遠程的在 iOS App 上獲得穩(wěn)定的任意代碼執(zhí)行是非常困難的。而腳本能力恰恰破壞了系統(tǒng)中基本的、重要的代碼簽名安全特性，可以幫助攻擊者獲得穩(wěn)定的遠程代碼執(zhí)行能力，從而將 App 的防御能力降維。

前面有點零散的談了我們對 iOS App 防守的理解以及防守的一些基本策略，下面我們以具體功能點為維度談?wù)勅绾巫龇朗亍?/p>

具體功能點的防守方法

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

安全場景描述

移動應(yīng)用程序中通常會使用 SQLite 數(shù)據(jù)庫來存儲應(yīng)用數(shù)據(jù)，而數(shù)據(jù)庫本身一般存儲在沙盒文件中。盡管在 iOS 8.4 之后，已經(jīng)無法訪問沙盒里面的用戶數(shù)據(jù)，但是在 8.4 以前的設(shè)備或者是越獄設(shè)備上，數(shù)據(jù)庫文件可以輕易地通過助手類工具導(dǎo)出。

如果數(shù)據(jù)庫里面存儲的數(shù)據(jù)沒有進行復(fù)雜的加密處理，會是應(yīng)用程序有敏感信息泄漏的風(fēng)險，同時也有助于攻擊者進行逆向分析。

安全加固實施建議

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

NSUserDefaults 安全

安全場景描敘

保存用戶信息和屬性的一個非常普通方法就是使用 NSUserDefaults。保存在 NSUserDefaults 中的信息在應(yīng)用關(guān)閉后再次打開依然存在。加之 NSUserDefaults 的使用接口非常方便，導(dǎo)致開發(fā)人員有可能不加以區(qū)別的把數(shù)據(jù)存放到 NSUserDefautls 中。

事實上保存到 NSUserDefautls 中的數(shù)據(jù)是沒有加密的，可以很輕易地從沙盒中找到。NSUserDefautls 被存儲在一個以應(yīng)用 Bundle ID 為名稱的 Plist 文件中。

安全加固實施建議

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

Keychain 安全

安全場景描敘

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

安全加固實施建議

首次安裝應(yīng)用程序啟動后，進行刪除 Keychain 數(shù)據(jù)操作。

后臺快照

安全場景描敘

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

安全加固實施建議

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

Cookie 安全

安全場景描敘

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

安全加固實施建議

1、Cookie 存放前進行較復(fù)雜的加密運算。

2、將一部分 Cookie 加密存放在 Keychain 中，增加逆向難度。

HTTPS 安全

安全場景描敘

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

安全加固實施建議

1、App 內(nèi)要對 HTTPS 證書做校驗。

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

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

WebView 安全

安全場景描敘

在 iOS 應(yīng)用程序中，WebView 是經(jīng)常使用到的一個控件，用來加載網(wǎng)頁顯示在終端上，因跨平臺、動態(tài)等特性被廣泛使用。但是與此同時，很多桌面瀏覽器前端漏洞在 iOS 終端上仍然存在。

同時因為 iOS 終端上， WebView 可以注冊一些敏感信息數(shù)據(jù)，比如發(fā)短信、付款、定位信息等等，也帶來了一些新的安全風(fēng)險。

安全加固實施建議

1、對輸入進行過濾和編碼。

2、服務(wù)端對 App 發(fā)送的數(shù)據(jù)進行過濾和編碼。

3、盡量減少敏感接口的注冊、盡量不要加載第三方內(nèi)容；如果加載，則必須在 WebView 的 Delegate 方法中，通過白名單機制實現(xiàn)對調(diào)用者的檢驗。

加密算法

安全場景描敘

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

安全加固實施建議

1、對稱加密算法要使用 AES、DES 或 3DES，避免使用 RC4 等目前可能被爆破的算法。

2、對于數(shù)據(jù)安全性要求較高的場景并且條件允許的情況下，使用非對稱加密算法如 RSA 等。

3、對稱加密算法的 KEY 和 IV，應(yīng)避免硬編碼。若加密數(shù)據(jù)僅是本地存儲，可基于設(shè)備相關(guān)的信息來生成 KEY 和 IV。

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

安全場景描敘

開發(fā)人員可能會從非官方渠道下載開發(fā)環(huán)境或者開發(fā)工具。被修改過的惡意開發(fā)工具可能會在打包 IPA 文件時，插入惡意代碼。

另外，由于配置不當，打包 IPA 文件時，可能會把源碼或者開發(fā)文檔打包進入 IPA。

安全加固實施建議

1、從官方下載開發(fā)工具 Xcode。

2、打包 IPA 文件時，管理好 Xcode 的 Build Phases、Copy Bundle Resources。

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

安全場景描敘

開發(fā)過程中通常會使用 NSLog 來輸出日志，用于調(diào)試 Bug 和測試功能。因此在打印出來的 Log 中很容易會泄漏程序的關(guān)鍵邏輯和用戶敏感數(shù)據(jù)，降低了逆向破解的難度，增加了敏感信息泄漏的風(fēng)險。

如果 Release 包里面沒有關(guān)閉系統(tǒng)日志，通過 Xcode Device 等工具，可以很容易地看到應(yīng)用程序 Log 的打印。

安全加固實施建議

1、使用宏來控制測試版和發(fā)布版本的日志輸出。

2、安全測試和對外發(fā)布時使用 Release 版本，關(guān)閉日志輸出。

原文：https://www.anquanke.com/post/id/145326