最新的2021 Top 10已经出来了，我们从A01开始进行一次详细解读，本系列会详细介绍各个漏洞的变化与内容，并会着重介绍新增的漏洞情况。本篇解读A07 Identification and Authentication Failures（认证及验证机制失效）。

A07 Identification and Authentication Failures（认证及验证机制失效）

弱点因素

弱点描述

确认用户的身分、认证、会话(session)管理对于防止与认证相关的攻击至关重要，如果应用程式存在以下情况，则可能有认证的漏洞:

• 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击。

• 允许暴力或其他自动化攻击。

• 允许预设、脆弱、常见的密码，像是"Password1"或"admin/admin"。

• 使用脆弱或无效的认证资讯回复或忘记密码的流程，如不安全的"知识相关问答"。

• 将密码使用明码、加密或较脆弱杂凑法的方式储存(参考 A3: 2017-敏感性资料泄漏)。

• 不具有或是无效的多因素认证。

• 于 URL 中泄漏会话(session) ID(如 URL 重写)。

• 成功登入后没有轮换会话(session) ID。

• 没有正确的注销会话(session) ID。用户的会话(session)或认证 tokens(主要是单一登入(SSO)token) 没有在登出时或一段时间没活动时被适当的注销。

如何预防

• 在可能的情况下，实作多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复利用的攻击。

• 不要交付或部署任何预设的认证资讯，特别是管理者。

• 实作脆弱密码的检查，如测试新设定或变更的密码是否存在于前 10,000 个最差密码清单。

• 将密码长度、复杂度、和轮换政策与"NIST 800-63b 第 5.1.1 节-被记忆的秘密或其他现代基于证据的密码政策"保持一致。

• 对所有结果使用相同的讯息回应，确保注册、认证资讯回复、以及 API 路径能够抵御帐号列举攻击。

• 限制或增加失败登入尝试的延迟。记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告警。

• 使用伺服器端、安全的内建会话(session)管理器，在登入后产生新的高乱数随机程度(entropy)的随机会话(session)ID。会话(session)ID 不应出现在 URL 中，必须被安全的储存，并且在登出后、闲置、超时后被注销。

攻击情境范例

情境 #1:使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用程式没有实施自动化威胁或撞库攻击的保护，在这种情况下，应用程式会被利用为密码预报的工具来判断认证资讯是否有效。

情境 #2:大多数的认证攻击是因为持续的使用密码作为唯一因素，最佳实践、密码轮换、以及复杂度的要求会鼓励用户使用和重复使用脆弱的密码。建议组织按照 NIST 800-63 停止这些做法并使用多因素认证。

情境 #3:应用程式的会话超时没有被设定正确。一个用户使用公用电脑来存取应用程式时，用户没有选择"登出"而是简单的关闭浏览器分页就离开，此时一个攻击者在一小时后使用同一个浏览器，前一个用户仍然处于通过认证的状态。

身份认证和会话管理：

在进一步解释这种危险的漏洞之前，让我们了解一下身份认证和会话管理的基本知识。身份认证，最常见的是登录功能，往往是提交用户名和密码，在安全性要求更高的情况下，有防止密码暴力破解的验证码，基于客户端的证书，物理口令卡等等。

会话管理，HTTP本身是无状态的，利用会话管理机制来实现连接识别。身份认证的结果往往是获得一个令牌，通常放在cookie中，之后对用户身份的识别根据这个授权的令牌进行识别，而不需要每次都要登陆。

什么是失效的身份认证和会话管理？

用户身份认证和会话管理是一个应用程序中最关键的过程，有缺陷的设计会严重破坏这个过程。在开发Web应用程序时，开发人员往往只关注Web应用程序所需的功能。由于这个原因，开发人员通常会建立自定义的认证和会话管理方案。但要正确实现这些方案却很难，结果这些自定义的方案往往在如下方面存在漏洞：退出、密码管理、超时、记住我、秘密问题、帐户更新等等。因为每一个实现都不同，要找出这些漏洞有时会很困难。

一些存在此漏洞的例子：

1、用户更改密码之前不验证用户，而是依靠会话的IP地址;

2、没有会话超时限制;

3、用户忘记密码后，密码找回功能太过简单。

例1：应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。

例2：机票预订应用程序支持URL重写，把会话ID放在URL里：http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。

例3：内部或外部攻击者进入系统的密码数据库. 存储在数据库中的用户密码没有被加密, 所有用户的密码都被攻击者获得。

如何验证程序是否存在失效的认证和会话管理？

最需要要保护的数据是认证凭证(credentials) 和会话ID。

1.当存储认证凭证时，是否总是使用hashing或加密保护吗?

2. 认证凭证是否可猜测，或者能够通过薄弱的的帐户管理功能

(例如账户创建、密码修改、密码恢复, 弱会话ID)重写？

3.会话ID是否暴露在URL里(例如, URL重写) ？

4.会话ID是否容易受到会话固定(session fixation) 的攻击?

5.会话ID会超时吗? 用户能退出吗?

6.成功注册后,会话ID会轮转吗?

7. 密码、会话ID和其他认证凭据是否只通过TLS连接传输？

如何防范：

1、区分公共区域和受限区域

站点的公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。考虑一个典型的零售网站。您可以匿名浏览产品分类。当您向购物车中添加物品时，应用程序将使用会话标识符验证您的身份。最后，当您下订单时，即可执行安全的交易。这需要您进行登录，以便通过SSL 验证交易。

将站点分割为公共访问区域和受限访问区域，可以在该站点的不同区域使用不同的身份验证和授权规则，从而限制对 SSL 的使用。使用SSL 会导致性能下降，为了避免不必要的系统开销，在设计站点时，应该在要求验证访问的区域限制使用 SSL。

2、对最终用户帐户使用帐户锁定策略

当最终用户帐户几次登录尝试失败后，可以禁用该帐户或将事件写入日志。如果使用 Windows 验证(如 NTLM 或Kerberos协议)，操作系统可以自动配置并应用这些策略。如果使用表单验证，则这些策略是应用程序应该完成的任务，必须在设计阶段将这些策略合并到应用程序中。

请注意，帐户锁定策略不能用于抵*制服务攻击。例如，应该使用自定义帐户名替代已知的默认服务帐户(如IUSR_MACHINENAME)，以防止获得 Internet 信息服务 (IIS) Web服务器名称的攻击者锁定这一重要帐户。

3、支持密码有效期

密码不应固定不变，而应作为常规密码维护的一部分，通过设置密码有效期对密码进行更改。在应用程序设计阶段，应该考虑提供这种类型的功能。

4、能够禁用帐户

如果在系统受到威胁时使凭证失效或禁用帐户，则可以避免遭受进一步的攻击。5、不要在用户存储中存储密码

如果必须验证密码，则没有必要实际存储密码。相反，可以存储一个单向哈希值，然后使用用户所提供的密码重新计算哈希值。为减少对用户存储的词典攻击威胁，可以使用强密码，并将随机salt 值与该密码结合使用。

5、要求使用强密码

不要使攻击者能轻松破解密码。有很多可用的密码编制指南，但通常的做法是要求输入至少 8位字符，其中要包含大写字母、小写字母、数字和特殊字符。无论是使用平台实施密码验证还是开发自己的验证策略，此步骤在对付粗暴攻击时都是必需的。在粗暴攻击中，攻击者试图通过系统的试错法来破解密码。使用常规表达式协助强密码验证。

6、不要在网络上以纯文本形式发送密码

以纯文本形式在网络上发送的密码容易被窃听。为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。

7、保护身份验证 Cookie

身份验证 cookie被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护验证票证。另外，还应限制验证票证的有效期，以防止因重复攻击导致的欺骗威胁。在重复攻击中，攻击者可以捕获cookie，并使用它来非法访问您的站点。减少 cookie 超时时间虽然不能阻止重复攻击，但确实能限制攻击者利用窃取的 cookie来访问站点的时间。

8、使用 SSL 保护会话身份验证 Cookie

不要通过 HTTP 连接传递身份验证 cookie。在授权 cookie 内设置安全的 cookie 属性，以便指示浏览器只通过HTTPS 连接向服务器传回 cookie。

9、对身份验证 cookie 的内容进行加密

即使使用 SSL，也要对 cookie 内容进行加密。如果攻击者试图利用 XSS 攻击窃取cookie，这种方法可以防止攻击者查看和修改该 cookie。在这种情况下，攻击者仍然可以使用 cookie 访问应用程序，但只有当cookie 有效时，才能访问成功。

10、限制会话寿命

缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短，攻击者捕获会话 cookie并利用它访问应用程序的时间越有限。

11、避免未经授权访问会话状态

考虑会话状态的存储方式。为获得最佳性能，可以将会话状态存储在 Web 应用程序的进程地址空间。然而这种方法在 Web场方案中的可伸缩性和内涵都很有限，来自同一用户的请求不能保证由同一台服务器处理。在这种情况下，需要在专用状态服务器上进行进程外状态存储，或者在共享数据库中进行永久性状态存储。ASP.NET支持所有这三种存储方式。

对于从 Web 应用程序到状态存储之间的网络连接，应使用 IPSec 或 SSL 确保其安全，以降低被窃听的危险。另外，还需考虑Web 应用程序如何通过状态存储的身份验证。

在可能的地方使用 Windows验证，以避免通过网络传递纯文本身份验证凭据，并可利用安全的 Windows 帐户策略带来的好处。