如何自動化安全測試 Web REST API

如何自動化安全測試 Web REST API

這篇文章主要說明網站安全自動化測試的幾種方式與優缺點

能夠在早期就發現安全問題盡快修復是每個研發團隊的目標

安全自動化測試要做到有效率又有效果又要做到在開發前期就發現確實是挑戰

我們針對Web REST API的自動化測試作一些討論 (不包含靜態代碼掃描)

我們將討論一些常見測試工具的優缺點與使用場景 Jmeter, SoapUI, AppScan, Zap, Selenium, Peach Fuzzer

網站安全測試挑戰為何

網站服務的本身基本就是 Http Request 與 Http Response 的過程

要達到安全自動化測試主要挑戰分兩大部分說明

 Http Request

• 如何將所有http request參數自動化列出
• 將列出的參數輸入惡意攻擊的資料, 例如 XSS, SQL injection, 過長的email, Buffer Overflow字串…

Http Response

• 如何分析判斷惡意攻擊的資料輸入是有效的? XSS 是否成功? SQL injection 是否成功?

分析判斷 Http Response是否成功是筆者認為最困難的部分, 因為這會關係到誤判率

我們當然不希望電腦自動化測試完分析出100個問題, 最後驗證只有5個是真正的安全問題

測試方法

如果針對 Web REST API 的安全自動化測試來說, 這幾種方式與工具都有所優缺點, 分述如下

Jmeter

http://jmeter.apache.org/

針對網站功能性與效能測試 Jmeter 是筆者十分建議的工具

但是如果回到  Web REST API 的安全測試, 我們必須回答下列問題

 Http Request

• 如何將所有http request參數自動化列出?

這部分 Jmeter 無法完全處理, 只能靠人工自行定義Jmeter 的腳本與參數設定

• 如何將列出的參數輸入惡意攻擊的資料, 例如 XSS, SQL injection, 過長的email, Buffer Overflow字串…?

這部分只要利用惡意攻擊的資料庫 FuzzDB, 透過外部參數的方式傳入給Jmeter 就可以解決

https://github.com/fuzzdb-project/fuzzdb

Http Response

• 如何分析判斷惡意攻擊的資料輸入是有效的? XSS 是否成功? SQL injection 是否成功?

這部分是筆者認為最難的部分, 因為要精準的判斷攻擊是否成功需要一些智慧分析引擎

Jmeter 僅能透過 Regular Expression 的方式來判斷, 換句話說如果要使用 Jmeter 必須自行建立判斷的規則資料庫

SoapUI

https://www.soapui.org/

SoapUI可以說是 Jmeter 的競爭者

SoapUI 有免費版本與付費版本

SoapUI 只是工具名稱, 網站服務不一定需要 Soap才能用 SoapUI

介面設計上因為功能較為豐富, 筆者覺得要上手會有些找不到 (個人使用習慣, 筆者習慣Jmeter 簡單的介面)

如果跟Jmeter 相同功能的話, 為什麼特別提這個工具呢?

主要是這個工具SoapUI額外提供下列這些安全測試的功能

https://www.soapui.org/soapui-projects/ws-security.html

• SQL Injection : tries to exploit bad database integration coding
• XPath Injection : tries to exploit bad XML processing inside your target service
• Boundary Scan : tries to exploit bad handling of values that are outside of defined ranges
• Invalid Types : tries to exploit handling of invalid input data
• Malformed XML : tries to exploit bad handling of invalid XML on your server or in your service
• XML Bomb : tries to exploit bad handling of malicious XML request (be careful)
• Malicious Attachment : tries to exploit bad handling of attached files
• Cross Site Scripting : tries to find cross-site scripting vulnerabilities
• Custom Script : allows you to use a script for generating custom parameter fuzzing values

另外還有一個版本ReadyAPI, 但是筆者建議使用 SoapUI , 因為ReadyAPI包含其他功能算是整合的工具

筆者喜歡簡單特定用途的工具, 或許筆者研究不夠透測 SoapUI Security Testing 目前對於 REST JSON的變數測試似乎還不支援

http://community.smartbear.com/t5/SoapUI-Open-Source/How-to-add-security-tests-to-REST-requests-with-JSON-content/m-p/34487#M14204

Zap or AppScan + Selenium

待完成

這個方式最大的優點是從最終使用者觀點出發進行的測試

透過瀏覽器瀏覽的過程導引 ZAP在整個過程中進行安全測試

最大的缺點是自動化測試的過程很容易受到 UI 變動, UI 載入時間等的影響

所有  Selenium 會遇到的自動化測試失敗原因, 在這個情境下都會遇到

因此另外的折衷方案是透過 ZAP 的API 直接對網站測試, 如下小節描述

ZAP + API

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Peach Fuzzer

http://community.peachfuzzer.com/

http://www.peachfuzzer.com/solutions/peach-professional/

將 Peach Fuzzer 放在這裡有點不是完全對等

首先先釐清 Peach Fuzzer 可以做什麼不可以做什麼

• 可以： Network or Application 的Exploit , buffer overflow or Crash 的弱點測試
• 可以:  Fuzz 智慧引擎, 可以針對當下的情境, 動態改變測試的步驟與測試的資料
• 不可以: 因為Peach Fuzzer 不是特別針對Http 的安全測試設計, 因此無法執行 XSS, SQL injection 等 OWASP 安全威脅測試

那為什麼要特別提 Peach Fuzzer 呢?

因為許多的弱點都是因為第三方軟件漏洞所導致

這些漏洞多半是因為 Buffer overflow, Stack overflow or crash 等原因造成

因此 Peach Fuzzer 可以透過這樣的測試找出潛在 Buffer Overflow 等問題, 做到 Zero Day 的防護測試