iOS app security - 分析和防範

講者 :Hokila
mail:hokila.jan@splashtop.com
blog:josihokila.blogspot.com
FB:fb.me/hokilaj

這是10/17分享的第一個講者,在分享有關app的安全上攻防的相關議題
因為這是我第一次參加cocoahead聚會,誤信了google map而迷路,遲了半小時入場,因此有部份內容沒有聽完整>”<
幸好後來找到Hokila很好心的預錄了當天的內容,在投影片最後一頁的QR code裡(有列在參考資料裡)。

ps:報名網頁的地址『台北市大安區敦化南路一段205號6樓600室』,打入google map會出現在忠孝復興站@@
說到這,當天我到會場時,有另一個漂亮女生也遲到,我就和她打招呼,結果她問我:妳也是用google map嗎?
嗚哇~所以不只我一個人這樣阿!(握手

今天Hokila講的內容大致如下:

  1. iOS app 資料結構
    在一個APP裡面大概會有幾個資料夾
    2013-10-29_105710
    MyApp.app裡面會存放一些APP會用到的照片、XAB、貼圖(PVR)或素材PNG、JPG等檔案(裡面的值無法修改)。
    Documents是建議存放永久性資料的地方,我們可以在裡面創建、修改、刪除要永久存放的檔案,如DB工具、抓影片放裡面,好處是只要plist裡宣告可以file share的話,他會可以用iTune打開來。PS: 這個資料夾會被iCloud自動備份。
    Library則是較為複雜的資料夾裡面一般會有下面這些資料夾

    1. Application Support:也是放一些設定檔的地方,它不會不見
    2. Cache:不會備份,存放可以再次從網路上下載的資料(每隔一段時間會清掉,何時清也不確定)
    3. Cookie:存放webView的Cookie,要注意的是這個cookie和safari瀏覽器的並不一樣。
    4. Preferences:放使用者相關設定檔的地方(NSUserDefault)

    tmp這個地方,重要的東西千萬不要放在裡面,因為只要每一次NSTemporaryDirectory重新restart時都會清掉,一般講者都是放download到一半的檔案,下次app開啟時再繼續download。

  2. 這邊也有提到可以去觀察對方的plist檔案來看他們的設定(如url schemes、document types )
  3. Console log:可以到此下載(http://support.apple.com/kb/DL1465)這個軟體。
    剛剛隨意的載下來玩了一下,這邊有使用說明(請按此
    感覺蠻好玩的,可以用它來看到app沒有埋好的log、framework⾃自⼰己帶的log、system notification、memory warming
    螢幕快照 2013-10-29 下午9.16.41
    因此,在用framework時或是寫code時,要注意是不是有丟出什麼log訊息。
    或是播影片時,把影片暫停、改全螢幕等等,有些會吐一些log出來,所以有時如果不知道別人怎麼做的,可以去觀察那個APP的log紀錄,把關鍵字丟到google查,或許可以查到一些端倪。
    另外在這邊也可以看到memory leak,不過只能知道有沒有memory leak的狀況,而無法知道是為什麼造成的。
  4. 接下來是資料儲存的部份,很多時候,我們會將資料儲存在Library>Preferences,但若我們打開資料夾,會可以看到plist檔,並且key和value值都是明碼,這是非常危險的。(例如fb會在裡面有使用者的資料)
    螢幕快照 2013-10-30 上午12.50.31
  5. 把資料放到keychain裡面,某app存的資料,另一個app也可以拿出來,並且有經過加密。(不過講者說可用keychain_dump解出裡面的table來)
  6. 另外可以使用charles來觀察網路狀況,這個工具我在開發flash也時常用到,非常好用。個人推薦map local和一個可以控制流量的功能
    螢幕快照 2013-10-30 上午12.55.33 用本機檔案去替代伺服器上的檔案
    螢幕快照 2013-10-30 上午12.55.51 控制下載流量
    那要如何讓CHARLES可以偵測到IOS上APP的HTTP request呢?
    首先我們要設定proxy,然後在iphone上設定代理伺服器
    2013-10-30_1114272013-10-30_111443
    在這邊講者也列出了其他類似的工具:
    ZAP (Mac Windows) Free:一個open source的工具
    Fiddler (Windows) Free
    Wire Shark (Mac Windows) Free:比較老牌的,講者覺得有點難用
  7. 因此我們在分析一個APP的時候,至少要分析下面幾個項目
    ● device screen
    ● console log
    ● plist、db裡面的狀況,一般會放在document裡面
    ● API request/response(送什麼出去、送什麼回來)
  8. 接下來是這次的講者們都很推薦的class-dump(在此下載)
    這個東西可以dump app的class,看看裡面宣告了什麼東西。
    但首先機子要先jb才可以連進去,用遠端登入的方式連進手機的位置
    螢幕快照 2013-10-30 上午1.16.42
    在手機上將專案抓下來
    螢幕快照 2013-10-30 上午1.18.41
    把它解壓縮
    螢幕快照 2013-10-30 上午1.20.07
    拿取版本,把它copy到
    螢幕快照 2013-10-30 上午1.22.40
    接下來就把app的資料拿出來看
    螢幕快照 2013-10-30 上午1.24.15
    便可以看到一些.h的檔案
    螢幕快照 2013-10-30 上午1.27.24
    如上圖,這時後大多的app都會有保護而導致dump失敗,這時候可以去一些ipa破解網站去下載app,通常從那些地方下載的都是已被破解,沒有保護的。否則就得自己去修改iap。
  9. IAP Free和LocalAppStore
    iGameGardin/八門神器=>搜尋記憶體位置,把該資料鎖定住,像是可以鎖值,像是血量什麼都不會變。
    FLEX:最可怕的一項功能,鎖定function回傳值,例如說-(BOOL)isTransactionSucess 一定回傳YES
  10. 在這邊講者提供了十項資安要注意的議題
    螢幕快照 2013-10-30 上午1.33.32
  11. 應對方法:
    • model的值和view的值不要一樣
    • 當model和server互相傳值時,不要太過相信彼此傳來的值,應還是要再做驗證
    • 加密的話,不要用hash

    範例:首先,不要使用get,如GET http://xxx.yyy/getUserData.php改成POST http://xxx.yyy/public
    讓所有的api有一個共通接口,然後用(string)call_file_name來判別要呼叫那個api,用(string)token來認證使用者的身份(此token會在幾分鐘後失效),然後設定數字編號來代表不同的status
    接下來就是使用ssl來傳遞資料,這樣就會有加密了
    或這樣還不放心,可以把傳的值的結構改成struct

  12. 在買東西時做double check。例:買東西時把剩的錢和數量回傳,用的時候可再確認是否有該產品,較好的時機點是在使用者有做任何互動時,再去檢查資料是否正確,而不要每隔幾分鐘就去檢查一次。
    存回db時做hash(不要直接把值原封不動存進去,因為很容易被搜尋修改)
  13. 加密方式選擇:md5、sha1已被破解
    AES-128和AES-256是最潮的(他加解密是同一個key),現在還無法被破解。
  14. public data可以不用加密,像折價券之類。但是private data一定要加密,例如密碼、交易記錄,就非常需要加密
  15. 不要只顧app端而已,要想到更多有關於server的東西,這樣才不會漏洞百出,更重要的是兩者的交互過程也要去思考,這樣整體的設計才會更完美。

參考資料:

  1. IAP攻防戰
  2. IAP攻防戰影片
  3. iOS app security
  4. 當天的影片

Marty Cagan談產品系列影片心得

影片連結在此:  http://v.youku.com/v_show/id_XMzAyNTg0MDEy.html

Marty Cagan是eBey前副總裁,本篇文章截錄部份影片重點,若有興趣者請直接看原始影片喔!
(PS: 右邊有集數可以選擇)

產品的兩周理論

Marty Cagan認為一個產品負責人和設計者,應該在兩周之內,給使用者一個創意原型
但大多數的產品經理不會喜歡這樣做,
原因很簡單,因為他們總是認為此時提出的原型會不夠完善、有缺陷,
會希望將產品做到位之後再公開他們的產品。

但是Marty Cagan提到,只有將產品的設計公開出來給使用者看,才能夠做到心裡有數,
很多設計者或產品負責人很容易愛上自己的產品,
但愛情是盲目的,這很容易讓設計者忽略實際情況和使用者的反饋。

因此他認為應該在兩周之內提出一個產品原型,
他推薦使用high fidelity prototypes、user prototypes、live-data prototypes,
若時間來不及,也可以單就提出產品的設計圖如Balsamiq Mockups之類的,
很多時候,這樣才能夠最快檢驗出產品是否易於被接受。
即使此時的原形與最後產品產出可能會有極大的差異,但是及早搜集使用者意見,對產品的設計與開發是最安全的

克服心理障礙,將產品原型盡早提出給使用者看,
是產品團隊的一項重要技能。

什麼是基本產品

基本產品是所有軟體的基本核心概念,一個基本產品應要滿足下列條件:

  1. 客戶會願意購買該產品:最重要,也最難達成
  2. 使用者能夠很簡單的了解該怎麼使用,而不會一直要去理解”怎麼用”
  3. 有能力把產品開發出來

也就是說,一個基本產品應該要滿足:有價值、可用、可行的基本條件
但是要確定自己的產品是一個基本產品,則需要用prototypes和user testing來做測試。
我們可以用各種不同的原型模式(例如prototypes、live data prototypes、使用者面對面測試、以及sprint testing)去交叉比對、檢驗自己的產品是否符合上面的三項條件。

基本產品和最小化產品是有差異的,一般來說最小化產品指的是只具備基本功能的產品,
缺少可用性及外觀設計。
要記得客戶是不會花錢去購買半成品的,他們可能會試用,但不會購買。

產品探索團隊

這樣的團隊有三個重要角色

  1. 產品經理:定義產品功能
  2. 介面設計師:負責產品的易用性
  3. 程式設計師:最終決定這個構想是否可被實現

上面這三個角色應要一起合作、去定義一個基本產品:一款客戶願意購買、並能明白怎麼使用、也做的出來的產品

尤其是產品經理與介面設計師應該要密切的合作,一般我們會認為一個產品的計畫是由產品經理以及介面設計師一起共同構思。但有一個大秘密是:通常好點子都是程式設計師提出來的。因為程式設計師更了解怎樣的點子是可行的,他可以做到怎樣的功能。因此,雖然這些角色的功能不同,但每一項工作大家都必需參與,共同打造出基本產品。

也建議這三個角色在辦公室的設計上應該要放在一起,即使有職等上的不同,產品經理及介面設計師還是應該要讓他們能夠坐在附近以方便溝通。

用戶測試的類型

用戶測試是產品經理最重要的工作。

用戶測試分為兩部份:

  1. 使用者是否知道如何使用產品(可用性測試):做這個測試時,產品經理、程式設計師、介面設計師都應該在場。這個測試簡單、效果明顯,可以很快了解問題所在。
  2. 若用戶知道怎麼使用產品,那用戶願不願意使用產品,如果不願意,怎樣才能說服他們購買產品(價值測試):一般人會問你是否會願意購買此產品,但因為禮貌上,大部份的人都不會回答真實的想法。
    因此,Marty Cagan通常會問受測者:【你是否願意把這個產品推薦給同事?】,並用0~10的分數去代表非常不願意=>非常願意。除非他們給9~10分,否則都應該只是出於禮貌的敷衍你。在了解為什麼使用者不願意購買產品之前,不能停止用戶測試。
    在做價值測試時,當他們回答的結論是NO時,我們可能會發現這是因為受測者不是我們的目標客戶,還有其他人會需要。
    或者產品解決的問題不是他們需要的,這時就要改進產品,讓這個產品真正的可以解決使用者的問題,這會讓產品更有價值,通常這是解決方案出錯了,需要其他方式去解決問題。
    或者是營利模式錯誤。多留意這些關鍵點,他們往往是成功的關鍵。

測試方式的類型

  1. 使用者原型測試:快速製作prototypes,這個prototypes不能正常使用、也不能顯示正確數據,但只需要一兩天便可出爐。這可以快速的表達產品的想法給使用者並且觀察他們的反應,快速找到價值所在。這個工作由設計師就可以勝任,不需要程式人員。僅管是主觀的測試但效果明顯。
  2. 真實數據原型測試:可以得到真實的數據,會花到大把時間由程式人員撰寫,但是有些地方用戶原型測試是測不出的,因此這個步驟還是必需的。通常會同時採用對比測試,監控使用者瀏覽原型網站和舊有網站的流量,分為兩份數據,去做對比比對。

上述的兩種測試模型可以交叉使用,目的在花小錢辦大事,以避免製作出一個沒人想使用的產品。通常要做出一個完整的產品,會需要真實數據原型測試。但是想要快速的了解使用者感受或想法,使用者原型測試是最快速有效的。

定義產品經理

首先要了解,產品推廣並不是產品經理。定義市場需求、分析商業案例、搜集客戶需求是產品推廣的工作,很多人會認為直接把客戶需求丟給程式設計師開發就是產品經理,但其實這也不是。產品經理應要定義待開發任務,並定義任務優先權,然後開發團隊來完成這個任務。產品探索,就是要定義出基本產品。要做出好產品要有三個條件:

  1. 熟悉技術:只有了解技術、快速學習新技術,才能和技術團隊有良好的溝通。
  2. 熟悉UX(使用者介面設計):UX是好產品的必要條件
  3. 熟悉用戶和客戶:要做到這點,必需花大量的時間與使用者溝通及面對面的交流。
  4. 熟悉行業和市場

做到以上幾點,一個產品經理才有可能規劃出一個好的產品。

XSpect簡介(一個AOP觀念實作的框架)

講者資料:小
投影片:XSpect
專案github位置:在此

這是10/17在cocoaHead聚會裡由講者所分享的一個他自己所寫的framework
因為他是在今日議程的最後一個講者,有些部份講的較為快速、簡短
有很多投影片也跳過去未說,在當下聽時只能大略聽到一個概念。

較引起我注意的地方,是他所提到的AOP的觀念與應用
也因為對他所說的AOP的觀念以及相關應對、程式設計方式感到蠻有趣的
這部份在會議結束後也花蠻多時間在研究該講者的code以及相關概念的研究

這是講者對AOP的解釋:

如果我要敘述 AOP 在幹嘛,或是說他的目的的話。我會說 AOP 是在用另一種方式去封裝變化,達到原本 OOP 做不到的事。這個變化就是 crosscutting concerns。
crosscutting concerns 就是為了一個邏輯,而散布在四處的程式碼。
AOP 就是要把他們全部包裝在一起。

下面的是其他網頁對於AOP的解釋

AOP全名Aspect-Oriented Programming,我們先來看看XXX-Oriented的意義,通常翻譯「XXX導向」,也就是以XXX為中心,例如中文中「客戶導向」就是以客 戶為中心,而「物件導向」(OOP:Object-Oriented Programming)就是以物件為中心的程式設計。

自然的,Aspect-Oriented Programming,就是「Aspect導向程式設計」,也就是以Aspect為中心的程式設計,但什麼是Aspect?中文直譯通常是「方面」,但這個名詞容易使人混淆。

牛津字典中的英英解釋對Aspect是:particular part or feature of sth being considerd.

所以Aspect在英文中不只有「方面」的意思,還有部份(part)的意思。中文中稱「就這個方面來說」,通常指的是「就這個角度來說」或 「就這個方向來說」,這個解釋不適用於AOP中的Aspect。如果英文中說from this aspect of sth,除了可以翻譯為上面兩句的意義之外,還可以翻作「就這個部份來說」。

以我們的前一個主題中的記錄(log)動作插入至HelloSpeaker物件的hello()中為例,我們說「就記錄這個部份」是不屬於 HelloSpeaker職責的,它被硬生生切入HelloSpeaker中,英文中我們可以說:The logging aspect of the “hello” method doesn’t belong to the job of HelloSpeaker.

所以以整個方法的執行流程來說,如果執行流程是縱向的,則記錄這個動作硬生生的「橫切」入其中,這個橫切入的部份我們就稱之為Aspect,它 是橫切關注點(crosscutting concern,一個concern可以像是權限檢查、事務等等)的模組化,將那些散落在物件中各處的程式碼聚集起來。

所以Aspect要用中文表達的話,適切一些的名詞該是「橫切面」或「切面」。AOP關注於Aspect,將這些Aspect視作中心進行設 計,使其中從職責被混淆的物件中分離出來,除了使原物件的職責更清楚之外,被分離出來的Aspect也可以設計的通用化,可運用於不同的場合。

然後這個是XSpect框架的架構圖
2013-10-28_135639

簡單來說,使用AOP的框架主要是為了把 crosscutting concerns 封裝在一起,提高程式模組化的程度。
以上圖來看,左邊的部份是原本的程式寫法,假如是一個儲存資料的函數如下,以原本的寫法來看,或許檢查值是否符合格式這部份的程式碼,在許多地方都可以用到,AOP主要便是去關心多個相似的流程的衡切面裡共通的部份,橫著去”跨越”多個程序裡使用的相同的功能。

log是一個標準的crosscutting concern範例,因為log的策略會牽動整個系統的每一個必需記錄的部份。
從橫向去記錄和登記所有classes和methods。

假如今天我們一個送交表單的程式碼,長的像是這樣:

function saveForm(){
...檢查欄位是否為空。
...檢查輸入的值是否符合格式。
[真正的儲存工作]
...後續相關操作(存LOG、紀錄操作等...)
...顯示儲存結果

}

我們可以看到,在這個函數裡面,只有[真正的儲存工作]是函數真正要做的事情,
剩的部份都是要處理商業需求的商業邏輯而寫的功能。這樣的程式碼撰寫方式,會造成寫出的程式只能專門用在單一工作,降低程式碼的重用性以及可維護性。

例如我們今天在程式的多個地方都需要使用LOG來紀錄所有的商務操作,
若今天這一項業務邏輯需要做修改或是移除,
那麼整個專案裡有加入這個LOG功能的部份,都需要同時去更新,這將會增加整個維護的成本。

因此,這個AOP的框架就是為了要將這些和業務相關的程式碼與原本的程式碼分開,
(商務邏輯,稱為Aspect,具體實作這些商務邏輯的程式碼則稱為Advice)
利用程式切入點Joinpoint(在應用程式執行時加入商務流程的點或時機稱之為Joinpoint),
並設定那些Aspect要用在那些Joinpoint裡,這個設定的定義稱為PointCut。

這邊的文章有AOP相關專有名詞的解釋:AOP觀念與術語,下圖則是講者大大的相關說明圖
2013-10-28_143641

這個框架可以讓商業邏輯獨立出物件之外,只需要設定Joinpoint便可以將之插入程式邏輯中。
如果對這個講者個框架有興趣的話,可至他的GITHUB上有更完整的使用手冊及範例: XSpect Tutorial

PS: 在當場講解時,有在場的大大提供了另一個很完整、並且功能與這一套框架相似的框架
叫作ReactiveCocoa,若對AOP有興趣者,也可以到這個網站去看看另一種方式的實作
https://github.com/ReactiveCocoa/ReactiveCocoa

 

相關資料

  1. XSpect, a lightweight library to make your code reusable and maintainable
  2. XSpect Tutorial
  3. AOP入門
  4. AOP觀念與術語