许多网站似乎支持https但不使用安全cookie.我想让我的网站使用安全cookie,但允许使用http访问某些内容.
一个明智的做法似乎是为真实会话提供一个安全的cookie,以及一个非安全的cookie,它只是一个标志,表示用户是否登录(在标题中显示不同的内容,如注销链接而不是登录链接).此cookie不包含任何"真实"会话信息,只是为了使网站可以显示登录用户与网站http部分登出的页面略有不同的页面.
将整个站点作为https是另一种选择,但这似乎比普通的http慢得多,所以不是很理想.
为什么网站不使用这种设置并拥有安全的cookie？饼干盗窃的可能性似乎使安全饼干成为必需品.有没有更好的方法来实现同样的目标？
您提出的解决方案似乎可行,只要您不介意未经授权的人员能够查看网站的非安全(http)部分,就像他们已登录一样' - 即只要该站点的http部分不包含任何敏感信息,登录和未登录用户之间的唯一区别是标题中的无害.
它不经常使用的原因可能是以下之一:
这种情况可能不太常见.通常,如果您足够关心网站的一部分是安全的,那么您只需将登录会话限制在该安全部分,或者您将使整个网站始终使用HTTPS(如Paypal).
存在预先存在的解决方案,这些解决方案是安全的并且能够实现更多,例如以HTTPS登录表单登录某人并在将其转移回HTTP时维护该会话. OpenID就是一个例子.还要考虑flickr或gmail:他们的登录页面始终是HTTPS,但是一旦会话开始,您将迁移回HTTP,同时安全地维护会话.
更新(2014年8月)
自从我在2009年写回来之后,登录屏幕安全连接但登录后退回到HTTP的做法几乎消失了.
在整个范围内使用HTTPS的开销不再是一个大问题.谷歌率先推出的新SPDY协议(现已演变为HTTP/2)支持跨浏览器和主要Web服务器,并提高了HTTPS速度.
最后,隐私被视为比以往任何时候都更重要,即使是对身份验证不重要的操作,例如撰写评论,上传照片等.
谷歌最近甚至表示,仅限HTTPS的网站将开始受益于搜索引擎排名.
从安全角度来看,您永远不应该信任通过非安全连接发送的任何内容.因此,考虑到这一点,只有当盗窃或滥用该cookie的成本大约为零时,才能安全地使用通过未加密连接发送的cookie.
考虑到这一点,大多数站点的设计使得数据不允许在通道之间"泄漏".毕竟,来自加密端的数据通常是特权的,因此不应该在正常信道中被允许,而来自未加密信道的数据可能是欺骗性的,并且不应该被信任.
如果您的数据不符合这些概括,那么请随意使用它.
通过HTTP传输会话cookie一直困扰着我.我认为您所描述的技术是保护cookie的唯一理智方式,同时使登录用户可以像登录一样浏览HTTP页面.但是,我很少看到这个实现.
为什么网站不使用这种设置并拥有安全的cookie？
我认为缺乏采用的主要原因是风险管理:
通过窃听窃取会话令牌比例如跨站点脚本(假设存在漏洞)要困难得多.您需要访问网络(例如用户的LAN或ISP).因此,根据基于风险的优先级划分,开发人员应首先解决XSS问题,因为它提供了更大的攻击面(攻击的可能性要高得多).
CSRF和UI纠正(也就是点击顶升)也是如此.
如果被黑客入侵的会话的业务影响很大(例如存储信用卡以供以后在网上商店使用),您可能最好将整个网站限制为HTTPS.
另一个原因可能是可用性问题:使用您提出的方案,您可以有效地为单个用户管理两个并发会话.只要登录标志是存储在不安全会话中的唯一状态,这就很容易了.如果您还可以在两个会话中更改语言和国家/地区等设置,则可能会变得混乱(实现或使用).
有没有更好的方法来实现同样的目标？
来自Web应用程序黑客手册:
如果使用HTTP cookie来传输令牌,则应标记这些令牌
secure以防止用户的浏览器通过HTTP传输它们.如果可行,应该为应用程序的每个页面使用HTTPS,包括静态内容,如帮助页面,图像等.
说真的,让整个网站使用HTTPS.几年前,这可能不太可行,主要是因为CDN不提供HTTPS支持.但是,今天主要是平衡开发和运营成本的问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 