API 的5 身份验证安全隐患 _API

文章插图

最近一连串的 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 并检测它们中是否存在这样的碎片验证问题是很重要的。