在這篇文章談到近期針對金融機構的針對性攻擊日漸增多，金融機構應強化對外服務的系統安全及補強內部資訊環境常見問題。而隨著金融業者推出越來越多行動App金融服務，相關App經檢測後卻發現有用戶資訊外洩、資料傳輸未受保護，及後端安全不足等問題。不只是金融服務App應注意，凡牽涉交易、敏感個資的App，系統開發與管理者都應特別注意。
以下文章簡介OWASP Top 10 Mobile Risks所提到十種行動裝置風險類型，並整理「金融機構辦理電腦系統資訊安全檢測辦法」草案提供做為防護上的參考。
M1 - Weak Server Side Controls伺服器端安全控制脆弱
在行動App開發時，經常有不同的承包商進行前後端的分包，而App廠商鮮少將後端控制運用搭配於前端手機應用程式中，而後端亦忽略了行動平台的特殊性而疏於伺服器安全的防護措施，包含後端的服務、API、資料庫、網站本身等，App後端需要有對應的Web Service提供服務，同樣會存在SQL Injection(資料隱碼注入攻擊)問題、應注意資料傳輸過程中的保護，如SSL安全性、Session是否有抵抗重送攻擊以避免被截錄後利用、傳輸的資料是否敏感，如身分證字號、卡號、密碼應避免在網路上傳輸等。其中經常發現前端App有不錯的UI介面，但是後端安全機制完全非銀行金融的安全水準，原因是App多半是委外製作，而對開發者在此方面安全要求顯然不足。此項目可以繼續參考針對網站的 OWASP Top 10 2013 、Cloud Top 10 Risks及 SANS 相關安全規範。
M2 - Insecure Data Storage不安全的資料儲存於用戶端
即檢測App本身處理資料儲存與該資料的保護方式。包含將用戶敏感資訊、系統敏感資訊存放於用戶端裝置中，而未給予適當的保護，可能造成這些資料被存取、解析來使用，間接造成其他傷害。常見的資料項目包含Usernames、Authentication tokens、Passwords、Cookies、Location data、UDID/EMEI、Device Name及個人相關資料等。
M3 –Insufficient Transport Layer Protection傳輸層保護不足
在App與後端的資料傳輸過程中，未施以合適的傳輸層保護，如其中有重要的資料傳輸，則容易被揭露或攔截使用。或者被中間人攻擊手法(MITM)介入交易過程，造成交易資料的外洩、變造、濫用。前端App與後端Web Service傳輸過程沒有使用HTTPS而使資料暴露。部分App直接與後端資料庫直接連通，導致資料庫傳輸內容亦暴露於網路。
M4 –Unintended Data Leakage非故意/意外造成資料外洩
包括網頁暫存、按鍵側錄、畫面截圖、日誌檔或暫存目錄等，一但攻擊者成功取得可攜式行動裝置權限時，將會侵犯使用者隱私，甚至導致資料洩漏情形。開發者將API的Key Chain (如: Facebook, Twitter API等，需要一串Key當作認證)、密碼與商業邏輯撰寫於App中，這樣可能會被逆向分析出原始資料或動態執行時遭到截取，而導致敏感資料洩漏。在行動銀行App的開發上，應將重要敏感資訊儘量移出用戶端，而放置於後端服務中。
M5 –Poor Authorization and Authentication身分鑑別與授權機制不嚴謹
App與後端溝通時，使用明碼的身分識別與密碼，或部分App將身分鑑別與授權內容綑綁行動裝置UDID或IMEI，可能導致未來裝置遺失時有更高的風險。
M6 –Broken Cryptography 加密方法不嚴謹或失效
App經常使用編碼(encoding)或擾亂(obsfucation)來當作是加密，即便如此仍無法有效保護敏感資訊的安全。另一種狀況則是未善用已經穩健強韌的加密函式庫，導致攻擊者有機可乘。如:App經常使用Base64編碼，而開發者認為這樣已經是加密，實則不然。
M7 –Client Side Injection 用戶端注入攻擊
App用戶端可以輸入資料，如同以往網頁應用程式，一樣會存在注入攻擊的安全疑慮。而多半在用戶端均未適當過濾注入攻擊字串或Exploit。另外也可能由QRCode、NFC、藍芽等傳入有攻擊意圖的資訊包(payload)或檔案。
M8–Security Decisions Via Untrusted Inputs 對於不受信任輸入來源的檢測處置
應用程式可能經由惡意攻擊者精心設計，或是應用程式遭攻擊者透過Client Side Injection攻擊方式來消耗可攜式行動裝置的硬體資源或提升權限情形。舉例來說，假設Skype應用程式具有HTML或Script Injection弱點，攻擊者只要事先把具有惡意連結的iframe寫入某個特定網頁。一旦可攜式行動裝置的瀏覽器讀取到此iframe程式碼時，Skype應用程式將無需使用者授權，自動開始播號給指定的電話號碼，此弱點已經被修補。
在掃瞄QRCode、NFC、藍芽時，透過交換讀取資訊進入裝置，亦可能從不受信任的來源帶入不安全的資訊，而導致入侵或資料外洩。例如: SMS簡訊中帶有詐騙 URL引導去安裝惡意APK檔案（目前相當氾濫的詐財簡訊即為一例）、NFC Tag可導引用戶到惡意網站。
M9–Improper Session Handling 連線階段處理不適當
通過第一層身分鑑別後，每次連線應該給予不同的session管理識別，而部分App沒有做到連線階段處置或使用相同的session識別，可能導致重送(replay)攻擊。如果行動裝置本身透過NFC或其他無線感應方式之交易，就有可能被空中攔截，因為沒有session管制，使攔截資料可以再次被使用，此為風險所在。
M10 –Lack of Binary Protections 封裝檔案保護不足
因為行動平台檔案也有可能被逆向分析而發現其中的明文訊息或隱藏資訊，若透過簡單的工具即可做到還原大部分的內容，則保護便顯得不夠充足。還原後可能會洩漏出程式中的設計、安全機制、系統資訊等，跳脫原有的安控機制，或者變造程式碼成為釣魚App使用。另外，現行App開發方式有可能採用 Hybrid方式套用 HTML及 JavaScript 的內容，而較容易看到原本的程式內容。可以考慮做破解(Jailbreak)、偵錯工具 (Debugger) 的偵測、檢查碼等
結論與建議
短期來看，遵照未來「金融機構辦理電腦系統資訊安全檢測辦法」(下表)的檢測項目，透過網路架構檢視、網路活動檢視、網路設備、伺服器及終端機等設備檢測，可達到一定程度的檢測效果。可以從風險的角度衡量，參考上述之風險來源做為檢測範圍匡列原則之一。另外應該要注意的是檢測的規則、方法程序、工具，是否在廣度與深度上具有效性，而非僅是一個檢測項目的因應。
其次，可針對上述之手法場景進行模擬的應變演練，包含不同目的、不同威脅來源及綜合事件的應變，可提升未來在遭遇或處置上的抵抗力及存活率。中長期而言，包含電腦系統資訊安全檢測專職組織、人員培育以及委外專案、廠商之安全評估均可作為參考發展方向。
金融機構辦理電腦系統資訊安全檢測辦法草案(於2014/5/23仍為草案，請以正式公告版為主)
.jpg)
(資料來源：本文作者提供）
本文作者為資深資安顧問擅長資安檢測、事件處理