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 文档并自行构建规范，或者有时规范是公开可用的，但不在众所周知的位置。
