如何給SaaS應用程式做安全測試
SaaS（軟體即服務）應用程式在過去幾年中迅速發展了。截至2023年，全球已有超過30,000家SaaS新創公司。SaaS應用程式已成為無數行業線上業務的重要組成部分和首要選擇。憑藉著簡化的流程，便捷的交付和可擴展性，越來越多的應用資料和業務邏輯已從本地遷移到了SaaS雲端環境中。
然而，SaaS應用程式的成長與普及也自然成為了無數網路威脅與攻擊的誘人目標。面對各種安全挑戰，SaaS應用供應商與使用者需要透過全方位的安全措施與測試來積極分析與因應。
SaaS面對的主要風險
由於SaaS應用程式通常被託管在服務供應商的雲端伺服器上，並讓用戶設備透過互聯網進行訪問，因此這種交付模式具有更低的成本和更易於維護的優點。不過，攻擊者一旦發現SaaS應用程式上存在安全漏洞，就會想辦法透過取得應用服務的存取權限，如探囊取物般批量取得使用方和客戶的資料資訊。
目前，此類風險大致包括以下幾個方面：
多租戶架構缺陷
在多租用戶SaaS架構中，來自不同客戶的資料駐留在同一台伺服器上。一旦租戶之間的邏輯隔離不到位，那麼某個租戶就可能無意、甚至刻意訪問到另一個租戶的數據，進而出現隱私信息的洩露，機密性的缺失。
任意訪問的開放性
由於任何人都可以從任何位置存取SaaS應用，因此攻擊者不再受限。他們可以輕鬆地使用網路釣魚詐騙，來獲取使用者憑證，或透過直接破解弱密碼，來實現未經授權的存取。
與其他應用的集成
SaaS平台通常使用API來與其他應用程式整合。如果這些API在設計上具有安全缺陷，那麼攻擊者便可以將其作為網關，滲透到SaaS應用以外的多個系統，並竊取敏感資料。
故障導致資料遺失
雖然SaaS的雲端服務保障了應用程式的可用性，但雲端伺服器上的資料安全性可能會因網路問題、裝置故障、甚至是自然災難而遺失或損壞。對此，安全團隊在檢查SaaS業務時，應注意資料備份策略的可靠性，以避免因為資料遺失而造成服務的完整性不足。
直接遭遇攻擊
根據開放式Web應用程式安全專案（OWASP）列出的典型十大Web應用和API風險，我們可以知道SaaS應用程式上一旦存在邏輯漏洞和技術問題，就會被駭客透過互聯網，發起直接攻擊和利用，也就可能產生服務中斷、資料外洩、以及隱私侵犯等不利影響。
責任共擔
由於多個應用程式共享同一套雲端服務系統與後台邏輯，因此服務提供者的配置錯誤、服務中斷等營運故障，就可能會被SaaS系統的共享結構所放大，進而波及到使用方的業務，甚至將網路釣魚、惡意軟體、以及勒索攻擊，傳播至使用方的業務資料上，使其被動承擔相應的責任。
欠合規與監管
縱然SaaS應用的使用方竭力遵循合規與監管的要求，但是一旦疏忽了對其使用到的SaaS供應商的合規性查驗，則會面臨連帶的監管風險，進而導致巨額的罰款、或讓公司聲譽受損。對此，安全團隊應定期審查SaaS供應商對行業標準和法律法規的遵守情況。
測驗的概念與好處
鑑於SaaS應用程式為用戶簡化了複雜的服務處理與提供機制，而其本身通常會保留使用方和最終用戶的大量敏感商業資訊與個人數據，因此SaaS安全測試可以透過對SaaS業務的所有組成部分採取深入掃描、利用與評估，以發現並修復應用在介面、網路、通訊、API、第三方整合、基礎程式碼、使用者輸入、以及角色權限等方面的安全漏洞，進而降低SaaS應用的營運風險，改善其安全態勢。
可見，SaaS安全測試不僅有助於保障企業的雲端系統、應用與資料安全，而且能滿足各種嚴格的合規性要求。
測試關注的組件
對於SaaS應用的安全測試而言，安全團隊通常需要注意並檢查以下三個方面的基本組件：
連線的安全性
客戶端設備與SaaS應用的連接是值得關注的重要風險點。鑑於SaaS應用的特點，服務提供者需要為使用方實施必要的頻道保護、身分驗證、權限管理、以及行為監控等連線上的存取與保障。而本著「從不信任，始終驗證」的零信任原則，應用使用方的安全團隊有必要透過了解，來為後續的安全測試做好規劃。
應用程式服務的安全性
SaaS應用程式雖然簡化了使用方的自我構建，對於後端複雜的呼叫邏輯，使用方往往透過API、以及配套的管理控制台來實現呼叫。不過，在進行應用安全測試之前，使用方的安全人員有必要透過與SaaS服務供應商的交互，獲悉其平台應用本身的基本業務類型，了解其技術架構可能存在的挑戰，API的權限管控，管理控制台的設定與操作邏輯。
整合互動的安全性
使用方往往需要將由SaaS平台提供的服務與數據，透過API整合等方式，為自己的前端應用提供擴展的功能、自動化的工作流程、以及與其他服務的互動。鑑於此類整合往往是一次性完成的，因此使用方的安全團隊應根據職責分離（SoD）和最小權限（PoLP）原則，審查前端應用與SaaS平台整合及互動的必要性與可控性。
測試的階段
為了避免出現「拆盲盒」的不確定性，使用方的安全團隊可以參考以下步驟，分階段進行SaaS安全測試：
收集資訊
安全團隊在考慮對SaaS應用程式進行安全測試之前，需要對待測的應用程式的架構、網路、業務邏輯、資料流轉、以及角色權限有所了解。這是製定有效的測試策略的基礎。鑑於安全團隊可能並非在應用程式項目開始時就參與其中，因此我們可以透過如下簡單的問卷列表，來獲取「第一手資料」：
- 該應用程式能夠提供哪些基本功能？
- 哪些團隊會在哪些場景下使用到該應用程式？
- 該應用對於前端業務的重要性？
- 該應用程式中將儲存哪些業務資料類型，它們的敏感度如何？
- 最終用戶會使用受管理的設備、還是個人終端存取該應用程式？
- 使用者會使用受管理的私密網路、還是網路連線存取該應用程式？
- 存取該應用程式的方式是瀏覽器、還是由使用方提供的應用程式介面？
- 平台供應商是否能給出應用的架構、通訊、以及配置等資訊？特別是如下安全控制資訊：
Web應用防火牆（WAF）等雲端安全元件
可用的外部連接埠
負載平衡與DDoS保護
基於身分認證管理（IAM）的單一登入（SSO ）整合、或多因素身份驗證（MFA ）的存取控制
靜態和傳輸中的資料加密
伺服器上的端點偵測與回應（E DR ）和防毒軟體（AV ）方案
API金鑰的管理與限流
資料與代碼的備份和服務的高可用性（HA）
日誌記錄和監控選項
制定計劃
安全測試團隊根據了解到待測應用的資訊與複雜程度，與各個利益方討論潛在的限制、預估的成本，最終創建一個全面的安全測試計劃，其中包括：明確的範圍、標準、方法、深度、以及測試所需的系統配置、工具、及腳本。
雙方交流
安全測試團隊透過與被測應用供應商交流，確定將要執行測試的人員以及聯繫方式，給將要使用的測試工具開放端口，並將其IP地址放入白名單，按需開放跳板主機，以及開通測試工具的安裝許可。
自動掃描
在這個階段，安全團隊透過專業的掃描工具，採用自動化的方式，仔細尋找被測應用的顯著漏洞。此類工具往往具有一定的侵入性。也就是說，它們可以透過模擬潛在的攻擊者，來爬取應用程式中的每個請求，進而快速地發現潛在的安全弱點和漏洞。
利用測試
針對自動化掃描到的漏洞，安全測試團隊需要綜合運用PoC （漏洞驗證程序）和EXP（漏洞利用程序）裡的各種工具、Selenium腳本、及策略，透過手動測試的方式，按照計畫所製定的標準與範圍，先後對應用程式進行黑盒、白盒、以及灰盒（按需）等類型的利用與測試。參考OWASP Top 10，典型的測試要點包括：
- 注入滲透
- 伺服器配置審查
- 模糊輸入
- 數據篡改
- 文件上傳
- 跨站腳本（XSS）
透過模擬攻擊的真實場景，我們可以得知被測應用的抗攻擊能力、以及攻擊得逞後，可能洩漏的資料、竄改的系統、以及中斷的服務。值得一提的是，安全測試人員除了使用手動測試技術，也可以利用自動化工具模擬人類的交互，以社會工程的方式非法獲取應用的存取授權。
評估報告
在完成了利用測試之後，安全測試團隊應根據記錄到的漏洞，計算潛在系統的損失、參考CVSS評分、以及核對如下維度實施漏洞分類，影響分析，優先級評定，以及按需進行風險計算。
- IAM – 基於角色的存取控制（RBAC）、SSO、MFA
- 資料安全– 資料加密、資料分級、資料外洩保護（DLP）
- 可見度– 日誌記錄（SIEM）、監控、警報
- 配置– 安全設定、存取控制清單（ACL）、IP白名單、存取的第三方應用
- 網路– WAF、入侵偵測、DDoS保護
- 合規–認證（ISO 27001、SOC 2 Type II、PCI DSS等）、隱私（PII、HIPAA、GDPR、CCPA等）
此外，透過結果保存與隨選截圖的方式，安全測試團隊最終出具高準確度的報告，並向利害關係人給予修復建議。
整改重測
針對被確認的漏洞，應用程式使用團隊將協同安全團隊著手整改。而對於實難整改的部分，則可以按需引入雲端存取安全代理程式（CASB）和雲端安全態勢管理（CSPM）等元安全組件以輔助加強。完成後，安全測試團隊將進入重新測試的階段，以確認漏洞是否已修復，且無新的漏洞產生，進而達到提高SaaS應用程式的整體安全態勢。
定期安全測試
我們常說：「安全態勢只是一時，並非一世」。這個概念在SaaS應用安全測試領域亦然。為此，我們需要透過定期進行安全測試（有時也稱為道德駭客攻擊），來驗證應用的安全預防措施的持續有效。
同時，我們也需要定期從開源情報（OSINT）處，收集並獲悉有關被測SaaS應用的其他公開報道、共享資訊、客戶與合作夥伴反饋等，以根據各種突發的事件，及時開展安全測評工作。
整體而言，我們對於SaaS應用安全就是要本著主動發現、及時管控、按需評測的態度，保障SaaS應用在整個生命週期的安全態勢。