每个 API 团队都应该知道的十大 API 安全威胁

随着越来越多的数据通过 API 安全性都不能再是事后考虑的问题。API 的难点在于它可以直接访问大量数据，同时绕过浏览器的预防措施。您不必担心 SQL 注入和 XSS 问题，而应该担心能够分页浏览所有客户记录及其数据的恶意行为者。

典型的预防机制（如 Captchas 和浏览器指纹识别）不起作用，因为 API 在设计上需要处理大量 API 访问，即使是单个客户也是如此。那么你从哪里开始呢？首先要把自己放在黑客的角度，然后对你的 API 进行检测和阻止常见攻击以及未知的零日漏洞攻击。其中一些是OWASP 安全 API 列表，但不是全部。

不安全的分页和资源限制

大多数 API 提供对资源的访问，这些资源是诸如/users或 之类的实体列表/widgets。客户端（例如浏览器）通常会过滤和分页此列表，以限制返回给客户端的项目数量，如下所示：

First Call: GET /items?skip=0&take=10



Second Call: GET /items?skip=10&take=10```



但是，如果该实体有任何 PII 或其他信息，那么黑客就可以抓取该端点以获取数据库中所有实体的转储。如果这些实体意外泄露了 PII 或其他敏感信息，这可能是最危险的，但也可能为竞争对手或其他人提供您企业的采用和使用统计数据，或为诈骗者提供获取大量电子邮件列表的方法。看看 Venmo 数据是如何被提取的



一种简单的保护机制是检查执行次数，如果大于 100 或 1000，则抛出错误。这种机制的问题有两个方面：



1. 对于数据 API，合法客户可能需要获取和同步大量记录（例如通过 cron 作业）。人为地设置较小的分页限制可能会使您的 API 变得非常繁琐，从而降低整体吞吐量。最大限制是为了确保满足内存和可扩展性要求（并防止某些 DDoS 攻击），而不是为了保证安全性。

2. 这对于编写简单脚本并在重复访问之间随机延迟的黑客来说毫无保护。

skip = 0
while True:
response = requests.post(‘https://api.acmeinc.com/widgets?take=10&skip=’ + skip),
headers={‘Authorization’: ‘Bearer’ + ‘ ‘ + sys.argv[1]})
print("Fetched 10 items")
sleep(randint(100,1000))
skip += 10

### 如何防范分页攻击



为了防止分页攻击，您应该跟踪每个用户或 [API 密钥](https://www.explinks.com/blog/api-key-what-is-an-api-key)在特定时间段内访问了单个资源的项目数，而不仅仅是在请求级别。通过跟踪用户级别的 API 资源访问



![监控 API 分页攻击](https://blog.moesif.com/images/posts/technical/api-security/content-length-by-company.png?aa=22)



## 不安全的 API 密钥生成



大多数 API 都受到某种 API 密钥或 JWT（[API 安全工具](https://www.explinks.com/blog/10-ai-powered-api-security-tools)可以检测异常的 API 行为并自动阻止对 API 密钥的访问。然而，黑客会通过从大量用户生成和使用大量 API 密钥来超越这些机制，就像网络黑客会使用大量 IP 地址来规避 DDoS 保护一样。



### 如何防范 API 密钥池



防范此类攻击的最简单方法是要求人工注册您的服务并生成 API 密钥。可以使用 Captcha 和双因素[身份验证](https://www.explinks.com/blog/which-authentication-methods-are-best-to-protect-your-api)等技术来阻止机器人流量。除非有合法的商业案例，否则注册您服务的新用户不应能够以编程方式生成 API 密钥。相反，只有受信任的客户才应该能够以编程方式生成 API 密钥。更进一步，确保在用户和帐户级别（而不仅仅是每个 API 密钥）对任何异常行为进行异常检测。



## 意外泄露密钥



API 的使用方式会增加凭证泄露的可能性：



1. API 预计会在无限的时间段内被访问，这增加了黑客获得未过期的有效 API 密钥的可能性。您将该 API 密钥保存在服务器环境变量中，然后就忘了它。这与用户登录交互式网站（会话会在短暂持续时间后过期）的情况形成了鲜明对比。

2. API 的使用者可以直接访问凭证，例如通过 Postman 或 开发人员不小心将包含 API 密钥的 [CURL 命令](https://www.explinks.com/wiki/what-is-the-curl-command/)复制/粘贴到公共论坛（如 GitHub Issues 或 Stack Overflow）中即可。

3. API 密钥通常是不记名令牌，不需要任何其他识别信息。API 无法利用一次性令牌或双因素身份验证等功能。



如果由于用户错误而泄露密钥，人们可能会认为您作为 API 提供商应该承担责任。但是，安全性的关键在于减少接触面积和风险。请像对待自己的数据一样对待客户数据，并通过添加防止意外泄露密钥的保护措施来帮助他们。



### 如何防止意外泄露密钥



防止密钥泄露的最简单方法是利用两个令牌而不是一个。*刷新令牌*存储为环境变量，只能用于生成*短期访问令牌*。与刷新令牌不同，这些短期令牌可以访问资源，但有时间限制，例如几小时或几天。



客户将与其他 API 密钥一起存储刷新令牌。然后，您的 SDK 将在 SDK 初始化时或最后一个访问令牌过期时生成访问令牌。如果 CURL 命令被粘贴到 GitHub 问题中，那么黑客需要在数小时内使用它，从而减少攻击媒介（除非它是实际的刷新令牌，但可能性很低）



## 遭受 DDoS 攻击



API 开辟了全新的[商业模式](https://www.explinks.com/wiki/what-is-business-model/)，客户可以通过编程方式访问您的 [API 平台](https://www.explinks.com/blog/chinese-api-platform-for-selling-apis)。然而，这可能会使 DDoS 保护变得棘手。大多数 DDoS 保护旨在吸收和拒绝来自恶意行为者的大量请求DDoS 攻击



### 阻止 DDoS 攻击



API 的神奇之处在于几乎每次访问都[需要 API](https://www.explinks.com/blog/9-reasons-why-you-need-api-governance) 密钥。如果请求没有 API 密钥，您可以自动拒绝它，这对您的服务器来说很轻量（确保在后续中间件（如请求 JSON 解析）之前尽早完成身份验证）。那么，您如何处理经过身份验证的请求？最简单的方法是利用每个 [API 密钥的速率限制](https://www.explinks.com/blog/best-practices-api-rate-limiting-vs-throttling)计数器，例如每分钟处理 X 个请求，并拒绝那些超过阈值的请求。429 HTTP response.有多种算法可以做到这一点，例如漏桶和固定窗口计数器。

## 服务器安全性不正确

在良好的服务器卫生方面，API 与 Web 服务器并无不同。由于 SSL 证书配置错误或允许非 HTTPS 流量，数据可能会泄露。对于现代应用程序，几乎没有理由接受非 HTTPS 请求，但客户可能会错误地从其应用程序或 CURL 发出非 HTTP 请求，从而暴露 API 密钥。API 没有浏览器的保护，因此 HSTS 或重定向到 HTTPS 之类的东西无法提供保护。

### 如何确保 SSL 正确

通过以下网址测试您的 SSL 实现Qualys SSL [测试REST API](https://www.explinks.com/blog/the-rest-api-handbook-how-to-build-test-consume-and-document-rest-apis) 跨源资源共享权威指南

## 缓存标头不正确

API 提供对每个 API 密钥范围内的动态数据的访问。任何缓存实现都应该能够将范围限定到 API 密钥，以防止交叉污染。即使您不在基础架构中缓存任何内容，也可能使客户面临安全漏洞。如果使用代理服务器的客户使用多个 API 密钥（例如一个用于开发，一个用于生产），那么他们可能会看到交叉污染的数据。为了避免这种潜在的漏洞，建议购买移动代理可以为每个用户或应用程序提供增强的安全性和专用隔离的服务。

这有多严重？参见 Twitter 在数据安全事件后披露账单信息泄露

### 如何确保不缓存

你应该确保缓存控制标头已正确配置。

API 的一个大问题是，许多 API 不使用标准Authorization标头，而是使用自定义标头，如X-Api-Key。缓存服务器不知道此请求是否经过身份验证，因此选择缓存该请求。

app.use((req, res, next) => {
res.setHeader(‘Cache-Control’, ‘no-store, no-cache, must-revalidate’);
res.setHeader(‘Pragma’, ‘no-cache’);
// …
});

## 记录和监控不足



这是 OWASP 十大 [API 日志](https://www.explinks.com/blog/sa-api-logs)记录和监控，攻击者可以继续使用相同的漏洞，甚至探测更多漏洞。



### 如何正确添加 API 日志记录



您应该确保您的 API 日志记录不仅跟踪 [API 产品](https://www.explinks.com/blog/api-as-a-product-what-is-api-as-a-product)提供全套 [API 监控和分析](https://www.explinks.com/blog/api-analysis-what-is-api-analysis)，只需几分钟即可开始使用。



![API 审计日志](https://blog.moesif.com/images/posts/technical/kong/kong-api-log.svg?aa=22)



## 不保护内部端点



同一 [API 服务](https://www.explinks.com/api/location_time_zone)可能具有供外部和外部使用的端点。端点未记录并不意味着黑客无法调用它。除了使用[身份验证和授权](https://www.explinks.com/blog/api-authentication-and-authorization-6-methods-and-tips-for-success)方案进行保护外，您还应确保这些端点完全不暴露在公共互联网上，这可以在负载均衡器或 [API 网关](https://www.explinks.com/wiki/api-gateway/)内完成。这有助于提供多层次的安全性，这是一种常见的预防策略。



## 不办理授权



虽然大多数 [API 开发](https://www.explinks.com/blog/api-design-first)人员都会添加全局*身份验证*方案（例如 API 密钥或 [OAuth](https://www.explinks.com/wiki/oauth/)）来验证人员身份，但*授权*也是必需的，并且与身份验证分开，因此实施起来比较困难。授权涉及检查此人（已识别）是否可以访问特定资源。这可以通过 API 范围、检查租户 ID 或用户 ID 等来完成。



由于授权特定于您的应用程序逻辑，并且并非总是横切的，因此它可能是开发人员容易忘记的一个领域。除非您的对象标识符具有足够的熵，否则黑客可以通过迭代轻松测试不同的 ID。对于在插入时增加 ID 的 SQL 数据库来说尤其如此。



### 如何修复授权



确保经过身份验证的用户有权访问生成 API 响应所需的*所有*资源。这可能涉及检查与相关对象关联的用户 ID 或[访问控制](https://www.explinks.com/blog/ua-comprehensive-analysis-of-access-control-csdn)列表 (ACL)。有关如何处理授权的更多信息，请查看我们的帖子《为RESTful [API构建身份验证](https://www.explinks.com/blog/api-authentication-and-authorization-6-methods-and-tips-for-success)和授权的步骤》



原文地址：