Web应用安全 三 失效的身份认证和会话管理

失效的身份认证和会话管理

与身份认证和回话管理相关的应用程序功能往往得不到正确的实现，这就导致了攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份（暂时或永久的）。

失效的身份认证和会话管理

我存在会话劫持漏洞吗?

如何能够保护用户凭证和会话ID等会话管理资产呢？以下情况可能产生漏洞：
1.用户身份验证凭证没有使用哈希或加密保护。
2.认证凭证可猜测，或者能够通过薄弱的的帐户管理功能（例如账户创建、密码修改、密码恢复, 弱会话ID）重写。
3.会话ID暴露在URL里（例如, URL重写）。
4.会话ID容易受到会话固定（session fixation）的攻击。
5.会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效。
6.成功注册后,会话ID没有轮转。
7.密码、会话ID和其他认证凭据使用未加密连接传输。

攻击案例场景

• 场景#1：机票预订应用程序支持URL重写，把会话ID放在URL里：
  http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
  该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。
• 场景#2：应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。盐
• 场景#3：内部或外部攻击者进入系统的密码数据库。存储在数据库中的用户密码没有被哈希和加盐, 所有用户的密码都被攻击者获得。

如何防止?

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帐户策略带来的好处。

补充：

- 1. 设置httponly属性.

httponly是微软对cookie做的扩展,该值指定 Cookie 是否可通过客户端脚本访问, 解决用户的cookie可能被盗用的问题,减少跨站脚本攻击,主流的大多数浏览器已经支持此属性。

• asp.net全局设置：

//global中设置有所的cookie只读
protected void Application_EndRequest(Object sender, EventArgs e)
        {
            foreach(string sCookie in Response.Cookies)
            {
                Response.Cookies[sCookie].HttpOnly = true;
                Response.Cookies[sCookie].Secure = true;
            }

        }

• JAVA

httpOnly是cookie的扩展属性，并不包含在servlet2.x的规范里，因此一些javaee应用服务器并不支持httpOnly，针对tomcat，>6.0.19或者>5.5.28的版本才支持httpOnly属性，具体方法是在conf/context.xml添加httpOnly属性设置

<Context useHttpOnly="true"> ... </Context>

另一种设置httpOnly的方式是使用Tomcat的servlet扩展直接写header

response.setHeader( "Set-Cookie", "name=value; HttpOnly");

- 2. 验证成功后更换sessionID

在登录验证成功后，通过重置session，使之前的匿名sessionId失效，这样可以避免使用伪造的sessionId进行攻击。代码如下

protected void doPost(HttpServletRequest request, HttpServletResponse response) throwsServletException, IOException { 
    String username=request.getParameter("username"); 
    Stringpassword=request.getParameter("password");
    if("admin".equals(username) &&"pass".equals(password)){ //使之前的匿名session失效 
          request.getSession().invalidate(); 
          request.getSession().setAttribute("login", true);  
          response.sendRedirect("hello.jsp"); 
    }
    else{ 
          response.sendRedirect("login.jsp");
   } 
}