以金融業為例，API潛在的資安風險及解決方法(上)

2020 / 08 / 12

資料來源: 中華民國期貨業商業同業公會期貨人季刊 2020 第一季/ 作者: 資策會資安所技術合作組- 鄭婷方,顏思嘉,朱宇豐

Fintech趨勢下的Open Banking
近年來由於資訊科技的快速發展，及社會大眾對於電子商品的高度依賴性，透過電子化技術導入金融消費市場的Fintech成為金融業熱烈討論的議題。在資訊科技導入金融市場的過程中，必須針對金融產業、資訊產業、資安產業這三個獨立的產業進行整合，因此資訊技術以及資安問題日益受到重視。其中在2015年6月世界經濟論壇（World Economic Forum, WEF）報告中指出，金融科技將帶來前所未有的突破性創新，甚至金融服務業的風貌將被重塑。

截至2019年，金融科技全球投資額已突破30兆台幣，此數據更凸顯出金融業與資訊科技業整合的趨勢已成為必然，資安問題也會日益受到重視。但在過往社會大眾認知裡，由於資訊安全的問題往往被視為資訊產業的成本，因此金融業導入資安的難度相對較高。即便如此，Fintech的概念已經改變金融圈交易的生態，因應不同的交易模式所衍生出來的風險，迫使金融業不得不重視資安議題，以避免在金融服務創新的過程中產生無法承擔的交易風險。

Fintech的概念具體展現於開放銀行（Open Banking），而Open API（應用程式界面，Application Programming Interface）為主導開放銀行的實際執行層面。Open Banking其精神在於將金融數據的主導權還給消費者，藉由「消費者賦權」
來達成「消費者與社會利益的最大化」。而Open Banking的運作模式主要是在銀行取得消費者的授權後，以合法的方式將金融數據及相關資訊提供給第三方業者（Third Party Service Providers, TSP）進行共享使其加以整合並分析相關數據進而產生更有價值的訊息。

二、Open Banking關鍵驅動力- API
目前為止，世界各國政府對於Open Banking所採行的運作方式及相關規範也有所不同。2018年，歐盟推出第二版的支付指令（the Second Payment Services Directive, PSD2）以第一版的支付指令PSD1要求銀行建立數位及電子支付服務為基礎下，更近一步要求銀行必須提供Open API給外部機構使用，此支付指令除了使銀行資料更加透明化外，也進一步提升了消費者對自身財物的主控權。同年，歐盟針對個人身分、生物特徵，以及定位資料等，提出一般資料保護規範（General Data Protection Regulation, GDPR），顯示出金融機構對法遵科技（RegTech）的需求日益增長。

有別於歐盟針對Open Banking訂定相關的規範，台灣的開放銀行政策採用香港的不修法模式，主要由銀行與TSP以合作方式共同推動，並採三階段開放，依序從商品資訊、客戶資訊到交易資訊，透過漸進式手法改變傳統銀行的營運模式。2019年10月16日，台灣「開放API平台」正式啟用，首先針對第一階段的商品資訊進行提供，此階段以非金融交易資訊為主且不涉及消費者的個人資料，主要為TSP業者透過API介接各家銀行的商品資訊，使消費者可透過應用程式比較各銀行的相關產品服務。綜觀上述，無論是歐盟以法規推動Open Banking的方式，亦或是台灣的不修法模式，儼然Open API已成為Open Banking不可或缺的一部分。透過Open API不但更有效地整合了Bank(銀行業者)、TSP(第三方業者)、User(使用者)，且在三方透過驗證機制進行串連下，使得Open Banking的概念得以具體展現，同時亦增加金融服務的多元性。尤其在交易模式方面，不同於以往，使用者單獨對口各家銀行來進行交易，TSP在銀行取得使用者授權的情況下，將使用者在各家銀行的資訊整合於API上，進行一站式的操作服務。TSP透過API除了提供更具個人化、及多元化的金融服務外，同時也使消費者能夠更有效地掌握自身的財務狀況。

三、API潛在資安風險
然而，為了成功推動Open Banking，銀行透過Open API公開應用程序邏輯和機敏數據且針對用戶的多個帳戶進行整合，同時公開個人可識別資訊（Personally Identifiable Information, PII），在這樣的狀況下等同於將帳戶相關資訊暴露在高風險的環境中，形成資安漏洞，也成了駭客攻擊的目標。API安全性對於企業來說相當重要，由於這些接口通常會暴露敏感數據，容易導致組織內部基礎架構被濫用。且隨著個資保護意識抬頭，建構符合GDPR及安全API的成本亦不斷增加，除此之外開發人員在進行產品開發時也須將安全性納入產品生命週期作為考量依據。以下為常見的API漏洞的攻擊手法包含：
1. 中間人攻擊（Man-in-the-Middle）
中間人攻擊是一種網路攻擊模式，其中駭客將自己插入兩方之間的對話中冒充了雙方，並取得了雙方試圖相互發送的訊息。若要減少這種攻擊，建議透過SSL / TLS升級到更安全的HTTPS協議，如此一來可以在服務和客戶端建立加密的安全連接，進而防止所有訊息被盜用，不過此種方法也只能針對部分，如下圖模式，中間人也是可以發憑證，所以竊取傳輸中加密資料，不過此種方法會多一個發憑證過程，容易感受到傳輸效率下降。此種技術已經很成熟，突破傳輸效率也是有可能做得到，如果在外盡量少用來路不明的網路。（如圖1）

2. CSRF攻擊（CSRF Attack）
在跨網站的請求偽造攻擊中，駭客可在用戶不知情的情況下，透過身份驗證的Web應用程序中採取了諸如匯款或更改電子郵件地址之類的操作。可透過token來防止CSRF攻擊，這些token作為隱藏字段嵌入HTML中，並隨每個請求發送回伺服器，讓伺服器可以驗證該請求是否來自經過身份驗證的來源。（如圖2）

3.  XSS攻擊（XSS Attack）
跨網站腳本攻擊（Cross site scripting attacks）的原理是將惡意腳本注入易受攻擊的應用程序，使用戶洩露其對話cookie。透過適當轉譯數據以消除惡意腳本並驗證用戶的數據中是否存在有害內容，即可以防止此類攻擊。
4.  SQL注入式攻擊（SQL Injection）
當用戶輸入最終將在數據庫上執行的SQL語句而不是輸入有效數據時，就會發生SQL注入。防禦這類攻擊的最佳方法是透過開發框架(Framework)、SQL準備的語句，或者使用ORM工具（如Hibernate）提供的命名參數。
5.  阻斷式服務攻擊（Distributed Denial of Services, DDoS）
阻斷式服務攻擊是一種惡意透過大量互聯網流量淹沒目標或其周圍基礎架構，從而破壞目標伺服器、服務或網路的正常流量。DDoS攻擊使用多個受損的電腦系統作為攻擊流量的來源，被利用的機器包括電腦和其他網路資源。此攻擊最困難的部分是難以區分攻擊和正常流量，尤其是當流量來自看起來像一般用戶的使用。

金融科技發展最有關聯性的是關於API安全風險的議題，除了認識API可能的潛在風險外，為解決Open API風險問題，根據OWASP 2019所提出之前10大API安全風險，針對此10大API資安風險將於下回提出相對應的管控機制分享給大家。敬請期待。

Fintech Open Banking 資策會資安所