API安全风险：需要注意和如何预防

如今，世界依靠通过 API 连接的强大数据生态系统提供支持的技术运行。我们的移动和桌面应用程序、支持 IoT 的智能设备、金融机构等都在由 API 支持的技术上运行。

Humankind 已经目睹了技术越受欢迎和被广泛接受，它成为安全攻击的目标就越大。新型攻击及其各自的补救措施不断出现。为了确保其应用程序和 API 的安全，组织需要跟上 API 安全最佳实践。

常见的 API 安全风险有哪些？

Open Web Application Security Project（称为 OWASP Foundation）是一个非营利性基金会，致力于提高软件的安全性。OWASP 维护了一份全球安全研究人员贡献的 10 大 API 安全风险列表。据说这些是 API 安全性的行业基准。仅通过缓解这些安全风险，组织就可以显著减少攻击媒介。让我们来了解一下其中一些常见的 API 安全风险，以确保应用程序架构更安全。

1. 损坏的对象级授权

损坏的对象级授权（BOLA）是指在处理请求之前缺少资源所有权验证。这意味着服务器不会验证客户端和请求的对象之间的所有权关系。这可能会导致任何人都能访问任何东西。

例如，在电子商务应用程序中，您可能有一个“查看我的订单”部分，该部分通过 GET API 运行，该 API 列出了与您的用户 ID 关联的所有订单 ID。然后是另一个 API，它根据订单 ID 提供详细信息，而无需进一步检查请求的资源是否属于客户端。

通过尝试订单 ID 的多种组合并“走运”，通过发现数据库中的基础表的设置方式在创建时自动递增订单 ID，这很容易被利用。

现在，假设攻击者可以访问任何订单 ID。在这种情况下，他们可以上下该范围，并可能从这些增量订单 ID 中获取个人身份信息，例如订单的联系人或送货地址。

解决方案是始终检查客户端是否有权访问请求的资源。没有更好或更简单的表达方式了。

2. 用户身份验证失效

通常，我们所有应用程序的页面都位于登录或公共注册页面后面。这会将这些访问方法呈现为攻击者可以利用的目标。一些常见的身份验证问题包括弱密码策略、以明文形式向服务器发送密码、相信所有用户都是人类（无 CAPTCHA）以及弱加密或无加密。

公司可以通过实施抗暴力机制（如速率限制、CAPTCHA、更强的密码策略、帐户不活动计时器等）来降低登录或注册漏洞风险，以确保用户始终进行身份验证。

OWASP 提供了其身份验证备忘单中记录的身份验证指南的单一参考点.

3. 过度数据暴露

实际上，过度数据暴露是指数据从数据库中获取并发送到客户端，而 RESTful API 中没有任何敏感度筛选或精细访问控制。

通过请求从您的服务器获取数据并检查 API 响应，可以轻松识别和捕获此漏洞。这些响应将始终包含客户端不应查看的数据或元数据。

这里的解决方案是很好地掌握应用程序的业务逻辑。这将允许您只发送客户端所需的数据，而不发送其他任何内容。这在规模上还会减小 API 响应的大小，从而降低带宽成本。

4. 缺乏资源和速率限制

缺少速率限制意味着您的服务器将继续接受请求，直到它不再接受为止。不限制可以发送到服务器的请求数量会使其容易受到拒绝服务（DoS）攻击。在 DoS 攻击中，服务器可能会被过多的请求淹没。最终，这可能导致服务器崩溃并导致中断，从而损失实际和潜在收入。

通过用大量请求（又名负载测试）攻击任何服务器并检查它是否崩溃，可以很容易地识别此漏洞。

有几种方法可以在服务器上实施速率限制。这是一篇详细的博客，供想要更深入地了解 Node.js 实现的读者使用。

5. 功能级授权失效

失效函数级授权是指可以通过 REST API 进行管理操作，但在函数级别缺乏授权。从本质上讲，系统无法识别管理员用户和普通用户之间的区别。因此，它将向所有人授予访问权限并允许运行管理操作。

攻击者可以通过利用 API URL 的通用 REST API 原则和命名法来快速识别这一点。仅仅将 GET 用户的 API 方法更改为 PATCH 或 DELETE 可能会给普通用户带来未经授权的破坏性能力。

一个简单的解决方案是阻止所有操作作为默认配置。然后，仅在需要时向某些用户或用户类型开放操作。对于管理操作，与普通用户也可以使用它们相比，管理员用户无法使用它们要好得多。

6. SQL注入

许多应用程序根据用户输入构建 SQL 查询，例如，用于字符串比较的文本输入。让我们看一个订单取消查询的示例。在这种情况下，订单 ID 应由客户端作为 Delete API URL 本身的查询参数发送。在这里，以下查询模板需要订单 ID：

const query = `DELETE FROM Orders WHERE OrderId = ${req.query.orderId};`;

这可以让攻击者直接访问您的数据库，在那里他们可以调用，而不是订单 ID：

DELETE /api/orders?orderId=123%20OR%201%3D1

这最终将构建以下 SQL 查询：

DELETE FROM Orders WHERE OrderId = 123 OR 1=1;

上面生成的 SQL 查询是有效的，因此将从 Orders 表中删除所有行，因为 OR 1=1 始终为 True.

解决方案可能是对 URL 查询进行严格的参数检查。但是，经验法则是永远不要相信用户输入。始终使用公认的输入清理库来清理用户输入。这将确保，如果你期望路由的查询参数中的 orderId 是一个整数，那么它就不是整数了。已经创建了许多库来解决此问题。您可以选择由开源社区积极维护的任何流行的应用程序。

经验法则是永远不要相信用户输入。