纵观授权cookie的失效 事实上,这个一个可笑的安全结构和它仅仅只是前面的例子我感觉是值得写出来,但是我们在这里。在实现当中,“记住我”功能简单地归结为当授权的cookie到期。这里做的事情是控制你想让某人登入到你网站多久,它是简单的。 在这里例子当中,ASP.NET 默认使用session cookie 或者换一句说话, a cookie 没有明确的失效时间。当用户浏览器一关闭,cookie就强制到期。 这是一种方法，另外一种就是明确一个简短时间以至于浏览器是开着的,用户自动退出的经过一段时间。当然,假如系统是运行顺畅的,你也是能够控制服务器的行为,由服务器响应增加失效时间,你也能够扩展授权cookies信息的生命周期。 记住某个人是简单的,保存授权cookie信息是激活的。多长时间让它存活呢?在这个例子中默认是2天,这个可能是短暂的对一些合法的用户来说。(尽管它可以简单的在 ASP.NET中配置) ,Facebook 可以让你的cookie信息存活持续一年。短暂的时间说明减少风险但是不方便,长时间使得用户增加窗口的潜在攻击可能。让我们看一下风险更详细。 |
| 利用长期运行的认证状态 当你不认证的时候,你的会话不能被劫持。我知道那种情况。但严重的是类似Aussie Farmers Direct的情况。cookie有效的时间是6个月。由于这个事实,网站没有标记为HttpOnly。因为网站里面有XSS缺陷并且cookie的有效时间是6个月,所以在这6个月当中,在你不经意访问网站的时候,它会把链接相关的证书发送给攻击者。假如有效时间是一个月,虽然他们在设计方面会有严重的缺陷,但是攻击者攻击窗口的机会将会减少。 另一方面，Black＆Decker公司有一个相对短的一个星期的有效期，所以在他们的情况下，与外露的ELMAH日志。是的，有一系列坏的失败对他们的一部分,但除非有人已经记录在“记住我”复选框打勾，在上周引起了未处理的异常,凭据不会被公开展出。好吧,如果你是在网站上开始有一个很好的机会(至少和Farmers例子比较,在那个网站上,你会不自觉地失去密码在你的网站浏览过程中)但你可以看到，风险状况如何变化在cookie的有效期间内。 |
| 当然所有这一切的基础是需要仔细地保护认证cookie；HttpOnly和安全属性是绝对必须要做的事情。不过古典的劫持威胁仍然要重视，然而要分离这些最终与cookie相关的特性，你就需要非常非常仔细地看看这些cookie。 最终需要考虑诸多因素，比如站点的用户数据对于攻击者的价值、返回给用户的未通过认证的阻挡页面和站点的其余安全配置等，然后再做权衡。例如，脸谱有一些有关社交方面的非常有用的数据，而且用户期望在返回时得到低冲突（甚至没有冲突）的处理，另外他们在安全方面已经给予大量的投资。另外，Aussie Framer站点用户个人拥有识别用户的数据和财务信息 而且人们认证后才获得的所提供的服务（支付功能）仍然很少理解重要的安全理念。因此这两个站点有着非常不同的风险配置，而且它们应当有非常不同的认证cookie过期策略。 |
增强授权途径很多人在审视通过cookie进行授权的途径的时候都会绝望地翻白眼, 对于安全这件事其实就是始终都有一种更好的方式(去实现), 这依赖于你愿意为之付出的时间/金钱/复杂度, 而且总会有那么一个人准备告诉你: 你搞错了! 现在让我们以授权cookie作为一个起始点, 来探寻一些可能的方式来增强这个途径. 反对长期有效的授权cookie一个论据就是, 它们实际上会保证用户处于已授权状态并且处于被攻击的风险之下, 类似于CSRF或者点击劫持之类, 当然, 应用程序需要暴露其他的风险之处才能让袭击者利用长期性的cookie, 但是关于整体纵深防御的论证又再度出现了. 一个可选方式就是保持一个专用cookie来应对那些用户 －他们在通过了服务器对会话真实性的验证之后能够在回来的时候发起一轮新的已授权会话, 这样原始的会话就马上失效了, 这里的技巧就是, 当用户带着专用的"记住我"cookie的返回的时候重新设置一个新的会话, 并在这个过程中包含进一些额外的验证. |
| 提供额外的验证的一种方式是包含用户的IP地址/用户代理/等其他显著特点的“记住我”的cookie。理由这样的：这种方式提供了一些防御劫持的cookie。这样也有个问题，就是在正常使用的情况下这些也需要。在移动世界中的情况更常见，许多终端常常共用一个IP，即使在平常的物理网络中，你也不能完全信任ISP提供的静态IP地址。至于用户代理，如Chrome和Firefox这些 浏览器更新恍如隔日，你或许会认定一个用户代理中的字符串做 属性进行存储和比较，但这将是一个有危险的做法。 使用独特的用户属性，在会话上下文间增加安全特性，cookie授权，我相信这都是有效的措施（再次回到银行），我不能说我已经看过我测试过的网站已经在使用，但使用是一个很好的理由… |
| 一个更为务实的缓解方案是：依然把认证cookie从一个专门的“记住我” cookie中分离出来，并使用后者来对用户进行重新认证，但要施加一些限制。事实是，自动持久化某人的认证状态的过程 – 不管是什么方式 – 都会要求安全模型做出妥协。一个缓解方案可以是这样：在查看特定类型的数据或者执行特定操作之前，要求一个自动重新认证的用户再次明确的输入他们的凭证。在“记住我”特性之外，这种做法并不是闻所未闻的新做法，你应该在执行高价值的操作时见过，比如银行转账。这种情形下，我们说认证用户面临着更高的风险，因为更有可能他们并不是他们所声称的那个人(也就是说，另外一个人已经坐在了电脑前并且有效的劫持了本次会话)。 |
| 我们可以应用到这种方法的另一个强化措施是确保用来记住用户的cookie在使用了以后要重置。这也意味着在服务器上使它失效，这就需要cookie的值既具有惟一性又具有持久性，例如在数据库和cookie里保存的临时变量。这有利于确保如果cookie被攻击者获得，那么它有仅仅只有一次单独的使用机会---也就是如果用户在它们失效之前不能合理的使用cookie才出现这样的情形。这儿有一片很好的小小文章，它再次谈论了这种方法的某些缓解措施，有些使用情形可能是有帮助的，不过你将需要投入更多地努力构建cookie，还有些情形是cookie困扰着合法用户（即试图在横跨多个服务器的同一个站点上记住你自己）。 最后一个值得提及的事情是：需要考虑已认证的活动会话的同一个账户的管理原则在“记住我”的上下文里是紧密相关的。例如，来自同一个用户的多个同时已认证会话是否允许？如果用户更改了它们的密码的话，是否要断开其余的会话？ 管理员是否结束已认证了的会话？这儿出现的所有问题实际上是有关如何验证和管理已认证会话的一部分，这儿的讨论仅仅关注在如何恢复哪个会话上。 |
什么时候不应该允许“记住我”？ (以及一些中间路线选择)有时允许一个认证用户长时间保持认证态根本没有意义。比如银行业就是典型的案例，如果你想强制尽快的重新认证，却将已认证的浏览器会话丢在一边不用，就会使风险变得很大。 但实际上在这里可以采取一些中间路线：
|
