这里有另外的一个: |
这就是 Aussie Farmers Direct 。它的登录界面看起来非常传统。当我们开始登录并打上"记住我"的标志的时候, 我们看一眼相关的cookies信息。 哇亲爱的,相同的处理方式但是没有任何Base64编码。事实上,这样是相当的不合理,因为你能够操作像下面这样。 XSS 你自己的 JSON cookie? 确定不! 另外的方式是改变你的密码而不要改变你的cookie。所以当你下一次返回的时候,尝试重新登入用旧的密码。哎呀。 |
Aussie Farmers Direct 没有暴露出ELMAH日志信息 (因为PHP友好的处理了它) 。但是,它仍然有其它的风险例如XSS(顺便说一下,它们多次负责任的关闭和处理了风险。)另外一件事情是上面2个网站的cookies处理密码没有标记作为HttpOnly, 你能看见它们在cookie列表的第二列。那就意味着客户端脚本访问这些cookies,那就意味着如果你能到网站上得到XSS。假如你能够让用户去运行XSS负载(现在有多种方式去做),你就能偷到包含的密码的cookies信息,访问Aussie Farmers 网站。缺少了HttpOnly属性是代表这两个网站上的马虎,但是核心的问题用cookies存储你的密码,然后使他们很容易通过其他疏漏。 |
从根本上来说,最重要的原因主要是这两个网站的疏忽。他们保护用户的证书被用在网站。在网站上,用户每一次使用"记住我"特征,用户发送了一个请求。现在有一个好的选择就是发送他们的用户名和密码到他们的邮箱,或者eBay,或者它们的银行通过线路,有时候用文本,有时候访问用客户端脚本。总是放在浏览器中未受到保护。密码重用是疯狂,而这些该死的用户该付出血淋淋的责任(我在这里转述!),我们—作为开发者—当我们处理凭据时,我们必须认识到保护远远超过只是我们自己的网站。 因此,我们应该建立"记住我"的功能的真正误区。让我们开始走向正确的实践道路。 |
一个参考的实现样本安全领域中你能经常听到的箴言之一就是“不要使用你自己的——使用已经证实是安全的”。它被非常频繁地应用于加密和身份验证方案中,但是现在我们可以将这个扩展到“记住我”的特性,以便在我们深入细节之前,先从一个好的参考实现开始。 在一个由Visual Studio 2012新建的ASP.NET MVC 4网站中,你能得到这个开箱即用的登录界面: 其它的框架有其它实现这个特性的标准模式,但这个参考起来很容易。当我们像上面这样填写字段登陆的时候(即不要让它记住我),验证成功则会返回如下cookie结果: Set-Cookie:.ASPXAUTH=6891A5EAF17A9C35B51C4ED3C473FBA294187C97B758880F9A56E3D335E2F020B86A85E1D0074BDAB2E1C9DBE590AF67895C0F989BA137E292035A3093A702DEC9D0D8089E1D007089F75A77D1B2A79CAA800E8F62D3D807CBB86779DB52F012; path=/; HttpOnly |
这只是个简单的验证cookie, 在无状态的HTTP世界里, 一个用户发送的所有请求若不是被这一小段数据关联起来的话, 都将变成完全独立的请求. 每一次这个对我唯一的cookie被发送后, 网站就会知道来访的用户是我而且我已经通过了验证. 我们可以在Chrome的Cookie记录下面看得更仔细一点儿: ![]() 顺带说一下, 第二个cookie是一个用于阻止CSRF攻击的反伪造令牌, 这和我们的验证状态没啥关系, 除此以外就没有其他cookie了. 现在, 我们登录并要求网站记住我, 下面是响应的cookie值: Set-Cookie:.ASPXAUTH=3A92DAC7EFF4EE5B2027A13DD8ABEA8254F0A16D8059FCAF60F5533F1B7D99462DDF57320D069A493481978750526DF952D5C9EA0371C84F5CF1BFC0CCA024C2052824D4BA09670A42B85AEC7FFCB4088FC744C6C0A22749F07AF6E65E674A4A; expires=Tue, 02-Jul-2013 00:27:05 GMT; path=/; HttpOnly 啊哈 – 看到了吧?! 如果你在Chrome下面查看被分解开来的cookie值就会变得更加清楚: ![]() 现在, 我们有了一个从当前开始有效期为48小时的cookie, 相反的是不设置过期时间的cookie将会在浏览器被关闭之后被立即清除. 让我们来近距离的看一看. |