常见API接口漏洞

了解接口常见漏洞，将帮助你在测试接口获取更多的思路。

信息披露

信息可能会在 API 响应或公共来源（如代码存储库、搜索结果、新闻、社交媒体、目标网站和公共 API 目录）中披露。

敏感数据可以包含攻击者可以利用的任何信息。

例如：使用WordPress API的网站可能会在不知不觉中与导航到API路径的任何人共享用户信息。/wp-json/wp/v2/users

GET https://www.sitename.org/wp-json/wp/v2/users

[{"id":1,"name":"Administrator", "slug":"admin"}],
{"id":2,"name":"Vincent Valentine", "slug":"Vincent"}]

然后，可以使用这些 slug 尝试以公开用户的身份登录，并进行暴力破解、凭据填充或密码喷射攻击。

错误消息可帮助 API 使用者排查其与 API 的交互问题，并允许 API 提供者了解其应用程序的问题。但是，它也可以揭示有关资源、用户和 API 底层体系结构（例如 Web 服务器或数据库的版本）的敏感信息。

通常，您可以通过与 API 终端节点交互并分析响应来收集最多信息。API 响应可以显示标头、参数和详细错误中的信息。其他良好的信息来源是在侦察期间收集的 API 文档和资源。

断开的对象级别授权

当 API 提供者允许 API 使用者访问他们无权访问的资源时，就会发生 BOLA 漏洞。

例如：假设我们被授权仅访问用户Cloud Strife。我们会向 https://bestgame.com/api/v3/users?id=5501 发送初始 GET 请求

{
 "id": "5501",
 "first_name": "Cloud",
 "last_name": "Strife",
 "link": "https://www.bestgame.com/user/strife.buster.97",
 "name": "Cloud Strife",
 "dob": "1997-01-31",
 "username": "strife.buster.97"
}

在这种情况下，我们可能会使用另一个接近 Cloud ID 5501 的标识号来检查这些问题。假设我们能够获取有关其他用户的信息。

通常，您可以通过了解 API 的资源结构并尝试访问不应访问的资源来测试 BOLA。通过检测 API 路径和参数中的模式，您应该能够预测其他潜在资源。

BOLA 可能是一个低悬的 API 漏洞，您可以使用模式识别轻松发现它，然后通过几个请求来刺激它。其他时候，由于对象 ID 的复杂性以及用于获取其他用户资源的请求，发现起来可能非常复杂。

用户身份验证中断

用户身份验证中断是指： API 身份验证过程中的任何弱点。当 API 提供程序未实现身份验证保护机制或未正确实现机制时，通常会发生这些漏洞。

RESTful API应该是无状态的。为了成为无状态的，提供者不需要记住从一个请求到另一个请求的使用者。要使此约束起作用，API 通常需要用户经历注册过程才能获得唯一的令牌。然后，用户可以在请求中包含令牌，以证明他们有权发出此类请求

例如：为了确定代币生成过程是否较弱，我们可以收集代币样本并分析它们的相似性。如果令牌生成过程不依赖于高级别随机性或熵，我们有可能创建自己的令牌或劫持别人的令牌。

令牌处理可以是令牌的存储、通过网络传输令牌的方法、硬编码令牌的存在等。我们也许能够在 JavaScript 源文件中检测硬编码令牌，或者在分析 Web 应用程序时捕获它们。捕获令牌后，我们可以使用它来访问以前隐藏的终结点或绕过检测。如果 API 提供者将身份归因于令牌，我们将通过劫持被盗令牌来承担身份。

其他可能具有自己的一组漏洞的身份验证过程包括注册系统的各个方面，例如密码重置和多重身份验证功能。例如，假设密码重置功能要求您提供电子邮件地址和六位数代码来重置密码。好吧，如果API允许您发出任意数量的请求，则只需发出一百万个请求即可猜测代码并重置任何用户的密码。一个四位数的代码只需要 10，000 个请求。

由于 REST API 的无状态性质，公开的 API 密钥等效于发现用户名和密码。通过使用公开的 API 密钥，你将代入与该密钥关联的角色。

过度的数据泄露

过度数据泄露是指 API 端点响应的信息多于满足请求所需的信息。

当存在此漏洞时，可能相当于向某人询问其姓名，并让他们使用其姓名，出生日期，电子邮件地址，电话号码以及他们认识的每个人的身份进行响应。

假设我请求了自己的帐户信息，并提出了以下请求：

GET /api/v3/account?name=Cloud+Strife

# respone 
{
 "id": "5501",
 "first_name": "Cloud",
 "last_name": "Strife",
 "privilege": "user",
 "representative": [
 "name": "Don Corneo",
 "id": "2203"
 "email": "dcorn@gmail.com",
 "privilege": "super-admin"
 "admin": true
 "two_factor_auth": false,
 }

要检测过多的数据泄露，您需要做的就是测试目标 API 端点并查看响应中发送的信息

缺乏资源和速率限制

速率限制在 API 的货币化和可用性中起着重要作用

。如果不限制使用者可以发出的请求数量，API 提供商的基础设施可能会被请求淹没。没有足够资源的请求过多将导致提供商的系统崩溃并变得不可用。例如：拒绝服务（DoS）状态RapidAPI允许每月免费500个请求，但付费客户每月允许1，000个请求。

DoS是Denial of Service的简称，即拒绝服务，造成DoS的攻击行为被称为DoS攻击，其目的是使计算机或网络无法提供正常的服务。最常见的DoS攻击有计算机网络带宽攻击和连通性攻击。

DoS攻击是指恶意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。这些服务资源包括网络带宽，文件系统空间容量，开放的进程或者允许的连接。这种攻击会导致资源的匮乏，无论计算机的处理速度多快、内存容量多大、网络带宽的速度多快都无法避免这种攻击带来的后果。

一旦您被限制提出其他请求，就该尝试查看如何实施速率限制了。您可以通过添加或删除参数、使用其他客户端或更改 IP 地址来绕过它吗？

中断的功能级别授权

中断的功能级别授权（BFLA）：

是一个角色或组的用户能够访问另一个角色或组的 API 功能的漏洞。

BFLA 与 BOLA 类似，不同之处在于不是涉及访问资源的授权问题，而是执行操作的授权问题。

当 API 中存在 BOLA 漏洞时，您可能能够访问该信息其他帐户，例如付款历史记录、用户名、电子邮件地址和帐号。

如果存在 BFLA 漏洞，您可能能够转账并实际更新帐户信息。相反，该功能可以基于 HTTP 请求方法，例如、、和。如果提供程序不限制使用者可以使用的 HTTP 方法，则只需使用其他方法进行 a 即可指示 BFLA 漏洞。

GET
POST
PUT
DELETE
unauthorized request

发现 BFLA 的最简单方法是查找管理 API 文档，并以测试管理功能和能力的非特权用户身份发送请求。如果特权操作的 API 文档不可用，则需要在测试用于执行特权操作的终结点之前发现或对其进行反向工程。

质量分配

当 API 使用者在其请求中包含比应用程序预期更多的参数，并且应用程序将这些参数添加到代码变量或内部对象时，就会发生批量分配。“我觉得这看起来像参数污染”。

例如：应用程序可能具有帐户更新功能，用户应仅使用该功能来更新其用户名、密码和地址。如果使用者可以在与其帐户相关的请求中包含其他参数（如帐户权限级别或敏感信息（如帐户余额），并且应用程序接受这些参数而不根据允许操作的白名单检查它们，则使用者可以利用此弱点来更改这些值。

// Imagine an API is called to create an account with parameters for 

"User" and "Password":

{
"User": "scuttleph1sh",
"Password": "GreatPassword123"
}
//While reading the API documentation regarding the account creation 
//process, suppose you discover that there is an additional key, "isAdmin", that 
//consumers can use to become administrators. You could use a tool like 
//Postman or Burp Suite to add the attribute to a request and set the value 
//to true:
{
"User": "scuttleph1sh",
"Password": "GreatPassword123",
"isAdmin": true
}

您可以通过在 API 文档中查找感兴趣的参数，然后将这些参数添加到请求中来发现批量分配漏洞。查找用户帐户属性、关键功能和管理操作中涉及的参数。拦截 API 请求和响应也可以揭示值得测试的参数。此外，您可以在 API 请求中猜测参数或模糊参数。

安全配置错误

安全配置错误包括开发人员在 API 的支持安全配置中可能犯的所有错误。例如，如果 API 的支持安全配置揭示了未修补的漏洞，则攻击者有可能利用已发布的漏洞轻松“pwn”API 及其系统。

安全配置错误实际上是一组弱点，包括配置错误的标头、配置错误的传输加密、使用默认帐户、接受不必要的 HTTP 方法、缺乏输入清理和详细的错误消息。

缺乏输入清理可能允许攻击者将恶意负载上传到服务器。

例如，如果使用上传端点将上传的文件传递到 Web 目录，则它可能允许上传脚本。导航到文件所在的 URL 可以启动脚本，导致对 Web 服务器的直接外壳访问。

API 提供程序使用标头为使用者提供处理响应和安全要求的说明。配置错误的标头可能导致敏感信息泄露、降级攻击和跨站点脚本攻击。

例如，采用以下响应：

HTTP/ 200 OK
--snip--
X-Powered-By: VulnService 1.11 // reveal backend tech => search exploits
X-XSS-Protection: 0 // could be changed to 1
X-Response-Time: 566.43
//If the X-Response-Time header has a consistent response time for nonexistent records, for example, but increases 
// its response time for certain other records, this could be an indication that those records exist.
HTTP/UserA 404 Not Found
--snip--
X-Response-Time: 25.5
HTTP/UserB 404 Not Found
--snip--
X-Response-Time: 25.5
HTTP/UserC 404 Not Found
--snip--
X-Response-Time: 510.00

在这种情况下，UserC 的响应时间值是其他资源的响应时间的 20 倍。由于样本量如此之小，很难明确地断定 UserC 存在。

例如，您知道像这样的虚假帐户的平均X响应时间为ms。您还知道，您现有的帐户 /user/account/1021 收到的 X 响应时间为。如果您随后发送了请求，强制所有帐号从到，您可以查看结果并查看哪些帐号导致响应时间大幅增加。/user/account/thisdefinitelydoesnotexist87625.5510.0010002000

任何向使用者提供敏感信息的 API 都应使用传输层安全性（TLS）来加密数据。即使 API 仅在内部、私有或合作伙伴级别提供，使用 TLS（加密 HTTPS 流量的协议）也是确保 API 请求和响应在通过网络传递时受到保护的最基本方法之一。配置错误或缺少传输加密可能会导致 API 用户以明文形式跨网络传递敏感的 API 信息。然后攻击者可以使用MITM攻击来利用它。

当服务使用默认帐户和凭据并且默认值已知时，攻击者可以使用这些凭据代入该帐户的角色。这可能允许他们访问敏感信息或管理功能，可能导致支持系统。

最后，如果 API 提供程序允许不必要的 HTTP 方法，则应用程序无法正确处理这些方法或导致敏感信息泄露的风险会增加。

您可以使用 Web 应用程序漏洞扫描程序（如 Nessus、Qualys、OWASP ZAP 和 Nikto）检测其中的几个安全错误配置。这些扫描程序将自动检查 Web 服务器版本信息、标头、cookie、传输加密配置和参数，以查看是否缺少预期的安全措施。如果您知道要查找的内容，也可以通过检查标头、SSL 证书、cookie 和参数来手动检查这些安全配置错误。

注入

当请求传递到 API 的支持基础结构并且 API 提供程序不筛选输入以删除不需要的字符（此过程称为输入清理）时，存在注入缺陷。详细的错误消息、HTTP 响应代码和意外的 API 行为都可能是您可能发现了注入缺陷的线索。

API 可能会将该有效负载直接传递到后端 SQL 数据库，其中 OR 1=0 语句将失败（因为 1 不等于 0），从而导致一些 SQL 错误：

POST /api/v1/register HTTP 1.1
Host: example.com
--snip--
{
"Fname": "hAPI",
"Lname": "Hacker",
"Address": "' OR 1=0--",
}

注入漏洞通常辅以其他漏洞，例如输入清理不良。在以下示例中，您可以看到一种代码注入攻击，该攻击使用 API GET 请求来利用弱查询参数。在这种情况下，弱查询参数将请求的查询部分中的任何数据直接传递到底层系统，而不先对其进行清理：以下响应正文显示 API 端点已纵为显示主机的 /etc/passwd 文件，从而显示系统上的用户：

GET http://10.10.78.181:5000/api/v1/resources/books？show=/etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin

查找注入缺陷需要认真测试 API 端点，注意 API 的响应方式，然后精心制作尝试操纵后端系统的请求。与目录遍历攻击一样，注入攻击已经存在了几十年，因此有许多标准的安全控制措施来保护 API 提供程序免受这些攻击。

资产管理不当

当组织公开 API 时，会发生不正确的资产管理已停用或仍在开发中。仍在开发的 API 通常不如生产 API 对应项安全。

资产管理不当会导致其他漏洞，例如数据过度暴露、信息泄露、批量分配、速率限制不当和 API 注入等。

您可以通过密切关注仓库中过时的 API 文档、更改日志和版本历史记录来发现不当的资产管理。

组织通常在其终结点名称中包含版本控制信息，以区分较旧版本和较新版本，例如等。仍在开发中的 API 通常使用诸如 .如果您知道 API 现在正在使用 apiv3.org/admin 但 API 文档的一部分提到了 apiv1.org/admin，则可以尝试测试不同的端点以查看 apiv1 或 apiv2 是否仍处于活动状态。此外，组织的更新日志可能会披露 v1 更新或停用的原因。如果您有权访问 v1，则可以测试这些弱点/v1/, /v2/, /v3//alpha/, /beta/, /test/, /uat/, and /demo/

在使用文档之外，您还可以通过使用猜测、模糊测试或暴力请求来发现不正确的资产管理漏洞。观察 API 文档或路径命名方案中的模式，然后根据您的假设发出请求。

业务逻辑漏洞

业务逻辑漏洞（也称为业务逻辑缺陷或 BLF）是攻击者可以恶意使用的应用程序的预期功能。

例如，如果 API 具有不验证编码有效负载的上传功能，则只要任何文件已编码，用户就可以上传该文件。这将允许最终用户上传和执行任意代码，包括恶意负载。在这些情况下，组织基本上依赖于信任作为一种安全控制，期望消费者采取仁慈的行为。不幸的是，即使是善良的 API 使用者也会犯错误，从而导致应用程序受损。

您可以在 API 文档中搜索业务逻辑漏洞的迹象。像下面的陈述应该照亮你头顶的灯泡：

“仅使用功能 X 来执行功能 Y。” “不要对端点 Y 执行 X。” “只有管理员才能执行请求 X。”

当您攻击他们的 API 时，请确保不服从此类请求以测试是否存在安全控制。

例如，请考虑用户通常用来对其帐户进行身份验证的 Web 应用程序身份验证门户。假设 Web 应用程序发出了以下 API 请求：

POST /api/v1/login HTTP 1.1
Host: example.com
--snip--
UserId=hapihacker&password=arealpassword!&MFA=true

我们有可能通过简单地将参数更改为来绕过多因素身份验证。MFAfalse

测试业务逻辑缺陷可能具有挑战性，因为每个业务都是独一无二的。自动扫描程序将很难检测到这些问题，因为这些缺陷是API预期用途的一部分。您必须了解业务和 API 的运作方式，然后考虑如何利用这些功能来发挥自己的优势。以对抗的心态研究应用程序的业务逻辑，并尝试打破任何假设被制造

总结

熟悉这些漏洞非常重要，这样您就可以轻松识别它们，在参与渗透测试期间利用它们，并将其报告给组织，以防止犯罪分子将您的客户拖入头条新闻。现在您已经熟悉了 Web 应用程序、API 及其弱点。

原文链接：https://blog.csdn.net/summer_fish/article/details/130455076