【web安全】API接口安全风险大盘点：常见漏洞一览

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

正如我们从第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 漏洞。

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 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 注入等。

您可以通过密切关注仓库中过时的 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.1Host: example.com--snip--UserId=hapihacker&password=arealpassword!&MFA=true

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

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

总结

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

学习计划安排

我一共划分了六个阶段，但并不是说你得学完全部才能上手工作，对于一些初级岗位，学到第三四个阶段就足矣~

这里我整合并且整理成了一份【282G】的网络安全从零基础入门到进阶资料包，需要的小伙伴可以扫描下方CSDN官方合作二维码免费领取哦，无偿分享！！！

如果你对网络安全入门感兴趣，那么你需要的话可以

点击这里👉【整整282G！】网络安全&黑客技术小白到大神全套资料，免费分享！

①网络安全学习路线
②上百份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥HW护网行动经验总结
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

![](https://img-
blog.csdnimg.cn/img_convert/455e5e3828800d685f15da40c7128117.png)

接下来我将给各位同学划分一张学习计划表！

学习计划

那么问题又来了，作为萌新小白，我应该先学什么，再学什么？
既然你都问的这么直白了，我就告诉你，零基础应该从什么开始学起：

阶段一：初级网络安全工程师

接下来我将给大家安排一个为期1个月的网络安全初级计划，当你学完后，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web渗透、安全服务、安全分析等岗位；其中，如果你等保模块学的好，还可以从事等保工程师。

综合薪资区间6k~15k

1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（1周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（1周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（1周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）

那么，到此为止，已经耗时1个月左右。你已经成功成为了一名“脚本小子”。那么你还想接着往下探索吗？

阶段二：中级or高级网络安全工程师（看自己能力）

综合薪资区间15k~30k

7、脚本编程学习（4周）
在网络安全领域。是否具备编程能力是“脚本小子”和真正网络安全工程师的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力。

零基础入门的同学，我建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习
搭建开发环境和选择IDE，PHP环境推荐Wamp和XAMPP，IDE强烈推荐Sublime；

Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，没必要看完

用Python编写漏洞的exp,然后写一个简单的网络爬虫

PHP基本语法学习并书写一个简单的博客系统

熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)

了解Bootstrap的布局或者CSS。

阶段三：顶级网络安全工程师

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

学习资料分享

当然，只给予计划不给予学习资料的行为无异于耍流氓，这里给大家整理了一份【282G】的网络安全工程师从入门到精通的学习资料包，可点击下方二维码链接领取哦。