Session 安全cookie和混合https/http站点使用

许多网站似乎支持https，但不使用安全cookies。我想让我的网站使用安全cookies，但允许使用http访问某些内容

这样做的一个合理方法似乎是为实际会话提供一个安全cookie，以及一个非安全cookie，它只是一个表示用户是否登录的标志（在标题中显示不同的内容，例如注销链接而不是登录链接）。此cookie不包含任何“真实”会话信息，只是为了让站点可以为登录用户显示与在站点http部分上注销的用户略有不同的页面

将整个站点作为https是另一种选择，但这似乎比普通http慢了一点，因此并不理想

---

为什么网站不使用这种设置并拥有安全的cookie？饼干被盗的可能性似乎使安全饼干成为当今的必需品。有没有更好的方法来实现同样的目标？

从安全角度来看，您永远不应该信任通过非安全连接发送的任何内容。因此，考虑到这一点，只有当通过未加密连接发送的cookie被盗或误用的成本约为零时，才可以安全地使用该cookie

考虑到这一点，大多数站点的设计都不允许数据在通道之间“泄漏”。毕竟，来自加密端的数据通常是有特权的，因此不允许在正常通道中使用，而来自未加密通道的数据可能是伪造的，不应被信任

---

如果您有不符合这些概括的数据，请随意使用。

只要您不介意非授权人员能够查看非安全（http）的数据，您提出的解决方案似乎是可行的站点的一部分“就好像他们登录了”——即只要站点的http部分不包含任何敏感信息，登录用户和未登录用户之间的唯一区别是标题中的无害信息

不经常使用的原因可能是：

• 这种情况可能并不常见。通常情况下，如果您非常关心使站点的一部分安全，您可以将登录会话限制在该安全部分，或者使整个站点始终使用HTTPS（如Paypal）
• 现有的解决方案是安全的，并且能够实现更多功能，例如以HTTPS登录表单登录某人，并在将其传输回HTTP时维护该会话。OpenID就是一个例子。还可以考虑flickr或gmail：他们的登录页面总是HTTPS，但一旦会话启动，您就可以迁移回HTTP，同时安全地维护会话

---

更新（2014年8月）

自从我在2009年写这篇文章以来，为登录屏幕建立安全连接，但一旦登录就返回HTTP的做法几乎消失了

广泛使用HTTPS的开销不再是什么大问题了。谷歌首创的新SPDY协议（现已演变为HTTP/2）得到了跨浏览器和主要web服务器的支持，并提高了HTTPS速度

最后，隐私被视为比以往任何时候都更重要，即使是对身份验证不重要的行为，如写评论、上传照片等等

---

谷歌最近甚至表示，仅使用HTTPS的网站将开始在搜索引擎排名中受益。

通过HTTP传输会话cookie一直困扰着我一段时间。我认为您所描述的技术是保护cookie安全的唯一合理方法，同时使登录用户能够像登录一样浏览HTTP页面。然而，我很少看到这个实现

为什么网站不使用这种设置并拥有安全的cookie？

我认为缺乏收养的主要原因是：

• 通过窃听窃取会话令牌比跨站点脚本编写（假设存在漏洞）要困难得多。您需要访问网络（例如用户的LAN或ISP）。因此，根据基于风险的优先级划分，开发人员应该首先解决XSS问题，因为它提供了更大的攻击面（攻击的概率更高）
• 对于CSRF和UI校正（也称为点击顶升）也是如此
• 如果被黑客攻击的会话对业务的影响很大（例如存储信用卡以供以后在网上商店使用），您最好将整个站点限制为HTTPS

另一个原因可能是对可用性的担忧：使用您提出的方案，您可以有效地为单个用户管理两个并发会话。只要登录标志是存储在不安全会话中的唯一状态，这就足够容易了。如果您还可以在两个会话中更改语言和国家等设置，则可能会变得混乱（要实现或使用）

有没有更好的方法实现同样的目标？

发件人：

如果HTTP cookie用于传输令牌，则应将其标记为

安全

，以防止用户的浏览器通过HTTP传输令牌。如果可行，应用程序的每个页面都应该使用HTTPS，包括帮助页面、图像等静态内容

---

说真的，让整个网站都使用HTTPS。几年前，这可能不可行，主要是因为CDN不提供HTTPS支持。然而，今天主要是平衡开发和运营成本的问题

我完全知道推荐的做法是在整个站点上强制使用SSL。然而，在某些特殊情况下，能够在HTTP和HTTPS之间进行选择可能会派上用场

我遇到了与@Dsavid Gardner类似的场景。我的公司

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" */