iOS安全攻與防

• 本地數(shù)據(jù)攻與防
• https
• UIWebview
• 第三方sdk與xcode
• 反編譯與代碼混淆
• 越獄與反調(diào)試
• 掃描工具fortify
• 常見接口漏洞分析

本地數(shù)據(jù)攻與防

APP文件下的本地存儲Documents岂却、Library/Caches、Tmp

• Documents: 保存應(yīng)?運行時生成的需要持久化的數(shù)據(jù),iTunes同步設(shè)備時會備份該目錄裙椭。

• tmp: 保存應(yīng)?運行時所需的臨時數(shù)據(jù),使?完畢后再將相應(yīng)的文件從該目錄刪除躏哩。應(yīng)用沒有運行時,系統(tǒng)也可能會清除該目錄下的文件。iTunes同步設(shè)備時不會備份該目錄骇陈。

• Library/Caches: 保存應(yīng)用運行時?成的需要持久化的數(shù)據(jù),iTunes同步設(shè)備時不會備份該目錄震庭。一般存儲體積大、不需要備份的非重要數(shù)據(jù)你雌，比如網(wǎng)絡(luò)數(shù)據(jù)緩存存儲到Caches下器联。

如下圖所示在越獄設(shè)備中，完全可以利用iTools等其他工具將這些數(shù)據(jù)導(dǎo)出婿崭。

圖片1

防止數(shù)據(jù)泄露建議

1.對于主動存儲在app內(nèi)的重要的拨拓、有價值的、涉及隱私的信息需要加密處理氓栈，增加攻擊者破解難度渣磷。

2.對于一些非主動的存儲行為如網(wǎng)絡(luò)緩存，涉及重要信息授瘦，做到用完即刪醋界。

數(shù)據(jù)庫（sqlite）的安全問題

APP一般運用數(shù)據(jù)庫存儲一些數(shù)據(jù)量比較大竟宋，邏輯比較復(fù)雜的數(shù)據(jù)，方便我們使用和增加使用效率形纺。數(shù)據(jù)庫丘侠，一般存儲在Documents路徑下的特殊文件，格式一般為.db或者.sqlite逐样，導(dǎo)出后使用特殊工具即可查看如DB Browser for sqlite 和 SQLiteStudio蜗字。

防止攻擊者讀取數(shù)據(jù)庫的建議:

數(shù)據(jù)加密：
使用如AES256加密算法對數(shù)據(jù)進行安全加密后再存入數(shù)據(jù)庫中。

優(yōu)點：使用簡單脂新，無需第三方庫支持挪捕。

缺點：每次存儲都有加密解密過程，增加APP資源消耗争便。

整庫加密：
可使用第三方的SQLite擴展庫级零，對數(shù)據(jù)庫進行整體的加密。如：SQLCipher滞乙，git地址

優(yōu)點：對數(shù)據(jù)庫整體操作妄讯，減少資源消耗。
缺點：需要使用第三庫酷宵。

在創(chuàng)建數(shù)據(jù)庫時，添加如下代碼即可：

圖片2

這時再打開數(shù)據(jù)庫會彈出輸入密碼窗口躬窜，只有輸入密碼方可打開：

圖片3

sqlcipher使用demo請參考:數(shù)據(jù)庫sqlite3

KeyChain數(shù)據(jù)的讀取

Keychain是一個擁有有限訪問權(quán)限的SQLite數(shù)據(jù)庫（AES256加密）浇垦，可以為多種應(yīng)用程序或網(wǎng)絡(luò)服務(wù)存儲少量的敏感數(shù)據(jù)（如用戶名、密碼荣挨、加密密鑰等）男韧。如保存身份和密碼，以提供透明的認(rèn)證默垄，使得不必每次都提示用戶登錄此虑。在iPhone上，Keychain所存儲的數(shù)據(jù)在 /private/var/Keychains/keychain-2.db SQLite數(shù)據(jù)庫中口锭。如下圖：

圖片4

當(dāng)我們打開這個數(shù)據(jù)庫朦前，會發(fā)現(xiàn)如下圖中四個表：genp、inet鹃操、cert韭寸、keys

圖片5

分別對應(yīng)下圖中的前四列，下圖表示iOS系統(tǒng)的keychain 存儲類型

圖片6

數(shù)據(jù)庫內(nèi)數(shù)據(jù)荆隘，大多數(shù)是加密的恩伺，Keychain的數(shù)據(jù)庫內(nèi)容使用了設(shè)備唯一的硬件密鑰進行加密，該硬件密鑰無法從設(shè)備上導(dǎo)出椰拒。因此晶渠，存儲在Keychain中的數(shù)據(jù)只能在該臺設(shè)備上讀取凰荚，而無法復(fù)制到另一臺設(shè)備上解密后讀取。

圖片7

一旦攻擊者能夠物理接觸到?jīng)]有設(shè)置密碼的iOS設(shè)備時褒脯，他就可以通過越獄該設(shè)備便瑟，運行如keychain_dumper這樣的工具，讀取到設(shè)備所有的Keychain條目憨颠，獲取里面存儲的明文信息胳徽。具體方法是通過ssl讓mac連接iPhone，使用keychain_dumper爽彤，導(dǎo)出Keychain养盗。具體步驟如下：

1. 將手機越獄，通過Cydia（越獄手機都有适篙，相當(dāng)于App Store）安裝OpenSSH往核。

2. 在mac終端輸入： ssh root@（手機IP） 然后會提示輸入密碼，默認(rèn)為alpine

3. 使keychain數(shù)據(jù)庫權(quán)限可讀：
   cd /private/var/Keychains/
   chmod +r keychain-2.db

4. 下載工具Keychain-Dumper git地址

5. 將下載的keychain_dumper可執(zhí)行文件移到iPhone的/bin目錄下

• Ctrl+D嚷节，退出當(dāng)前ssh連接

• 輸入命令：scp /Users/ice/Downloads/Keychain-Dumper-master/keychain_dumper root@（手機ip）:/bin/keychain_dumper

6. 添加執(zhí)行權(quán)限: chmod +x /bin/keychain_dumper

7. 解密keychain：/bin/keychain_dumper

最后輸出如下圖所示的手機應(yīng)用內(nèi)所有使用keychain的情況聂儒，下圖展示的是一個用戶存儲的WiFi賬號和密碼。

圖片8

綜上可知硫痰，無論以何種方式在手機內(nèi)存儲數(shù)據(jù)衩婚，攻擊者總是有辦法獲取到，只是不同的方式效斑，攻擊者獲取的難度不一樣非春，從這個角度來說keychain還是比較安全的存儲方式，但是還是需要加密隱私信息缓屠。這也說明了我們對緩存數(shù)據(jù)加密的必要性奇昙。

剪切板的緩存

我們在使用剪切板進行操作時，iOS系統(tǒng)會緩存所操作的數(shù)據(jù)敌完，如果數(shù)據(jù)涉及隱私储耐，將會帶來安全問題。如下圖滨溉，iOS的三種剪切板和功能什湘，其中系統(tǒng)級別的剪切板優(yōu)先級最高。

圖片9

注意：在獲取剪切板內(nèi)容時业踏，總是先取系統(tǒng)的剪切板內(nèi)容禽炬，若沒有值才會取應(yīng)用間的剪切板內(nèi)容。所以在使用完剪切板時勤家，我們在程序退出時腹尖，清空剪切板內(nèi)容。

圖片10

系統(tǒng)鍵盤緩存

我們打字在使用系統(tǒng)鍵盤打字時時，會出現(xiàn)提示热幔，鍵盤一般會緩存這些提示字符串乐设，緩存在手機的“/private/var/mobile/Library/Keyboard/dynamic-text.dat”文件中，攻擊者可以提取出來绎巨，出現(xiàn)頻率最高的往往是賬戶名和密碼近尚。如下圖所示：

圖片11

系統(tǒng)鍵盤不會緩存條件：

1. 禁用了自動糾正功能的文本框會阻止輸入內(nèi)容被緩存。
   設(shè)置UITextView/UITextField 屬性autocorrectionType 為. no類型 场勤。

2. 非常短的輸入戈锻，如只有1或者2個字母組成的單詞不會被緩存。

3. 輸入框被標(biāo)記為密碼輸入類型和媳，也不會被緩存格遭。
   設(shè)置UITextView/UITextField 屬性isSecureTextEntry為true。

4. iOS 5之后留瞳，輸入只包括數(shù)字的字符串不會被緩存拒迅。
   設(shè)置UITextView/UITextField屬性 keyboardType為數(shù)字鍵盤。

5. 應(yīng)用內(nèi)自定義鍵盤她倘，銀行類APP大多使用自定義鍵盤璧微。

第三方鍵盤權(quán)限問題：

第三方鍵盤可能會收集自己的信息以及上傳自己的信息，因此在蘋果設(shè)置里禁止這種行為至關(guān)重要硬梁，再有就是前硫，因為第三方鍵盤不可控因素很多，可能緩存數(shù)據(jù)邏輯與系統(tǒng)鍵盤不一樣荧止，防止攻擊者攻擊本地緩存數(shù)據(jù)开瞭，因此建議盡量少用第三方鍵盤。如下圖罩息，蘋果給的建議。
另外个扰，我們使用的第三方鍵盤瓷炮，會上傳你的鍵入數(shù)據(jù)到服務(wù)器，這樣我們的隱私完全暴露給第三方递宅，使用時因注意不要啟用不完全訪問娘香。

圖片12

應(yīng)用進入后臺時的截屏行為

當(dāng)應(yīng)用進入后臺時，系統(tǒng)會自動在當(dāng)前應(yīng)用的頁面截屏并存儲到手機內(nèi)办龄，如果當(dāng)前頁面涉及敏感信息時烘绽，被攻擊會造成泄密。如下圖生成的兩張圖片路徑：

圖片13

防止手機截屏圖片泄密方案：

一般我們在應(yīng)用被掛起時俐填，在當(dāng)前頁面添加一層高斯模糊安接，在應(yīng)用重新進入前臺時，刪除模糊效果英融，代碼如下盏檐，截屏圖片效果如下圖：

圖片14

代碼如下：

圖片15

圖片16

HTTPS問題

HTTPS協(xié)議其實是有兩部分組成：HTTP + SSL / TLS歇式，也就是在HTTP上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會通過TLS進行加密胡野，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)材失，具體流程如下圖所示：

圖片17

1. 客戶端將自己支持的一套加密規(guī)則發(fā)送給服務(wù)端。

2. 服務(wù)端從中選出一組加密算法與HASH算法硫豆，并將自己的身份信息以證書的形式發(fā)回給客戶端龙巨。證書里面包含了服務(wù)端地址，加密公鑰熊响，以及證書的頒發(fā)機構(gòu)等信息旨别。

3. 客戶端獲得服務(wù)端證書之后客戶端要做以下工作：

a) 驗證證書的合法性（頒發(fā)證書的機構(gòu)是否合法，證書中包含的服務(wù)端地址是否與正在訪問的地址一致等）耘眨。

b) 如果證書受信任昼榛，或者是用戶接受了不受信的證書，客戶端會生成一串隨機數(shù)的密碼剔难，并用證書中提供的公鑰加密胆屿。

c) 使用約定好的HASH算法計算握手消息，并使用生成的隨機數(shù)對消息進行加密偶宫，最后將之前生成的所有信息發(fā)送給服務(wù)端非迹。

4. 服務(wù)端接收客戶端發(fā)來的數(shù)據(jù)之后要做以下的操作：

a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密客戶端發(fā)來的握手消息纯趋，并驗證HASH是否與客戶端發(fā)來的一致憎兽。

b) 使用密碼加密一段握手消息，發(fā)送給客戶端吵冒。

5. 客戶端解密并計算握手消息的HASH纯命，如果與服務(wù)端發(fā)來的HASH一致，此時握手過程結(jié)束痹栖，之后所有的通信數(shù)據(jù)將由之前客戶端生成的隨機密碼并利用對稱加密算法進行加密亿汞。

HTTPS存在的漏洞：

一、SSL證書偽造

首先通過ARP欺騙揪阿、DNS劫持甚至網(wǎng)關(guān)劫持等等疗我，將客戶端的訪問重定向到攻擊者的機器，讓客戶端機器與攻擊者機器建立HTTPS連接（使用偽造證書）南捂，而攻擊者機器再跟服務(wù)端連接吴裤。這樣用戶在客戶端看到的是相同域名的網(wǎng)站，但客戶端會提示證書不可信溺健，用戶只要做了證書驗證就能避免被劫持的麦牺。

圖片18

二、SSL剝離攻擊

該攻擊方式主要是利用用戶并不會每次都直接請求"https://",來訪問網(wǎng)站，或者有些網(wǎng)站并非全網(wǎng)HTTPS枕面，而是只在需要進行敏感數(shù)據(jù)傳輸時才使用HTTPS的漏洞愿卒。中間人攻擊者在劫持了客戶端與服務(wù)端的HTTP會話后，將HTTP頁面里面所有的"https://"超鏈接都換成"http://"潮秘，用戶在點擊相應(yīng)的鏈接時琼开，是使用HTTP協(xié)議來進行訪問；這樣枕荞，就算服務(wù)器對相應(yīng)的URL只支持HTTPS鏈接柜候，但中間人一樣可以和服務(wù)建立HTTPS連接之后，將數(shù)據(jù)使用HTTP協(xié)議轉(zhuǎn)發(fā)給客戶端躏精，實現(xiàn)會話劫持渣刷。

圖片19

三、 Charles等第三方抓包工具

抓包工具可以通過截獲真實客戶端的HTTPS請求矗烛，偽裝客戶端向真實服務(wù)端發(fā)送HTTPS請求和接受真實服務(wù)器響應(yīng)辅柴，用自己的證書偽裝服務(wù)端向真實客戶端發(fā)送數(shù)據(jù)內(nèi)容，我們將私有CA簽發(fā)的數(shù)字證書安裝到手機中并且作為受信任證書保存瞭吃。下圖所示就是Charles的可信任證書碌嘀。想了解Charles如何抓包的請自行Google，網(wǎng)上有很多文章歪架，在此不過多介紹股冗。

圖片20

防范https漏洞：

我們使用AFNetworking網(wǎng)絡(luò)框架來配置證書驗證，而我們需要配置這個框架下的類AFSecurityPolicy相關(guān)屬性即可和蚪。在此我們使用AFSSLPinningModeCertificate對證書進行完整校驗止状。

圖片21

AFSSLPinningModeNone: 代表客戶端無條件地信任服務(wù)器端返回的證書。
如果選擇此種證書類型攒霹，由于客戶端沒有做任何的證書校驗怯疤，所以此時隨意一張證書都可以進行中間人攻擊，可以使用burp里的這個模塊進行中間人攻擊催束。

圖片23

AFSSLPinningModePublicKey: 代表客戶端會將服務(wù)器端返回的證書與本地保存的證書中旅薄，PublicKey的部分進行校驗；如果正確泣崩，才繼續(xù)進行。
如果選擇此種類型證書的話洛口，客戶端只是做了部分校驗矫付，例如在證書校驗過程中只做了證書域名是否匹配的校驗，可以使用burp的如下模塊生成任意域名的偽造證書進行中間人攻擊第焰。

圖片24

如果客戶端對證書鏈做了校驗买优，那么攻擊難度就會上升一個層次，此時需要人為的信任偽造的證書或者安裝偽造的CA公鑰證書從而間接信任偽造的證書，可以使用burp的如下模塊進行中間人攻擊杀赢。

圖片25

AFSSLPinningModeCertificate: 代表客戶端會將服務(wù)器端返回的證書和本地保存的證書中的所有內(nèi)容烘跺，包括PublicKey和證書部分，全部進行校驗脂崔；如果正確滤淳，才繼續(xù)進行。這種方式可以避免中間人攻擊砌左。

一般做法是將服務(wù)器生成的證書打包，導(dǎo)入客戶端內(nèi)，使用包的二進制數(shù)據(jù)澳淑，進行全部校驗犁罩，但是，打包進app會有被攻擊者反編譯出的風(fēng)險产弹，一般做法是將二進制數(shù)據(jù)轉(zhuǎn)換成base64的字符串派歌，存入代碼內(nèi)。
注意：服務(wù)器給的證書一般是.crt格式的痰哨，我們需要轉(zhuǎn)化成.cer格式胶果，終端執(zhí)行命令：
openssl x509 -in 證書name.crt -out 證書name.cer -outform der。

圖片26

圖片22

因此配置 allowInvalidCertificates = false, validatesDomainName = true
pinnedCertificates 屬性是證書的二進制數(shù)據(jù)作谭，對于證書來說稽物，一般是.cer格式的文件，拖入項目中折欠，然后讀取二進制數(shù)據(jù)對其賦值贝或，但是，項目中的文件锐秦，攻擊者很容易通過解包取出咪奖，所以我們一般，在代碼中存放證書的二進制流數(shù)據(jù)

UIWebView按漏洞

一酱床、 UIWebView XSS漏洞

（1） 未知的來源的進入了web頁面羊赵，如對用戶輸入框輸入的數(shù)據(jù)沒有進行過濾，惡意數(shù)據(jù)通過用戶組件扇谣，URL scheme handlers或者notifications傳遞給了UIWebView組件昧捷，并且UIWebView組件沒有驗證該數(shù)據(jù)的合法性。

（2 ） UIWebView通過loadHTMLString:baseURL：這個方法從本地html讀取代碼罐寨，然后加載靡挥，而這個HTML代碼并沒有被信任的未知來源，這個惡意的本地HTML可以讀取所有的保存在該應(yīng)用里的cookie鸯绿，繞過同源策略做一些非法的操作跋破，攻擊者將用戶的像cookie簸淀，session等敏感數(shù)據(jù)傳遞給攻擊者，或者重定向用戶頁面到攻擊者控制的服務(wù)器上毒返，或者誘導(dǎo)用戶輸入一些敏感數(shù)據(jù)租幕，然后傳遞到攻擊者的服務(wù)器上，實現(xiàn)釣魚攻擊拧簸。

方案：

（1）對輸入框內(nèi)的數(shù)據(jù)進行關(guān)鍵詞過濾（如“script”字符串）劲绪，避免輸入惡意腳本語言。
（2）在加載網(wǎng)頁的內(nèi)容之前狡恬，會用dataWithContentsOfURL方法將加載的網(wǎng)頁的內(nèi)容提取出來放入NSData中珠叔，在使用loadHTMLString之前可以對NSData的內(nèi)容過濾，編碼等等弟劲，上述代碼中是將script字符串都替換掉祷安，保證了UIWebView不去加載腳本，從而也避免了加載惡意腳本的可能兔乞，如下代碼：

圖片27

或者可以通過這些截斷的URL來做一些白名單汇鞭、黑名單策略，如禁用file域庸追，不讓它加載本地文件

圖片28

二霍骄、UIWebView https中間人攻擊漏洞

UIWebView中間人漏洞有如下兩種情況，第一種情況是直接沒有沒有校驗證書合法性淡溯，如校驗根證書是否為自簽名读整，是否可信，證書是否過期咱娶。第二種情況是校驗了證書的合法性但沒有校驗訪問的主機域名與證書上的域名是否匹配米间。通過中間人攻擊可以查看客戶端與服務(wù)器端傳輸?shù)臄?shù)據(jù)，有可能導(dǎo)致用戶隱私數(shù)據(jù)的泄露膘侮，通過中間人可以修改客戶端與服務(wù)器之間傳遞的數(shù)據(jù)屈糊，有可能導(dǎo)致用戶財產(chǎn)的損失。

解決方案：

在UIWebViewDelegate的代理方法中攔截請求琼了，并用AFNetworing框架對該請求進行https驗證逻锐，驗證通過再加載網(wǎng)頁，代碼如下：

圖片29

但是雕薪，我們的app很難做到全是https昧诱，域名驗證就無法通過，UIWebView的https證書驗證添加還有待討論所袁。

Xcode與第三方庫來源

如下圖所示,2015年的xcode后門事件盏档，原因就是從非官方渠道下載的xcode，被導(dǎo)入惡意代碼會上傳產(chǎn)品自身的部分基本信息纲熏，包括安裝時間妆丘、應(yīng)用id，應(yīng)用名稱局劲、系統(tǒng)版本以及國家和語言等勺拣。

圖片30

驗證Xcode來源：

終端內(nèi)輸入：spctl --assess --verbose/Applications/Xcode.app

如果輸出是/Applications/Xcode.app: accepted source=Apple 或者
/Applications/Xcode.app: accepted source=Apple System 或者
/Applications/Xcode.app: accepted source=Mac App Store 中的一個，表明來源可靠鱼填。

因此药有，我們?yōu)榉乐构ぞ吆偷谌綆毂晃廴荆褂脮r一定要注意來源苹丸，對于SDK來說愤惰，選用之前要做到觀看代碼邏輯，避免惡意代碼赘理，對于含有動態(tài)庫或者靜態(tài)庫的SDK宦言，盡量避免使用，或者運用反編譯手段商模，逆向SDK奠旺，這點難度較大。

逆向工程反編譯APP

市場上有很多反編譯工具如class-dump-z施流、IDA响疚、Hopper Disassembler，他們通常是和Clutch一起使用瞪醋。因為APP Store上的APP都是加密過的忿晕，需要先解密，解密一般可以得到資源文件银受、二進制文件践盼， Clutch 就是做這個工作的軟件。class-dump-z 蚓土，一般用來反編譯oc工程宏侍，不支持swift，IDA收費蜀漆，而且太貴谅河，我們主要使用Hopper來反編譯項目。只要將項目的二進制文件拖入hopper內(nèi)即可反編譯确丢。下圖就是反編譯绷耍，我們的項目中的配置的key值。

圖片31

下圖是反編譯出的項目中的所有方法：

圖片32

下圖是隨機抽取到的PACreateFollowUpViewController的ViewDidLoad方法的匯編實現(xiàn)形式鲜侥，大致邏輯可見褂始。

圖片33

下圖是反編譯出的項目中使用的字符串內(nèi)容：

圖片34

綜上所述，逆向工程師可以通過Hopper軟件破解APP描函，觀看里面的算法邏輯崎苗，或者利用工具向包內(nèi)添加代碼更改原來的邏輯狐粱。解決方案：

字符串加密，類名方法名胆数、代碼塊混淆

一肌蜻、字符串加密：
現(xiàn)狀： 對于字符串來說，程序里面的明文字符串給靜態(tài)分析提供了極大的幫助必尼，比如說根據(jù)界面特殊字符串提示信息蒋搜，從而定義到程序代碼塊，或者獲取程序使用的一些網(wǎng)絡(luò)接口等等判莉。

加固：對程序中使用到字符串的地方豆挽，首先獲取到使用到的字符串，當(dāng)然要注意哪些是能加密券盅，哪些不能加密的帮哈，然后對字符串進行加密，并保存加密后的數(shù)據(jù)渗饮，再在使用字符串的地方插入解密算法但汞，這樣就很好的保護了明文字符串。

二互站、類名方法名混淆：

現(xiàn)狀：目前市面上的IOS應(yīng)用基本上是沒有使用類名方法名混淆的私蕾，所以只要我們使用class-dump把應(yīng)用的類和方法定義dump下來，然后根據(jù)方法名就能夠判斷很多程序的處理函數(shù)是在哪胡桃。從而進行hook等操作踩叭。

加固：對于程序中的類名方法名，自己產(chǎn)生一個隨機的字符串來替換這些定義的類名和方法名翠胰，但是不是所有類名容贝，方法名都能替換的，要過濾到系統(tǒng)有關(guān)的函數(shù)以及類之景。

三斤富、程序代碼混淆：

現(xiàn)狀：目前的IOS應(yīng)用找到可執(zhí)行文件然后拖到Hopper Disassembler或者IDA里面程序的邏輯基本一目了然。

加固：可以基于Xcode使用的編譯器clang锻狗，然后在中間層也就是IR實現(xiàn)自己的一些混淆處理满力，比如加入一些無用的邏輯塊啊，代碼塊啊轻纪，以及加入各種跳轉(zhuǎn)但是又不影響程序原有的邏輯油额。可以參考下開源項目刻帚， 當(dāng)然開源項目中也是存在一些問題的潦嘶，還需自己再去做一些優(yōu)化工作。

四崇众、加入安全SDK：

現(xiàn)狀：目前大多數(shù)IOS應(yīng)用對于簡單的反調(diào)試功能都沒有掂僵，更別說注入檢測航厚，以及其它的一些檢測了。

加固：加入SDK锰蓬，包括多處調(diào)試檢測阶淘，注入檢測，越獄檢測互妓，關(guān)鍵代碼加密，防篡改等等功能坤塞。并提供接口給開發(fā)者處理檢測結(jié)果冯勉。

Cycript腳本語言顯示和修改APP的UI布局與代碼邏輯

Cycript是由Cydia創(chuàng)始人Saurik推出的一款腳本語言,支持oc和js語言的編輯器。通過Cycript下載安裝可以直接使用摹芙。Cycript 語法使用文檔

Cycript 作用：

1. 創(chuàng)建對象

2. 輸出當(dāng)前APP頁面布局
   （UIApp.keyWindow.recursiveDescription().toString()）

3. 添加方法

4. 更改對象屬性

5. Load frameworks

...

Cycript 使用示例：

1.通過Cydia下載安裝Cycript

2.通過ssh連接手機和電腦

在mac終端輸入： ssh root@（手機IP） 然后會提示輸入密碼灼狰，默認(rèn)為alpine

3.輸出所要更改應(yīng)用的當(dāng)前進程地址和文件地址：

ps aux | grep demo名（不一定是APP名）

輸出如下結(jié)果表示成功了

圖片35

4.使用cycript連接這個app

cycript -p 6542

輸出 cy# 表示成功 即可輸出相關(guān)指令更改APP了

例如打印當(dāng)前頁面的布局信息：

圖片36

詳細(xì)使用方式，請參考cycript語法文檔在此不過多介紹

Cycript危害：

使用cycript和反編譯工具是逆向APP工程的基本工具浮禾，cycript是解析APP布局和修改代碼邏輯的利器交胚，為防止cycript修改代碼邏輯，從而逃過我們自己代碼的邏輯盈电，我們在編寫重要流程時蝴簇，需要提醒接口也要鑒權(quán)判斷，如支付訂單時匆帚，在錢不夠的情況下熬词，我們不讓button可以點擊，但是通過cycript吸重，我們可以修改代碼button的屬性enable = YES互拾，這樣如果后臺不做判斷導(dǎo)致支付成功，會引發(fā)安全問題嚎幸。

檢測越獄與反調(diào)試

很多APP漏洞問題都是基于設(shè)備越獄的條件颜矿，因此在完成某些行為時，檢測APP是否越獄嫉晶，可以有效的防止攻擊者的破解行為骑疆。

1.常見越獄存在的文件

  /Applications/Cydia.app
  /Library/MobileSubstrate/MobileSubstrate.dylib
  /bin/bash
  /usr/sbin/sshd
  /etc/apt

在下面代碼中輸入上述路徑，判斷是否存在车遂，存在表示該設(shè)備已被越獄

圖片37

2.判斷cydia的URL scheme

一般越獄的設(shè)備中都會安裝cydia這個應(yīng)用封断，我們可以通過是否可以打開這個應(yīng)用檢測設(shè)備是否越獄。

圖片38

反調(diào)試

我們可以使用<sys/types.h>和<dlfcn.h>庫來阻止GDB依附舶担，從而達(dá)到阻止攻擊者破解代碼后坡疼，對我們的程序進行調(diào)試。具體代碼實現(xiàn)如下圖：

圖片39

掃描工具對代碼的掃描

市面上有很多掃描工具衣陶，一般比較流行的有fortify和coverity柄瑰，其中coverity對代碼的檢查側(cè)重于代碼質(zhì)量闸氮，fortify側(cè)重于代碼的安全漏洞。我們這里介紹的是使用fortify對代碼的漏洞分析教沾。掃描結(jié)果如下：

圖片40

掃描結(jié)果分析：

一蒲跨、發(fā)現(xiàn)一個關(guān)于 ATS（App Transport Security）問題，iOS9中新增App Transport Security（簡稱ATS）特性, 主要使到原來請求的時候用到的HTTP授翻，都轉(zhuǎn)向TLS1.2協(xié)議進行傳輸或悲，也就是https，通過在 Info.plist 中添加 NSAppTransportSecurity 字典并且將 NSAllowsArbitraryLoads 設(shè)置為 YES 來禁用 ATS堪唐，但是這種行為是不安全的巡语，也不是蘋果推薦的，結(jié)合我們使用需求淮菠，很多第三方庫和網(wǎng)頁還是使用http男公，所以就沒處理。

二合陵、在info.plist內(nèi)配置了一個APIkey值枢赔，info.plist里的內(nèi)容是完全可以暴露出來的，在里面配置key值拥知，也是一種不安全的行為踏拜。這個key是項目中bug統(tǒng)計Fabric腳本自動添加的key，目前已修正低剔。

項目中的接口常用漏洞：

一执隧、意見反饋／資質(zhì)審核等處，添加照片未對上傳文件后綴名作限制户侥，可實現(xiàn)任意文件上傳镀琉。

圖片41

這個是上傳圖片接口，上傳時并沒有對上傳的圖片二進制流數(shù)據(jù)進行格式判斷蕊唐，攻擊者可以通過抓包更改數(shù)據(jù)流屋摔，例如，將圖片二進制流替換成含有病毒的HTML的文件數(shù)據(jù)流替梨，我們訪問時钓试，會受影響。
二副瀑、下單時修改陪診服務(wù)費參數(shù)弓熏，將費用由99.0篡改為0.1，提交后成功下單

圖片42

針對支付漏洞糠睡，后端應(yīng)嚴(yán)格校驗訂單對應(yīng)的金額挽鞠，防止攻擊者進行篡改價格提交接口，引發(fā)重大漏洞。

三信认、app采用了https,但對證書校驗不當(dāng)材义，可通過信任bupsuite等代理工具攔截到https通信數(shù)據(jù)

圖片43

我們使用AFNetworking網(wǎng)絡(luò)框架請求接口，然而并未對證書進行比對校驗嫁赏，使得只要是ca頒發(fā)的的可信任證書其掂，都可以驗證通過，從而導(dǎo)致中間人攻擊或者被抓包潦蝇。

四款熬、賬號1在查詢自己訂單時將訂單參數(shù)OrderId替換為賬號2的值即可查詢賬號2的訂單

圖片44

在查詢賬號1隨訪記錄時通過攔截數(shù)據(jù)包修改Id參數(shù)為賬號2的對應(yīng)的值即可實現(xiàn)越權(quán)查詢

圖片45

越權(quán)漏洞的成因主要是因為開發(fā)人員在對數(shù)據(jù)進行增、刪攘乒、改华烟、查詢時對客戶端請求的數(shù)據(jù)過分相信而遺漏了權(quán)限的判定。大多數(shù)應(yīng)用程序在功能在UI中可見以前持灰，驗證功能級別的訪問權(quán)限。但是负饲，應(yīng)用程序需要在每個功能被訪問時在服務(wù)器端執(zhí)行相同的訪問控制檢查堤魁。如果請求沒有被驗證，攻擊者能夠偽造請求以在未經(jīng)適當(dāng)授權(quán)時訪問功能返十。因此應(yīng)該嚴(yán)格后端嚴(yán)格校驗參數(shù)與用戶的所屬關(guān)系妥泉，防止越權(quán)。

五洞坑、賬號退出登錄后相關(guān)接口依然可以操作

圖片46

添加退出登錄接口盲链，退出登錄時，立即注銷session迟杂。防止退出登錄后刽沾，依然可以通過接口請求數(shù)據(jù)。

六排拷、 APP登錄處侧漓，選擇動態(tài)密碼登錄，登錄成功后直接返回了用戶賬號密碼對應(yīng)的md5值

圖片47

所有接口不應(yīng)該返回用戶賬號密碼字段监氢，應(yīng)該屏蔽掉布蔗，即使返回的是MD5加密過的，也有可能被破解浪腐。

七纵揍、相關(guān)訂單查詢接口，請務(wù)必統(tǒng)一整改议街，涉及敏感信息：身份證號,手機號等未做脫敏處理

圖片48

在接口中必須返回一些敏感信息時泽谨，應(yīng)該使用對稱加密方式加密處理。防止攻擊者盜用用戶隱私信息。

八隔盛、登錄會話一天未操作后進入app會話依然有效犹菱，為保證用戶賬號安全，應(yīng)建立會話失效機制

圖片49

每次請求接口吮炕，應(yīng)該校驗token值是否在規(guī)定時間內(nèi)有效腊脱，無效則強制退出,在一定程度上防止攻擊者使用抓到的包或者接口一直惡意請求服務(wù)器。

最后

git地址

轉(zhuǎn)載請說明出處龙亲，文章書寫不易陕凹，如對你有幫助，請點贊鳄炉，謝謝杜耙！