以 API 為主軸的數位金融快速創新需正視API 安全性以取得客戶信任
- Noname Security - Taiwan
- 2022年6月1日
- 讀畢需時 5 分鐘
By Filip Verloy Noname Security EMEA區技術佈道者
開放銀行是以 API 為主軸的數位轉型完美範例。 API 是當今金融基礎設施中的重要工具，使得金融科技公司能夠將金融業務內嵌至他們的應用程式中，並且銀行能夠在客戶對現有金融服務供應商提出更多要求時，為其提供更為一致的應用體驗。
這種持續創新的循環正在提高整個行業對 API 的利用率，例如允許第三方開發人員針對特定金融機構開發應用程式。然而，金融科技公司與傳統銀行越急著將這些服務推向市場，也意味著它們的安全性正受到考驗。
創新競爭
如今，傳統銀行必須與徹底數位化的銀行競爭並跟上新的消費者需求。他們急於部署能夠實現數位化且零摩擦體驗的新技術。在全世界，開放銀行計劃推動了以 API 為主軸的服務，這些服務向第三方服務供應商提供支付服務、帳戶服務和其他客戶資料串接。透過提供附加價值來吸引新客戶和留住現有客戶的努力開發，產生了更多的應用程式服務和支援用 API。 API 的數量增加導致它們呈現給攻擊者和其他非善意者的攻擊平面急劇擴增。
無論是作為合規要求還是業務戰略，安全性都不應該是出事後再來思考是否需要。確保公司不會淪為討論數據外洩時的最佳範例，應該是考慮安全性時始終不變的優先事項。因此，在應用程式開發過程中，API 安全性需要成為首要考慮因素。然而，許多金融服務和金融科技公司選擇不在公司內部開發他們的應用程式，而是將他們的 API 和行動應用程式開發外包給第三方公司。
Noname Security 最近發布了基於前駭客Alissa Knight 對美國 55 個網路銀行應用程式安全性分析的研究結果。美國市場與英國市場一樣危機重重。 Scorched Earth: 入侵銀行 API 後突顯了幾個漏洞：
55 個被逆向工程後的行動應用程式中有 54 個包含硬編碼的 API 密鑰和令牌，包括第三方服務的用戶名稱和密碼。
所有的 55 個應用程式都容易受到 “中間人攻擊(WITM)“，因而使得 Knight 能夠攔截和解密行動應用程式與後端 API 之間的加密流量。
其中一家銀行將其行動應用程式和 API 的開發外包。而該開發團隊重複使用了相同且易受攻擊的程式碼，這造成其他 300 名銀行客戶一起暴露在危險中。
測試的 API ，100% 容易受到 OWASP API1:2019 Broken object level authorization (BOLA) 漏洞的攻擊，這使得 Knight 可以更改任何銀行客戶的 Visa ATM 簽帳金融卡號碼的 PIN 碼以及將資金轉入和轉出帳戶。
由於未對 API 請求進行身份驗證，測試的 API 也容易受到 OWASP API2:2019 Broken Authentication 的攻擊，這使得 Knight 可以在她知道帳號且未經認證的情況下，將資金轉入和轉出不同的銀行帳戶並更改客戶的 ATM 簽帳金融卡 PIN 碼。
API 部署在 Web 應用程式防火牆 (WAF) 後面 — 這是錯誤的安全控制部署。這無法檢測基於邏輯的攻擊，例如身份驗證和授權漏洞。
在幾次合作中，某些銀行無法找出受漏洞影響的特定 API 端點，這表示其 API 攻擊面存在明顯的可視化問題。
很明顯的，基於這些研究發現了身份驗證和授權的嚴重問題。在建立以 API 為主軸的服務時，仍有一些方法需要包含在“零信任”框架內。部署至線上之前把關好API 安全驗證仍是一個重要任務。
解決 API 安全性問題
API 安全性弱點影響所有企業，但金融服務相關是最敏感的行業。人們對金融業的信任度與數位化安全保護高度相關，因此API安全性與金融業能保持成功還有客戶採用有絕對關係。
在 Alissa Knight 的研究中，她發現了在擁有 25,000 名客戶和數百萬美元管理資產的銀行中與擁有 6800 萬客戶和管理資產 7.7 萬億美元的銀行有著相同的 API 安全漏洞。這顯示了大型、成熟且資金充足但使用傳統工具和流程的安全團隊，不代表能跟API 安全性劃上等號。
金融服務API 安全性必須跨團隊進行
在保護 API 安全方面需要許多發揮關鍵作用的團隊互相合作。開發團隊在寫程式碼時需要考慮到安全性；雲端團隊和平台團隊需要正確設定與使用API；安全團隊需要快速檢測、鑑識和回應事件。通常在大型公司中，API 能部署到線上環境且能使用的時間壓力比加上讓它們保持安全性的時間壓力大，而且企業團隊之間通常沒有明確的溝通管道。
針對 Knight 的研究，她利用的 API 是由第三方開發的——這又是另一個變數。此外，任何一家銀行都沒有發現駭客入侵。這凸顯了一個問題點，供應鏈的企業中部署 API 安全性也是相同的需要，這確保在攻擊發生之前檢測到並修復漏洞。這不僅僅是一個團隊的責任。開發人員、DevOps、DevSecOps 和安全團隊需要標準化、協作並與他們交流如何建立、部署和保護 API。
當漏洞被利用或攻擊成為頭條新聞時，要事後諸葛的討論非常容易，但事前檢測和阻止像 Alissa Knight 的行為只是 API 安全重大課題的一部分。企業需要跨 3 個核心領域來檢討與考慮 API 安全性：
1. API 安全態勢——公司一定要具備完整的 API 盤點清單（包含相關資料和METADATA），因此他們對自己的安全態勢有更強烈的認識。必須在狀況發生之前辨識和修復錯誤設定和漏洞。正如 Knight 的研究所證明的問題點，許多組織在攻擊發生之前完全是全部公開的狀態，他們不會意識到這一點。
2. API Runtime 安全性— 公司需要更好地了解其 API 的流量和行為。當發生異常和可疑行為時，可提供了更好的檢測和回應，因此可以在發生異常情況時即時防止攻擊。
3. API 安全性測試— 作為軟體開發生命週期的一部分，公司需要辨識出安全漏洞。比方來說，如果關鍵業務 API 無法通過基本的安全檢查（例如，缺乏身份驗證），絕對不應將其部署到線上環境中。在 API 的整個生命週期中，前期主動安全性測試可確保對API 安全性充滿信心。
在創新和安全中取得平衡點
隨著金融業不斷適應新的市場脈動，那些適應新技術的公司將取得更大更長遠的成功機會。開放銀行已成定局，當前的生態系統將被新的數位化工具框架所取代。金融業必須不斷進步，不僅僅對他們在新金融服務基礎設施中的地位的新願景，而且還要保護自己的商譽和維持客戶的信心，確保這些數位化工具安全性且具有抵禦各種攻擊的能力。
Noname Security Active Testing 是一個針對 AppDev/DevOps 組的新模塊，可幫助將“Shift Left”測試深入到應用程序開發過程中。 通過將 API 測試轉移到應用程式開發過程中，它可以幫助 AppDev/DevOp 團隊將經過徹底測試的 API 發佈到生產中，並避免在開發結束時造成測試瓶頸。 這減少了前期風險和補救工作，從而使 AppDev/DevOps 小組能夠始終如一地維護他們的測試版本。
Comments