在一般情况下，Web开发人员在开发过程中是留意常规的Web安全漏洞的。但也有一些危险和鲜为人知的漏洞广泛存在于Web应用程序中。大多数开发人员针对这些漏洞不做任何考虑，使得Web应用程序仍然处于危险中。失效的认证和会话管理就是这类漏洞之一。根据最新的OWASP TOP 10显示它位列10大Web漏洞中的第三位。这意味着它是一个高度危险的漏洞存在于互联网上的多数网站的应用程序中。
身份认证和会话管理
在进一步解释这种危险的漏洞之前，让我们了解一下身份认证和会话管理的基本知识。身份认证，最常见的是登录功能，往往是提交用户名和密码，在安全性要求更高的情况下，有防止密码暴力破解的验证码，基于客户端的证书，物理口令卡等等。会话管理，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 值与该密码结合使用。
6、要求使用强密码
不要使攻击者能轻松破解密码。有很多可用的密码编制指南，但通常的做法是要求输入至少 8 位字符，其中要包含大写字母、小写字母、数字和特殊字符。无论是使用平台实施密码验证还是开发自己的验证策略，此步骤在对付粗暴攻击时都是必需的。在粗暴攻击中，攻击者试图通过系统的试错法来破解密码。使用常规表达式协助强密码验证。
7、不要在网络上以纯文本形式发送密码
以纯文本形式在网络上发送的密码容易被窃听。为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
8、保护身份验证 Cookie
身份验证 cookie 被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护验证票证。另外，还应限制验证票证的有效期，以防止因重复攻击导致的欺骗威胁。在重复攻击中，攻击者可以捕获 cookie，并使用它来非法访问您的站点。减少 cookie 超时时间虽然不能阻止重复攻击，但确实能限制攻击者利用窃取的 cookie 来访问站点的时间。
9、使用 SSL 保护会话身份验证 Cookie
不要通过 HTTP 连接传递身份验证 cookie。在授权 cookie 内设置安全的 cookie 属性，以便指示浏览器只通过 HTTPS 连接向服务器传回 cookie。有关详细信息，请参阅模块 10：构建安全的 ASP.NET 网页和控件。
10、对身份验证 cookie 的内容进行加密
即使使用 SSL，也要对 cookie 内容进行加密。如果攻击者试图利用 XSS 攻击窃取 cookie，这种方法可以防止攻击者查看和修改该 cookie。在这种情况下，攻击者仍然可以使用 cookie 访问应用程序，但只有当 cookie 有效时，才能访问成功。
11、限制会话寿命
缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短，攻击者捕获会话 cookie 并利用它访问应用程序的时间越有限。
12、避免未经授权访问会话状态
考虑会话状态的存储方式。为获得最佳性能，可以将会话状态存储在 Web 应用程序的进程地址空间。然而这种方法在 Web 场方案中的可伸缩性和内涵都很有限，来自同一用户的请求不能保证由同一台服务器处理。在这种情况下，需要在专用状态服务器上进行进程外状态存储，或者在共享数据库中进行永久性状态存储。ASP.NET 支持所有这三种存储方式。
对于从 Web 应用程序到状态存储之间的网络连接，应使用 IPSec 或 SSL 确保其安全，以降低被窃听的危险。另外，还需考虑 Web 应用程序如何通过状态存储的身份验证。在可能的地方使用 Windows 验证，以避免通过网络传递纯文本身份验证凭据，并可利用安全的 Windows 帐户策略带来的好处。
