10 API Security Vulnerabilities You Need To Be Aware Of (Along with REST API Overview)

您需要注意的 10 个 API 安全漏洞（以及 REST API 概述）

原文链接：https://javascript.plainenglish.io/rest-api-overview-api-security-vulnerabilities

REST API 概述和 API 安全漏洞

什么是API?

API（或应用程序编程接口）提供了两个系统之间的交互方法

什么是RESTful API?

REST （REpresentational State Transfer），由计算机科学家 Roy Fielding 博士于 2000 年首次定义。

REST 是一组架构约束，而不是协议或标准。它是一种通过 HTTP 设计松散耦合应用程序的架构风格，通常用于 Web 服务的开发。

REST 不强制执行任何关于如何在较低级别实现的规则，它只是提出高级设计指南，让您考虑自己的实现。

REST 设计原则或架构约束

1. Client-Server（客户端-服务器）
2. Stateless（无状态）
3. Cache（缓存）
4. Uniform Interface（统一接口）
5. Layered System（分层结构）
6. Code-On-Demand (optional)（按需编码可选）

Client-Server
这种约束背后的原则是关注点分离，因为用户界面与数据存储的关注点完全分离。从本质上讲，这意味着客户端和服务器应用程序在不相互依赖的情况下发展。

Client-Server

Stateless
在 REST 应用程序中，每个请求都必须包含服务器理解所需的所有信息，而不是依赖于服务器记住先前的请求。在服务器上存储会话状态违反了 REST 架构的无状态约束。 所以会话状态必须完全由客户端处理。这种约束引入了可见性、可靠性和可扩展性的属性
Visibility — 每个请求都包含理解它所需的所有上下文。 因此，查看单个请求就足以可视化交互。
Reliability — 由于一个请求是独立的，一个请求的失败不会影响其他请求。
Scalability — 服务器不必记住应用程序状态，使其能够在更短的时间内处理更多请求。

Stateless

Cache
缓存约束要求对请求的响应中的数据被隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的，则客户端缓存有权将响应数据重用于以后的等效请求。缓存是在请求-响应路径上的多个位置存储经常访问的数据副本的能力。我们可以使用 Expires 和 Cache-Control HTTP 响应头来控制缓存行为。

cache

Uniform Interface
统一接口约束是任何 REST 服务设计的基础。统一的接口简化并解耦了架构，使每个部分都可以独立发展。
该接口的四个指导原则是：
• 资源标识——您使用URI (IRI) 标准来标识资源。在这种情况下，资源是 Web 文档。
• 通过这些表示来操作资源——您使用 HTTP 标准来描述通信。因此，例如 GET 意味着您要检索有关 URI 标识资源的数据。您可以使用 HTTP 方法和 URI 来描述操作。
• 自描述消息——您使用标准 MIME 类型和（标准）RDF 词汇来使消息自描述。因此客户端可以通过检查语义来找到数据，而不必知道服务使用的特定于应用程序的数据结构。
• 超媒体作为应用程序状态的引擎——您使用超链接和可能的 URI 模板将客户端与特定于应用程序的 URI 结构分离。您可以使用语义注释这些超链接，例如IANA 链接关系，因此客户将理解它们的含义。

Uniform Interface

Layered System
为了改善 Internet 规模需求层的行为，系统约束应运而生。分层系统风格允许架构由分层层组成，通过约束组件行为使得每个组件不能“看到”超出它们与之交互的直接层。REST 允许您使用分层系统架构，您可以在服务器 1 上部署 API，在服务器 2 上存储数据并在服务器 3 中验证请求。

Layered System

Code-On-Demand
REST 允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。这通过减少需要预先实现的功能的数量来简化客户端。 部署后允许下载功能提高了系统的可扩展性。但是，它也降低了可见性，因此只是 REST 中的一个可选约束。

Code-On-Demand

API 安全漏洞 (OWASPS-Top-10)

OWASP是一个开源的、非盈利的全球性安全组织，致力于应用软件的安全研究，它有很多开源项目，OWASP API安全Top 10就是其中的一个。

1.失效的对象及授权
API 倾向于暴露处理对象标识符的端点，从而产生广泛的攻击面级别访问控制问题。缺乏适当的授权检查允许攻击者访问指定的资源。

Use Cases
1.真实用户请求获取用户信息

案例 1 - 来自经过身份验证的用户的真实请求

2.用户通过猜测正确的参数来尝试访问另一个用户的资源

案例2——猜对参数

3.用户通过猜测错误的参数试图访问另一个用户的资源

案例 3——猜错参数

失效的对象级别授权只能手动测试。 您可以使用通常用于测试 API 的相同工具，例如 Postman、Fiddler、ReadyAPI。

2. 失效的用户认证
失效用户身份验证缺陷的发生主要是由于会话管理和凭据管理中的漏洞。攻击者主要利用身份验证机制的弱点来获取用户会话ID、详细信息和用户凭据。在这个漏洞中，由于在开发和部署 API 时没有实施最佳实践而导致的情况非常多。Broken Authentication 攻击旨在接管一个或多个帐户，为攻击者提供与被攻击用户相同的权限。 当攻击者能够破坏密码、密钥或会话令牌、用户帐户信息和其他详细信息来冒充用户身份时，身份验证就会被破坏。
例：
1、使用模糊或蛮力很容易猜出用户名和密码。
2、密码与密码复杂性政策或最佳实践不符。
3、认证失败时枚举用户名/密码无效的用户名或无效的密码。
4、登录凭据在存储且缺少哈希时不受保护。
5、通过 HTTP 等未加密通道传输用户名和密码
6、Session ID 暴露在 URL 中。
7、用户注销后，用户会话或身份验证令牌不会超时。

失效的用户认证

开发人员必须确保正确设置和保护身份验证机制。一些自动化工具可以帮助您测试最常见的身份验证模式。例如，对于基本身份验证，Acunetix 或 Burp Suite 等安全工具可以验证令牌是否加密以及哈希是否正确。 这些工具将为您提供一份基本报告，然后您必须仔细分析。

3. 过度的数据暴露
此漏洞与API 公开数据有关，这些数据将在 UI 上呈现或显示。例如，我们有一个界面，我们想要显示来自用户对象的三个字段，如姓名、地址和个人资料照片。 但与此同时，我们从 API 中获取了更多用户对象中的数据，这与当前用户界面的情况无关。为了防止这种情况，我们在 API 响应中返回了相关字段，而不是通过 API 共享敏感数据。
例：
1.API 返回完整的数据对象，因为它们存储在后端数据库中。
2.客户端应用程序过滤响应，只显示用户真正需要查看的数据。
3.攻击者直接调用 API 并获取 UI 将过滤掉的敏感数据。

过度的数据暴露

我们必须手动测试过度数据暴露。 我们可以通过功能测试来验证 API 响应字段。

4.缺乏资源和速率控制
不正确的速率限制是一种漏洞，当一个 API 对其发送到另一个 API 或服务器的请求数量没有限制时，就会发生这种漏洞。API 无法防止过多的调用或有效负载大小。攻击者可以将其用于拒绝服务 (DoS) 和身份验证缺陷，如暴力攻击。
Use Cases
1.攻击者可能通过发送不必要的更多请求来使API过载
2.没有对每个请求的请求记录大小进行适当的验证

缺乏资源和速率控制

要查找速率限制漏洞，您可以使用不同的模糊测试工具，例如 JBroFuzz 或 Fuzzapi。或者，您可以使用分析流量的相同工具。使用 429 (Too Many Requests) 状态码，我们可以对过载的不必要 API 请求实施速率限制。我们可以从 API 对请求的记录大小添加适当的验证，以返回有限的记录作为响应

5. 失效的功能级授权
具有不同层次结构、组和角色的复杂访问控制策略，以及管理和常规功能之间的不明确分离，往往会导致授权缺陷。此漏洞与垂直级别的授权有关——用户试图获得比允许更多的访问权限。例如，试图成为管理员的普通用户。

为了找到这个漏洞，我们要了解应用程序中的各种角色和对象是如何连接的，以及应用程序中实现的访问矩阵

6. 批量分配
API 获取客户端提供的数据并将其存储，而无需对列入白名单的属性进行适当过滤。实施验证中间件以从客户端 API 请求中获取参数并提取服务该请求所需的特定字段。

对于可以通过 API 检索但绝不应修改的所有属性，请在对象模式中使用设置为 true 的 readOnly 属性。在设计时精确定义您将在请求中接受的模式、类型和模式，并在运行时强制执行它们。

7.安全性配置错误
此漏洞与您的 Web 服务器或 API 的错误配置有关。API 服务器的不良配置允许攻击者利用它们。必须在服务器上禁用所有不必要的 HTTP 方法。 根本不显示任何不必要的用户错误。
不要将错误的技术细节传递给客户。 如果您的应用程序使用跨域资源共享 (CORS)，也就是说，如果它允许来自不同域的另一个应用程序访问您的应用程序的 cookie，则必须适当配置这些标头以避免额外的漏洞。还必须禁用对内部文件的任何访问。 有一些特殊的安全标头，例如 Content-Security-Policy，您还可以在应用程序中实现这些标头以提高安全级别。

如果我们的应用程序使用跨域资源共享 (CORS)，也就是说，如果它允许来自不同域的另一个应用程序访问我们应用程序的 cookie，则必须适当配置这些标头以避免额外的漏洞。 还必须禁用对内部文件的任何访问。 有一些特殊的安全标头，例如 Content-Security-Policy，我们也可以在您的应用程序中实施以提高安全级别。

8.注入
攻击者构建的 API 调用包括 SQL、NoSQL、LDAP、OS 或 API 或其背后的后端盲目执行的其他命令。我们可以使用对象-关系映射模型来避免 SQL 注入。在大量旧站点和系统中仍然可能存在此类问题。 除了 XSS 和 SQL，我们还应该寻找 XML 注入、JSON 注入等。

我们可以使用不同的工具测试注入。例如，ReadyAPI 提供了一个付费的自动扫描工具。其他的，比如 Burp Suite，是部分免费的。或者，如果您在项目中使用 Postman，您可以使用 Postman 和数据驱动测试执行基本的注入测试。

9.Improper Assets Management
此漏洞与您的资产管理不善有关。随着工程师采用 DevOps、持续测试和 CI/CD 管道，这个缺陷越来越多。从安全角度来看，正确配置这些 CI/CD 管道至关重要。攻击者发现 API 的非生产版本（例如，暂存、测试、测试版或更早版本）没有像生产 API 那样受到良好保护，并使用这些版本发起攻击。

使用虚拟机时，容器可能由 CI/CD 管道创建，微服务可能放置在单独的容器中。 在整个过程中，请确保我们周围没有每个人都忘记的旧容器——这些很容易成为额外的访问点。

10.日志记录和监控不足
此漏洞与日志记录和监控程序不足有关。这里的主要思想是，无论我们的应用程序发生什么，我们必须确保我们可以跟踪它。我们应该始终拥有准确显示攻击者试图做什么的日志。
此外，建立识别可疑流量的系统，等等。

OWASP 提供了详细的清单供参考，以确保您的应用程序受到保护。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！