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 提供程序未实现身份验证保护机制或未正确实现机制时，通常会发生这些漏洞。

正如我们从第2章讨论的REST 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 端点并查看响应中发送的信息。加微信好友hackctf55进渗透交流群。

缺乏资源和速率限制

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

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

中断的功能级别授权

中断的功能级别授权 （BFLA） 是一个角色或组的用户能够访问另一个角色或组的 API 功能的漏洞。

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

当 API 中存在 BOLA 漏洞时，您可能能够访问该信息 其他帐户，例如付款历史记录、用户名、电子邮件地址和帐号 如果存在 BFLA 漏洞，您可能能够转账并实际更新帐户信息。相反，该功能可以基于 HTTP 请求方法，例如 、、 和 。如果提供程序不限制使用者可以使用的 HTTP 方法，则只需使用其他方法进行 a 即可指示 BFLA 漏洞。

GETPOSTPUTDELETEunauthorized 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 exploitsX-XSS-Protection: 0 // could be changed to 1X-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.5HTTP/UserB 404 Not Found--snip--X-Response-Time: 25.5HTTP/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.1Host: 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/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin

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

资产管理不当

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

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

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点！真正的体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

mg-k7lIaoId-1715806124122)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点！真正的体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！