程序员攻克安全：OWASP API 安全十大风险系列——失效的身份验证

身份验证失效入选 OWASP API 安全风险列表并不令人意外，因为身份验证机制向来以难以正确实现而著称。此外，攻击者还占据了一定的优势，因为从本质上讲，大多数身份验证挑战必须向用户公开，这让攻击者有机会对其进行研究，并寻找可利用的模式或漏洞。

最后，由于身份验证通常是通往应用程序乃至整个网络的门户，它们往往成为攻击者的诱人目标。如果身份验证过程存在缺陷或漏洞，攻击者很有可能会发现并利用这些弱点。

因此，在本章中，我们将学习如何防范身份验证问题，将不法分子拒之门外。如果您想先测试一下自己的技能，请前往参与我们的游戏化挑战：

想要提高分数吗？请继续阅读，我们将为您详细拆解。

身份验证失效或配置错误的例子有哪些？

一个不太明显的例子是身份验证方法容易受到撞库攻击的影响，即利用已知的用户名和密码列表来破解安全防线。即使是通常非常安全的多因素身份验证方法，如果请求没有受到限制、限流或进行其他监控，也可能存在漏洞。

例如，攻击者可以通过向 api/system/verification-codes 发送 POST 请求并在请求正文中提供用户名来触发密码恢复请求。如果应用程序使用短信验证码（向用户手机发送六位数字代码），但输入字段没有限制，那么该应用程序在几分钟内就可能被攻破。攻击者只需将所有可能的六位数字组合发送到应用程序，直到试出正确的代码即可。

在这种情况下，表面上看，使用双因素身份验证似乎能保证应用程序的安全。但由于用户输入没有进行速率限制，身份验证机制实际上已经失效并存在漏洞。

在另一个例子中，应用程序可能会使用编码后的用户对象作为身份验证 Cookie。但如果拥有低权限访问权限的攻击者使用 Base64 对该 Cookie 进行解码，他们就能发现 Cookie 是如何向应用程序定义会话和用户的。例如，解码后他们可能会看到以下 JSON 数据：

{
"username" : "ShadyGuy",
"role" : "user"
{

此时，恶意用户可以更改其用户名、角色或两者兼有。通过修改几个值，他们就能摇身一变，成为拥有更高权限的其他用户：

{
"username" : "GoodGuy",
"role" : "admin"
{

此时，如果攻击者将信息重新编码并将其设置为 Cookie 值，他们实际上就变成了拥有更高权限的新用户。除非采取了防止此类更改的措施，否则应用程序很有可能会接受这种转换。

消除身份验证失效或配置错误

如果身份验证失败，整个系统的安全性很可能会受到威胁。但在编写应用程序时遵循一些重要的准则，有助于确保一切安全无虞。

首先，请务必在所有允许用户访问程序功能的地方加入身份验证检查。如果根本不存在身份验证检查，那么这场防御战从一开始就输了。

在最佳实践方面，需要牢记的一点是：避免在用户可访问的 URL 中暴露会话 ID。在上面关于身份验证失效的第二个例子中，如果会话 Cookie 从未暴露给攻击者，那么阻止他们尝试解码该 Cookie 就会容易得多。

实施多因素身份验证也是一个明智之举。您可以使用硬件令牌安全地实现这一点，这些令牌会按严格的时间表通过算法生成密码。如果您无法为用户提供此类设备，短信验证码也是一种可行方案。但您必须确保限制用户的请求频率，例如在 30 秒内仅允许尝试三到四次，并确保验证码在几分钟后即刻失效。使用字母数字组合的验证码，通过增加字符和数字的组合，也能进一步提升安全性。

最后，如果可能的话，请避免使用用户名或可预测的顺序值作为会话 ID。建议使用安全的服务器端会话管理器，每次都生成一个随机的会话 ID。

实施安全的身份验证方法比应对一般的漏洞要复杂一些。但由于授权对于每个应用程序、程序和 API 都至关重要，因此多花些时间确保其正确性是非常值得的。

请查看 Secure Code Warrior 博客页面，深入了解此漏洞，以及如何保护您的组织和客户免受其他安全漏洞的侵害。您还可以 申请演示 Secure Code Warrior 培训平台，以保持您的网络安全技能精进且与时俱进。