最近一连串的API安全事件（Peloton、Experian、Clubhouse 等）无疑迫使许多安全和开发团队仔细检查他们的 API 安全状况，以确保它们不会成为下一个被攻击对象。创建面向外部受众的所有API的清单是组织在组合或重新评估API安全程序时最常见的出发点。有了这个清单，下一步是评估每个暴露的 API 的潜在安全风险，比如弱身份验证或以明文形式暴露敏感数据。

　　OWASP API安全Top 10为评估API清单的风险类型提供了一个良好的框架。它们被列在前10位是有原因的，最常见和最严重的都排在前面。例如，列表中的前两个处理身份验证和授权，这两个都可以追溯到上面提到的一些最近的API事件，这在安全公司的客户环境中很常见。

　　未经身份验证的 API

　　未经身份验证的 API 是迄今为止在面向公众的 API 中检测到的最糟糕的事情，对于处理基本业务信息的 API 尤其如此，这些信息可能包含遵守PCI或PHI法规的信息。

　　在处理必要业务数据的面向公众的 API 中缺乏身份验证的一个常见原因是，该 API 过去故意不进行身份验证，以支持不支持身份验证的遗留应用程序。以前可能是这样，但这并不意味着API应该保持开放。今天，许多用户（包括外部和内部）将完全开放地访问API。了解旧限制历史的人可能已经离开了公司，因此，企业现在需要努力填补这一差距。为这些例外情况打开大门是绝对不能接受的，因为很少有人在以后的某个时间点再回去关闭大门。

　　最佳实践：永远不要部署未经验证的API，无论是内部的还是面向公众的。

　　使用非空值身份验证令牌的 API

　　尽管很难想象，但通常会发现 API 根本不使用 auth 令牌实现任何身份验证，而是仅检查请求中是否存在一个。这个问题通常比 API 中缺少身份验证更令人震惊，因为这允许用户仅通过在 API 请求中传递身份验证令牌来访问资源。令牌的实际值并不重要，因为应用程序仅检查请求中是否存在身份验证令牌（任何身份验证令牌）。

　　很难想到用这种方法开发 API 的充分理由。也许他们缺乏在后端应用程序中实现身份验证逻辑所需的时间？不幸的是，攻击者无需花费太多精力或时间即可利用这些 API。他们只需要为 auth 令牌发送一个非空值，API 请求就会被成功处理。绝不应允许使用非空值令牌。曾经。它带来了“暂时”使用但永远不会被删除的重大风险。

　　最佳实践：始终为内部或面向公众的 API 分配令牌值。

　　API经过身份验证，但未经授权

　　只有身份验证而没有授权的 API 是另一个常见的漏洞。部分原因是实现用户身份验证“足够好”的概念，通过验证用户的授权权限几乎没有什么好处。缺点是这允许用户访问不属于他们的资源。

　　例如，假设一个用户登录来检查他们的配置文件，而后端没有强制执行强授权检查。通过更改用户标识符，用户将能够“嗅探”并通过相同的API获取信息。在这种非常常见的API风险中，通过身份验证的用户可以通过简单地枚举标识符来获取许多其他用户的信息。

　　如果标识符是简单的数值，例如攻击者可以轻松枚举的 6 位数字，则此问题会变得更糟。最基本的建议是使用随机生成的字母-数字标识符，至少可以缓解（但不能消除）此类枚举攻击的风险。

　　最佳实践：始终实施强授权机制来补充强身份验证。

　　API令牌扩散

　　应用程序开发团队通常支持不同类型的身份验证集成与其 API 的不同使用者。这最终导致 API 的身份验证方法分散，应用程序所有者难以管理。

　　例如，消费者 A 可能会在请求标头中发送一个名为 X-api-token 的 API 令牌，以向应用程序验证自己的身份。相反，拥有相同API的消费者B可能会以一个名为API -key的请求参数发送他们的API令牌，第三个消费者C可能会在Authorization头中发送他们的信息。

　　这种不同的方法导致 API 以多种方式接受身份验证令牌，这些方法中的任何一个潜在漏洞，类似于我们上面看到的那些，都可能危及所有这些方法的访问。我们的建议是强制API定义（如Swagger规范）的一致性，然后在发布之前对结果进行测试以缓解风险。至少，在运行时发现API 并检测它们中是否存在这样的碎片验证问题是很重要的。

　　最佳实践：使用 API 规范框架强制执行一致性，并使用基于功能的测试计划超越基本的渗透测试。

　　带有不正确授权逻辑的API

　　具有不正确授权逻辑的 API 允许通过接受在低权限环境（例如 dev 或 staging）中生成的身份验证令牌来访问高权限环境，例如生产环境。如果用户可以轻松访问生产环境中的敏感业务数据，这可能会迅速升级为一个重大漏洞。

　　精明的攻击者可能能够从较低的环境中获取身份验证令牌并将其重播到生产服务器。身份验证的糟糕实现将允许此类访问，因为身份验证令牌本身可能是有效的，但适用于错误的环境。为了修复这种风险，需要将 auth 令牌的授权范围适当限制在允许访问的资源范围内。

　　最佳实践：使用 OAuth Scopes 或其他工具来创建和实施设计良好的授权后端。

　　总结

　　API 身份验证令牌实际上是你的应用程序中的关键。这 5 个身份验证漏洞都在客户环境中发现，使他们的 API 容易受到攻击者入侵他们的应用程序并泄露他们无权访问的信息的攻击。

　　创建清单并分析面向公众的 API 以在攻击者发布或发现它们之前找到身份验证漏洞非常重要。