自动 API 攻击工具

Imperva 的可定制 API 攻击工具将 API 规范作为输入，并基于该规范生成并运行攻击作为输出。

该工具能够解析 API 规范，并根据 API 规范中定义的内容创建模糊测试攻击场景。每个端点都会被注入根据规范边界内生成的巧妙值，以及边界之外的值，然后发送相应的请求，并详细报告其成功或失败。您还可以扩展它以运行各种安全攻击向量，例如非法资源访问、XSS、SQLi 和 RFI，这些攻击针对现有端点，甚至不存在的端点。 无需人工干预。只需运行工具即可获取结果。

该工具可以轻松扩展以满足各种需求，例如针对想要测试其 API 的开发者，或希望对其公共 API 定期运行漏洞或正向安全扫描的组织。它构建时考虑了 CI/CD。

要求

Java 8 或更高版本
Gradle

运行

从 GitHub 检出代码，然后运行 ./gradlew build（或在 Windows 上运行 gradlew.bat build）
您可以在 build/libs 文件夹下找到可执行的 jar 文件
运行 java -jar imperva-api-attack-tool.jar 查看帮助菜单

制作 Linux 可执行文件

将 runnable.sh 文件从 src/main/resources 文件夹复制到 jar 文件所在的同一目录。
然后运行：cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
您可以将 apia-attack.sh 文件当作常规可执行文件使用

用法

必需参数：

-f, --specFile=specFilePath

要运行的 API 规范文件（swagger 2.0）。JSON/YAML 格式。为获得更好结果，请确保为每个端点正确定义了响应。

-n, --hostName=hostName

要连接的主机名。也可以是 IP 地址

-s, --hostScheme=hostScheme

将使用此方案连接到主机；例如：https 或 http

可选参数：

-p, --hostPort=hostPort

主机监听 API 调用的端口，默认值：443

-ph, --proxyHost=proxyHost

指定通过代理发送请求的代理主机

-pp, --proxyPort=proxyPort

代理端口，默认值：80

-rcn, --addNegativeRC=responseCode[,responseCode...]

在负面攻击（例如错误值攻击）中额外接受的响应码。支持多个值，用逗号分隔

-rcp, --addPositiveRC=responseCode[,responseCode...]

在正向检查（合法值攻击）中额外接受的响应码。支持多个值，用逗号分隔

典型使用场景：

您想要检查您的 API 是否受到 API 安全解决方案的保护。

示例运行：api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403

我们添加了 403 响应码作为负面检查的合法响应码。这是因为 API 安全解决方案会阻止此类请求并返回 403 状态。而规格文件本身并不一定会为其任何端点定义 HTTP 码为 403 的响应。这将使此类响应变得合法，尽管它们不在规格中，并在未收到来自负面检查的此类响应时向您发出警报。这种情况意味着您的 API 安全解决方案未能提供保护。
您想要检查您的代理如何缓解 API 攻击，但后面没有实际站点。

示例运行：api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404

这次我们为正向场景添加了 404 状态码。这样一来，当某个场景未被阻止时，我们将不会报告失败，而是接受合法的 404（资源未找到）响应。
您想要检查您的 API 是否正确处理所有输入。此外，您希望每天晚上运行它，甚至是在开发者每次推送新代码到项目后运行。

示例运行：api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

这次我们没有任何排除项。API 规格文件必须精确声明其响应码。该工具只会接受这些响应码作为合法响应，否则将失败检查。有关检查失败条件的更多信息，请参见下文。在 Jenkins 作业（或任何其他您喜欢的 CI/CD 软件）中运行上述命令，该作业将由 cron 或仓库代码推送活动触发。确保安装了 TestNG 插件，它会解析写入 build/testng-results 的结果，以便在 CI/CD 场景中获得更好的可见性。
您想要检查此 API 是否容易受到模糊测试攻击。只需运行工具并检查报告的错误。

示例运行：api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

检查失败条件

该工具验证生成的请求响应码是否与 swagger 中声明的响应码匹配。然而，
正向检查：如果出现明显的错误（代码为 5xx），即使该响应码未在规格中定义，我们仍会判定检查失败，除非您提供了覆盖。
负面检查：如果响应不是合法的错误（1xx、2xx、5xx），则检查失败，除非您提供了覆盖。如果合法的错误码不在规格中，检查也会失败。
您可以在 swagger 的响应部分使用 'default' 定义，但不建议这样做。始终精确地定义您的合法答案。

检查失败条件

该工具验证生成的请求响应码是否与 swagger 中声明的响应码匹配。然而，
正向检查：如果出现明显的错误（代码为 5xx），即使该响应码未在规格中定义，我们仍会判定检查失败，除非您提供了覆盖。
负面检查：如果响应不是合法的错误（1xx、2xx、5xx），则检查失败。除非您提供了覆盖。如果合法的错误码不在规格中，检查也会失败。
您可以在 swagger 的响应部分使用 'default' 定义，但不建议这样做。始终精确地定义您的合法答案。

预期输出：

该工具使用 testng 报告框架，因此任何处理 testng 运行的插件都可以在此使用。只需注意结果写入 build/testng-results 文件夹。当然，这可以更改。
该工具根据其检查套件生成请求，每个请求检查特定内容。因此每个检查都会在命令行输出中显示所有相关细节，包括检查内容、响应内容以及是否符合预期。
任何错误的请求都将存储在 bad_requests 文件夹中，以便您稍后进行分析（例如，如果运行在 CI/CD 服务器上，并且您无法立即访问机器）。
最后，您将收到一个摘要。

失败的负面检查示例：

***** Testing API Endpoint *****
***** Test ID: 1575128763286-74212
Testing: Bad Property: /username (STRING), value: {, URL encoded: %7B
--> Url: /user/{
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/{ [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"username":"string","firstName":"string","lastName":"string","email":"string","password":"string","phone":"string","userStatus":0}

检查为何失败？尽管请求未包含合法 URL，却得到了 200 响应。

另一个示例：

***** Testing API Endpoint *****
***** Test ID: 1575128763286-25078
Testing: Bad Property: /body/quantity (INTEGER), value: 0.4188493, URL encoded: 0.4188493
--> Url: /store/order
--> Method: POST
--> Headers: []
--> Body: {"petId":-2511515111206893939,"quantity":0.4188493,"id":698757161286106823,"shipDate":"�s","complete":"true","status":"approved"}
----------**----------
Request was: POST /store/order [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"petId":0,"quantity":0,"shipDate":"2019-11-30T15:46:03Z","status":"placed","complete":false}

服务器期望接收整数，但却接受了一个双精度值。这可能是一个尝试利用服务器缓冲区溢出的好时机。

成功的检查示例：

***** Testing API Endpoint *****
***** Test ID: 1575128763137-43035
Testing: /user/{username}
--> Url: /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+(
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+( [Accept: application/json], Response status code: 404
Response (non parsed):
{"statusCode":404,"error":"Not Found","message":"Not Found"}

我们提供了一个不存在但根据 API 规范是合法的用户名。服务器知道如何处理此请求并返回合法错误。

支持的检查场景

这里我们将使用术语 端点，指 URL 端点和方法元组。

正向场景

对于每个端点，使用为其所有参数生成的值创建请求。这些值随机生成，但遵守 API 规范中定义的规则。
对于每个端点，仅使用所需的参数创建请求，这些参数的值按照上述方式生成。

负面场景

对于每个端点，创建多个请求，每个请求检查不同的参数。工具通过在被检查的参数中注入随机错误输入值，并用按照正向场景中生成的值填充其余参数来实现此目的。

持续努力

我们正在努力将其他场景迁移到开源工具中，以造福社区。敬请关注更新。

可扩展性

该工具以易于扩展其模糊测试和请求生成功能的方式编写，以满足您的特定需求。欢迎通过创建拉取请求提出任何可能使其他人受益的添加内容。

获取帮助

如果您对该库有疑问，请务必查看源代码文档。如果仍有问题，请通过电子邮件联系我：boris.serebro(at)imperva(dot)com。

报告错误

请创建一个 Git Issue 并尽可能多地提供信息。如果可能，请提供说明您遇到的问题的示例代码。如果您仅在特定仓库上遇到错误，请尽可能提供链接。请不要为寻求帮助而创建 Git Issue，仅用于报告错误。

automatic-api-attack-tool

最受欢迎