使用安全会话 cookie 在 HTTP 和 HTTPS 页面之间切换 [英] Switching between HTTP and HTTPS pages with secure session-cookie

问题描述

更新:请注意，每个网站在不安全的 HTTP 和加密的 HTTPS 页面之间切换，都不可避免地容易出现 SSL-strip.请考虑对整个站点使用 HTTPS，虽然这都不能阻止 SSL-strip，但至少这让用户可以安全地调用站点，如果他关心的话.对于需要切换的站点，这种方式可能仍然是最好的选择.

Update: Note that every website switching between unsecure HTTP and encrypted HTTPS pages, is inevitable prone to SSL-strip. Please think about using HTTPS for the whole site, although this neither can prevent SSL-strip, at least this gives the user the possibility to call the site safely, if he cares. For sites that need to switch, this method is probably still the best option.

这是一个常见的场景，一个网站的页面包含敏感数据，这些页面应该只使用 HTTPS 协议访问，而其他页面包含非关键数据.

It's a common scenario, that a website has pages with sensitive data, which should be accessed only with the HTTPS protocoll, and other ones with noncritical data.

我找到了一个解决方案，它允许在安全和非安全页面之间切换，同时保持会话，并希望询问您有关概念中缺陷的任何提示.你可以在这里找到整篇文章:使用 SSL 的安全会话 cookie(当然我也很高兴听到它是安全的).

I found a solution which allows switching between secure and non secure pages, while keeping the session and would like to ask you for any hints about flaws in the concept. The whole article you can find here: Secure session cookie with SSL (of course i'm also happy to hear, that it is safe).

问题

HTTPS 确保客户端和服务器之间的任何人都无法窃听我们的通信并防止中间人攻击.不幸的是，这不适用于 session-cookie，它也被发送到未加密的请求.

HTTPS makes sure, that nobody between client and server can eavesdrop our communication and prevents a man-in-the-middle attack. Unfortunately this doesn't apply to the session-cookie, it is sent to unencrypted requests too.

PHP 提供带有参数 $secure 的函数 session_set_cookie_params(...).这正是我们所需要的，但是当我们切换到不安全的页面时，它会导致我们失去会话的问题.

PHP offers the function session_set_cookie_params(...) with the parameter $secure. This is what we need, but it leaves us to the problem that we loose our session, when we switch to an unsecure page.

身份验证 cookie

身份验证 cookie 的想法是，当用户输入他的密码(增加他的访问权限)时，我们在不安全的 session-cookie 之外创建第二个 cookie，并确保只有加密的 HTTPS 页面才能访问它.

The idea of the authentication cookie is, that when the user enters his password (increases his access privileges), we create a second cookie additionally to the unsecure session-cookie, and make sure that only encrypted HTTPS pages have access to it.

https://www.example.com/login.php

<?php
  session_start();
  // regenerate session id to make session fixation more difficult
  session_regenerate_id(true);

  // generate random code for the authentication cookie and store it in the session
  $authCode = md5(uniqid(mt_rand(), true));
  $_SESSION['authentication'] = $authCode;

  // create authentication cookie, and restrict it to HTTPS pages
  setcookie('authentication', $authCode, 0, '/', '', true, true);

  print('<h1>login</h1>');
  ...
?>

现在每个页面(HTTPS 和 HTTP)都可以读取不安全的 session-cookie，但是具有敏感信息的页面可以检查安全身份验证 cookie.

Now every page (HTTPS and HTTP) can read the unsecure session-cookie, but pages with sensitive information can check for the secure authentication cookie.

https://www.example.com/secret.php

<?php
  session_start();

  // check that the authentication cookie exists, and that
  // it contains the same code which is stored in the session.
  $pageIsSecure = (!empty($_COOKIE['authentication']))
    && ($_COOKIE['authentication'] === $_SESSION['authentication']);

  if (!$pageIsSecure)
  {
    // do not display the page, redirect to the login page
  }

  ...
?>

攻击者可以操纵会话 cookie，但他永远无法访问身份验证 cookie.只有输入密码的人才能拥有身份验证 cookie，它始终通过加密的 HTTPS 连接发送.

An attacker could manipulate the session cookie, but he never has access to the authentication cookie. Only the person who entered the password, can own the authentication cookie, it's always sent over encrypted HTTPS connections.

非常感谢您的每一个回答！

Thanks a lot for every answer!

推荐答案

一个更简单的替代方案:它正成为越来越被接受的替代方案，始终使用 TLS，而不是在安全和不安全连接之间来回切换.大部分额外的处理时间都用于设置安全隧道，但这只会执行一次并缓存(通常).在现代处理器上，后续流量的对称加密非常非常快.认为这会导致服务器开销或可扩展性问题的想法有些过时.

A simpler alternative: It is becoming an increasingly accepted alternative to use TLS all the time, rather than switching back and forth between secure and unsecure connections. The bulk of additional processing time is spent setting up the secure tunnel, but this is only done once and cached (typically). The symmetric encryption of subsequent traffic is very, very fast on modern processors. It's somewhat out-of-date thinking to believe that this would cause a server overhead or scalability issue.

在最近的一篇博文中，一位 Google 工程师报告说，当他们为 GMail 切换到仅 HTTPS 时，他们发现他们的服务器仅增加了 4%.(找不到引文.)

In a recent blog post, a Google engineer reported that when they switched to HTTPS-only for GMail, they found their server overheard increased by only 4%. (Can't find the citation.)

这篇关于使用安全会话 cookie 在 HTTP 和 HTTPS 页面之间切换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！