保护cookie和https / http混合使用
很多站点似乎都支持https，但不使用安全cookie。 我想使我的网站使用安全的cookie，但允许使用http来访问一些内容。
一个明智的方法来做到这一点似乎是为真正的会议有一个安全的cookie和一个非安全的cookie，这只是一个标志，说如果用户login或不（在头上显示不同的东西，如注销链接而不是login链接）。 这个cookie不包含任何“真实的”会话信息，只是为了使网站可以显示与login用户相比稍微不同的页面，而不是login到网站的http部分。
有整个网站作为https是另一种select，但这似乎比普通的http相当慢，所以不是很理想。
为什么网站不使用这种设置并拥有安全的Cookie？ 盗窃cookie的可能性似乎使得安全的cookie成为现在的必需品。 有没有更好的方法来实现相同的事情？
您提出的解决scheme似乎是行之有效的，只要您不介意非授权人员能够查看站点的非安全（http）部分，就好像他们已经login一样 – 即只要该网站的http部分不包含任何敏感信息，login用户和未login用户之间的唯一区别在头部是无害的。
它不经常使用的原因可能是以下原因之一：
- 这种情况可能不是很常见。 通常情况下，如果你足够小心，使您的网站的一部分安全，你会限制login会话只是安全的部分，或者你会让整个网站总是使用HTTPS（如贝宝）。
- 现有的解决scheme存在安全性，而且能够胜任这一点，例如以HTTPSloginformslogin某人，并在将该会话传输回HTTP时保持该会话。
OpenID就是一个例子。另外认为Flickr或Gmail：他们的login页面始终是HTTPS，但一旦会话开始您迁移回HTTP，同时保持会话安全。
更新 （2014年8月）
自从我在2009年撰写这个报告以来，login屏幕具有安全连接但是一旦login就退回到HTTP的做法几乎消失了。
在侧面使用HTTPS的开销已经不再是什么大事了。 Google开发的新SPDY协议（现在演变为HTTP / 2）支持跨浏览器和主要Web服务器，并提高HTTPS速度。
最后，隐私被视为比以往任何时候都重要，即使是对authentication不重要的行为，例如写评论，上传照片等等。
谷歌最近甚至说，只有HTTPS的网站将开始在search引擎排名中受益。
从安全的angular度来看，您不应该相信通过非安全连接发送的内容。 因此，考虑到这一点，只有在窃取或滥用cookie的成本大约为零的情况下，才能安全地使用通过未encryption连接发送的cookie。
考虑到这一点，大多数网站的devise使得数据不被允许在频道之间“泄漏”。 毕竟，来自encryption端的数据通常是有特权的，因此不应该被允许在正常的通道中，而来自未encryption通道的数据可能被欺骗，并且不应该被信任。
如果您的数据不符合这些概括，请随意使用它。
通过HTTP传输会话cookie一直困扰着我。 我认为，您所描述的技术是保护cookie的唯一方法，同时使login用户可以像login一样浏览HTTP页面。但是，我很less看到这一点。
为什么网站不使用这种设置并拥有安全的Cookie？
我认为缺乏采纳的主要原因是风险pipe理 ：
- 通过窃听窃取会话令牌比跨站点脚本（假设存在漏洞）困难得多。 您需要访问networking（例如用户的LAN或ISP）。 因此，根据基于风险的优先级划分，开发人员应首先解决XSS问题，因为它提供了更大的攻击面（攻击的可能性要高得多）。
- CSRF和UI修复（也称为点击顶起）也是如此。
- 如果会话受到攻击的业务影响很大（例如存储信用卡以备以后在网上商店使用），那么将整个网站限制为HTTPS可能会更好。
另一个原因可能是可用性问题：使用您提出的scheme，您可以有效地pipe理单个用户的两个并发会话。 只要login标志是存储在不安全会话中的唯一状态，这很容易。 如果您还可以在两个会话中更改语言和国家等设置，则可能会变得混乱（要实施或使用）。
有没有更好的方法来实现相同的事情？
从Web应用程序黑客手册 ：
如果使用HTTP cookie传输令牌，则应将这些cookie标记为
secure以防止用户的浏览器通过HTTP传输它们。 如果可行，应该为应用程序的每个页面使用HTTPS，包括帮助页面，图像等静态内容。
严重的是，使整个网站使用HTTPS。 几年前，这可能是不可行的，主要是因为没有提供HTTPS支持的CDN。 但是，今天主要是平衡发展和运营成本的问题。
我完全知道，推荐的做法是在整个站点上强制使用SSL。 但是，在HTTP和HTTPS之间进行select可以派上用场的情况下，确实存在一些独特的情况。
我正在遇到类似于@David Gardner的情况。 我的公司使用第三方供应商来pipe理我们网站的商店部分，并且该商店驻留在子域“ https://store.mysite.com ”上。 我们拥有15年的video内容，而当videoembedded到SSL中时，我们当前的videopipe理供应商就会中断。 （我猜这是从HTTP域拉取资源，但这是另一天的另一个问题）
当然，我可以购买一个SSL，并通过debugging两个第三方供应商的过程，以及在我们的整个数据库（或.htaccess文件破解，但我离题）进行search和replace，以纠正任何HTTP资源链接，只是为了能够在头部有一个消息说：“欢迎你的名字”，但这似乎是矫枉过正。
下面是一个简单的Javascript解决scheme，它根据已经设置的安全cookie设置了一个站点范围内的不安全cookie。
首先， 我抓住了一些javascript cookiefunction 。 请继续将这些代码放在您网站的安全部分：
function readCookie(name) { var nameEQ = name + "="; var ca = document.cookie.split(';'); for(var i=0;i < ca.length;i++) { var c = ca[i]; while (c.charAt(0)===' ') { c = c.substring(1,c.length); } if (c.indexOf(nameEQ) === 0) { return c.substring(nameEQ.length,c.length); } } return null; } function setCookie(cname, cvalue, exdays) { var d = new Date(); d.setTime(d.getTime() + (exdays*24*60*60*1000)); var expires = "expires="+d.toUTCString(); /* Note, the W3 documents where I got this code didn't include the option to set the domain. I added this and it allows the cookie to be shared across sub-domains. Be sure not to add "www" */ document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com"; } /*Now we check our cookies on our secure server to find out if the user is logged in or not. In my case, the First Name is stored as a cookie. */ var firstNameCookie = readCookie("the-secure-cookie-name"); // if(!firstNameCookie){ /* If the cookie doesn't exist, then the person isn't logged in. Add conditional logic here if you'd like (such as deleting any current logged in cookies from the HTTP portion of the site) */ } else { /* otherwise, we have a successful login. By grabbing the cookie via this javascript resting on the secure server, we haven't compromised our security. However, if we set a cookie with javascript right now, it won't be a secure cookie by default and we'll have access to it with HTTP on the subdomain */ setCookie("HTTPfirstName", firstNameCookie, 1.5); } */The clients first name is now accessible across subdomains in the cookie entitled "HTTPfirstName" */
在这种情况下，我们唯一泄露给我们的HTTP服务器的是客户的名字。 然而，如果你想要更安全的话，你可以设置你的服务器设置为只允许某个cookie（即“firstNameCookie）”被HTTP请求访问，并且增加了一层额外的保护， 你可以学习如何做这里
当然，这不是最理想的解决scheme。 今后，我打算在全网范围内实现SSL，但是在此期间用一个简单的javascript函数replace它肯定是件好事。
