常见的API漏洞

前言

目前API在企业中使用的越来越来，API的安全问题也越来越严重，本篇文章就来看看常见的API漏洞都有哪些。

信息泄露

当API及其支持软件向非特权用户共享敏感信息时，这就说明该API可能存在信息泄露漏洞。信息可能在API响应或公共来源中泄露，例如代码仓库、搜索结果、新闻、社交媒体、目标网站和公共API目录。

敏感数据可以包括攻击者可以利用的任何信息，如下面的信息：

1）存在报错信息，如sql报错，信息报错

2）返回了详细内容，例如用户名不存在，密码错误，不存在id字段等

查找信息泄露的方式：

通常，通过与API端点交互并分析响应，可以收集到大量信息。API响应中的标头、参数和详细错误可能会泄露重要信息。其他有价值的信息来源包括API文档和在侦察过程中收集的资源

对象级授权缺陷（水平越权）

API中的一种常见漏洞是对象级授权缺陷(BOLA)。当API提供商未能对API用户实施适当的对象级访问控制时，便会产生BOLA漏洞。在这种情况下，若API端点未实施对象级访问控制，将无法确保用户仅能访问自身资源，从而导致用户A能够成功请求用户B的资源。

API使用特定值（如名称或数字）来标识各种对象。在发现这些对象ID时，应测试未经身份验证或以不同用户身份验证时，是否可以与其他用户的资源进行交互。

一句话总结：就是可以通过修改资源标识访问不属于自己的用户信息

GET/api/resource/1; GET /user/account/find?user_id=15;POST/company/account/Apple/balance;POST/admin/pwreset/account/90。

这里如何资源ID采用了不可预测的序列，即使存在越权，也会因为我们没有办法获取资源ID导致无法利用。这里就有一个问题，如何判断资源ID是否可以预测？有的资源ID看起来是无序的，仔细分析的话就可以发现其也是有迹可循。

用户身份验证缺陷（未授权访问以及认证过程中的漏洞）

用户身份验证缺陷是指API身份验证过程中存在的任何漏洞。这些漏洞通常发生在API提供商未实施或实施不当的身份验证保护机制的情况下。

API通常要求用户完成注册流程以获取唯一令牌。用户随后可在请求中使用该令牌，以证明有权发出此类请求。因此，注册流程、令牌处理及生成令牌的系统可能存在各自的漏洞。例如，评估令牌生成过程是否较弱，可收集部分令牌样本并分析其相似性。若令牌生成过程不依赖高随机性或熵，则可能创建或劫持他人令牌。

可能存在问题的功能：

1）注册功能

2）认证过程

3）令牌处理以及令牌生成

4）密码重置：设想一个密码重置功能要求提供电子邮件地址和一个六位数的代码。若API允许无限次请求，只需进行一百万次请求，即可猜测代码并重置任何用户的密码。四位数代码只需进行一万次请求

过度数据暴露

过度数据暴露是指API端点返回的信息超出了请求所需的信息范围。这种情况通常在提供商期望API用户会对结果进行过滤时发生。换句话说，当用户请求特定信息时，提供商可能会回应各种信息，默认为用户从响应中筛选出不需要的数据。当此类漏洞存在时，就如同要求某人仅告知其姓名，然而对方却提供了姓名、出生日期、电子邮件地址、电话号码，以及他们所认识的其他人的身份标识等过多信息。

要识别过度数据暴露，只需测试目标API端点，查看响应中发送的信息。

资源缺乏和速率限制

速率限制在API的商业化和可用性方面扮演着至关重要的角色。若不对用户发出的请求数量进行限制，API提供商的基础设施可能会因过载而崩溃。当请求过多而资源不足以应对时，将导致提供商的系统瘫痪，从而引发拒绝服务攻击。

功能级授权缺陷（垂直越权）

功能级授权缺陷(BFLA)是一种安全漏洞，它允许一个角色或组的用户访问另一个角色或组的API功能。API提供商通常会为不同类型的账户设置不同的角色，例如公共用户、商家、合作伙伴和管理员等。若一个用户能够使用另一个权限级别或组的功能，则可能存在BFLA漏洞。换句话说，BFLA漏洞可能表现为横向移动，即使用类似权限的组的功能；也可能是特权升级，即使用更高特权组的功能。尤其值得关注的是API功能，如处理敏感信息、访问属于另一个组的资源以及管理员功能（如用户账户管理）。

为发现BFLA漏洞，最简单的方法是查找管理员API文档，并以非特权用户身份发送请求，测试管理功能及能力。

批量分配

当API用户的请求中包含了超出应用程序预期数量的参数，且应用程序将这些额外参数整合到代码变量或内部对象中时，便会产生批量分配现象。在这种情况下，用户有可能篡改对象属性或提升自身权限。

意思就是API中存在其它的隐藏参数（一般对用户不可见），可以通过添加这些参数修改对象属性。

设想一下，调用API以创建一个带有“User”和“Password”参数的账户：

{"User": "scuttleph1sh","Password": "GreatPassword123"}

在查阅账户创建过程的API文档时，若发现一个名为isAdmin的额外键，用户可通过将其值设为true来获取管理员权限。用户可以借助诸如Postman或Burp Suite等工具为请求添加该属性：

{"User": "scuttleph1sh","Password": "GreatPassword123","isAdmin": true}

测试人员可通过查阅API文档寻找有趣参数，例如与用户账户属性、关键功能和管理操作相关的参数，并将这些参数添加至请求中，以发现批量分配漏洞。拦截API请求和响应有助于发现值得测试的参数。此外，还可猜测参数或在API请求中对参数进行模糊测试

安全配置错误

安全配置错误涵盖了开发人员在API的支持安全配置中可能犯的各类错误。这些错误若严重到导致敏感信息泄露或整个系统被接管，将对API及相应系统造成极大威胁。例如，若API的支持安全配置显示存在未修复的漏洞，攻击者便可能利用已公开的漏洞轻易实现对API及系统的“掌控”。

安全配置错误实质上是一系列问题，包括错误配置的标头、错误配置的传输加密、使用默认账户、接受不必要的HTTP方法、缺失输入过滤以及详细的错误消息。

用户可以运用Web应用程序漏洞扫描器（如Nessus、Qualys、OWASP ZAP和nikto）检测这些安全配置错误。这些扫描器将自动检查Web服务器版本信息、标头、Cookie、传输加密配置和参数，以确定是否缺少预期的安全措施。此外，用户还可以手动检查这些安全配置错误，若了解特定内容，可通过检查标头、SSL证书、Cookie和参数来进行。

注入

注入漏洞发生于请求传输至API基础架构的过程中，API提供商未能对输入进行过滤以移除不必要的字符（此过程称为输入过滤）。因此，基础架构可能将请求中的数据视为代码并执行。当此类漏洞存在时，攻击者得以实施注入攻击，如SQL注入、NoSQL注入和系统命令注入。

不当的资产管理

不当的资产管理可能导致组织暴露已停用或仍在开发中的API。与各类软件相似，旧的API版本更有可能存在漏洞，因为它们不再接受更新和修复。同时，开发中的API通常不如生产API安全。不当的资产管理可能导致一系列问题，如数据过度暴露、信息泄露、大规模资源分配、速率限制不当和API注入等。对攻击者而言，发现不当资产管理漏洞仅仅是进一步利用API的第一步。

为识别不当资产管理，可密切关注过时的API文档、变更日志和存储库中的版本历史。例如，若组织未及时更新API文档以适应API端点变更，可能出现对已不再支持的API部分的引用。通常，组织会在端点名称中加入版本信息，以便区分新旧版本，如/v1/、/v2/、/v3/等。开发中的API通常使用特定路径，如/alpha/、/beta/、/test/、/uat/和/demo/。若发现某API当前使用apiv3.org/admin，但文档中部分内容仍引用apiv1.org/admin，可以尝试测试不同端点，查看apiv1或apiv2是否仍活跃。此外，组织变更日志可能揭示v1为何被更新或停用。若可访问v1，可测试相关漏洞。

除了查阅文档，还可以通过猜测、模糊测试或暴力请求等方法发现资产管理方面的漏洞。通过观察API文档或路径命名的规律，可以据此构造并发起请求。

业务逻辑漏洞

业务逻辑漏洞（又称业务逻辑缺陷，或BLF）是指应用程序中的设计特性可能被攻击者恶意利用。例如，某API具备上传功能，但未对编码的有效负载进行验证，用户仅需对文件进行编码，便可上传任意文件。这将使得终端用户得以上传并执行任意代码，包括恶意负载。

在API文档中，用户可以寻找业务逻辑漏洞的明显迹象。一些关键语句可能激发用户的思考，

例如：

• 仅通过功能X执行功能Y；

• 避免使用端点Y进行X操作；

• 仅管理员可执行请求X。

这些表述暗示了API提供商对用户的信任，期望用户不会执行被抑制的行为。在进行API攻击时，应挑战此类请求，以验证安全控制措施的有效性。