RESTful Api 規範在漏洞掃描器中很重要
APIGit
2023-07-27
如何發現 Web 應用程序中的漏洞？
如今，越來越多的公司提供 Web API 來訪問其服務。他們通常遵循 REST 風格。這樣的 RESTful Web 服務看起來就像一個常規的 Web 應用程序。它接受 HTTP 請求，執行一些操作，然後回复 HTTP 響應。主要區別之一是回复通常不包含要在網絡瀏覽器中呈現的 HTML。相反，回复通常包含更易於其他應用程序處理的格式（例如 JSON 或 XML）的數據。
不幸的是，由於 RESTful Web 服務仍然是 Web 應用程序，因此它可能包含 Web 應用程序的典型安全漏洞，例如 SQL 注入、XXE 等。識別 Web 應用程序中的安全問題的方法之一是使用 Web 安全掃描器。幸運的是，由於 RESTful Web 服務仍然是一個 Web 應用程序，因此我們可以使用 Web 安全掃描器來查找 Web API 中的安全問題。
有幾種著名的網絡安全掃描儀。其中之一是 w3af。
w3af如何發現漏洞？
w3af 是一個 Web 應用程序攻擊和審核框架。該項目的目標是創建一個框架，通過查找和利用所有 Web 應用程序漏洞來幫助您保護 Web 應用程序。該框架包含數百個插件，有助於查找漏洞。
爬網插件使用不同的技術來識別新的 URL、表單以及在審核和暴力破解階段可能使用的任何其他資源。換句話說，這些插件瀏覽應用程序並嘗試發現要測試的入口點。
審核插件使用爬網插件創建的知識來查找遠程 Web 應用程序和 Web 服務器上的漏洞。這些插件測試發現的漏洞入口點。
通過啟用一些插件，您可以發現一些漏洞，但不多。這是我的 spring-boot web 項目的結果。網絡掃描器通常會嘗試瀏覽網站以查找所有可用的頁面和參數，然後可以測試這些頁面和參數是否存在漏洞。對於典型的網站，掃描器通常從主頁開始，並在 HTML 代碼中查找指向其他頁面的鏈接。但這種方法不適用於 Web API，因為 API 端點通常不提供 HTML 數據，並且 API 通常不會在回復中相互引用。
{
"items": [
{
"href": "/scans/1/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/1",
"id": 1,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/2",
"id": 2,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/1/kb/3",
"id": 3,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/4",
"id": 4,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
RESTful Api 規範對於掃描儀很重要
我們如何獲取要掃描的 API 端點和參數的列表？主要有兩種方式：
- #1 RESTful API 規範 Web 服務可能具有 OpenAPI 規範，該規範描述了所有端點、參數、響應、身份驗證方案等。此類規範通常由開發人員提供。
- #2 代理 使用代理，我們可以捕獲客戶端發送到 API 端點的 HTTP 請求。然後，我們可以解析捕獲的請求並提取有關參數的信息。
#1 看起來比 #2 好得多。在完美的世界中，每個 Web 服務都有一個始終可用且最新的 OpenAPI 規範。但在現實世界中，這種情況似乎並不經常發生。開發人員可能會更改 API，但忘記更新規範，或者由於某種原因他們沒有公開提供規範。在大多數情況下，公開可用的 REST API 具有人類可讀的文檔，這很好，但通常很難以自動化方式使用。
- 但是，APIGIT 可以讓這一切變得更容易。
APIGIT 是一個協作平台，以其原生 Git 支持而脫穎而出，簡化了 API 開發流程和版本控制，使用戶能夠輕鬆設計、記錄、模擬、測試和共享 API。該平台的可視化 OpenAPI 編輯器與其原生 Git 支持相結合，使團隊能夠輕鬆、無縫、高效地協作和共享工作。
w3af 如何根據 RESTful Api 規範查找漏洞？
這是我的 RESTful Api 規範的一部分。
"paths": {
"/find_pet": {
"get": {
"summary": "List pet",
"operationId": "listPet",
"tags": [
"pet"
],
"parameters": [
{
"name": "version",
"in": "query",
"description": "Get pet by version",
"required": true,
"type": "string"
}
],
通過啟用相關插件並使用 RESTful Api 規範提供：
[crawl.open_api]
custom_spec_location = /var/log/wvs/openapi2.json
no_spec_validation = True我們可以發現更多的漏洞。
{
"items": [
{
"href": "/scans/0/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/1",
"id": 1,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/0/kb/2",
"id": 2,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/3",
"id": 3,
"name": "Open API specification found",
"url": "file:///var/log/wvs/openapi2.json"
},
{
"href": "/scans/0/kb/4",
"id": 4,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/5",
"id": 5,
"name": "Cross site scripting vulnerability",
"url": "http://192.168.1.65:8181/find_pet"
},
{
"href": "/scans/0/kb/6",
"id": 6,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/_pet"
},
{
"href": "/scans/0/kb/7",
"id": 7,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/find_"
},
{
"href": "/scans/0/kb/8",
"id": 8,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/9",
"id": 9,
"name": "Strange HTTP response code",
"url": "http://192.168.1.65:8181/%2Fbin%2Fcat+%2Fetc%2Fpasswd_pet"
},
{
"href": "/scans/0/kb/10",
"id": 10,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
我們來談談crawl.open_api插件。該插件的第一個版本試圖在一個眾所周知的位置找到 OpenAPI 規範，例如：
/api/openapi.json
/api/v2/swagger.json
/api/v1/swagger.yaml
等等。這是一個非常好的功能。如果您有多個 Web 服務需要測試，並且它們的 API 規範在眾所周知的位置可用，那麼您只需向掃描儀提供主機名即可。掃描器將自行找到所有 API 端點，然後對其進行測試。不幸的是，有時 Web 服務不提供 API 規範，而 custom_spec_file 參數允許設置 OpenAPI 規範的本地路徑。用戶可以使用 API 文檔並自行構建規範，或者有時規範是公開可用的，但不在眾所周知的位置。
