php - secure - Alternar entre páginas HTTP y HTTPS con cookie de sesión segura

non httponly session cookies identified

Question

Actualización: tenga en cuenta que cada sitio web que cambie entre HTTP no seguro y páginas HTTPS cifradas, es inevitable propenso a SSL-strip . Por favor, piense en usar HTTPS para todo el sitio, aunque esto tampoco puede evitar la tira SSL, al menos esto le da al usuario la posibilidad de llamar al sitio de manera segura, si le importa. Para los sitios que necesitan cambiar, este método es probablemente la mejor opción.

Es un escenario común, que un sitio web tenga páginas con datos confidenciales, a las que se debe acceder solo con el protocolo HTTPS, y otras con datos no críticos.

Encontré una solución que permite cambiar entre páginas seguras y no seguras, mientras mantengo la sesión y me gustaría pedirle alguna pista sobre las fallas en el concepto. Todo el artículo que puede encontrar aquí: cookie de sesión segura con SSL (por supuesto, también me complace escuchar que es seguro).

El problema

HTTPS se asegura de que nadie entre el cliente y el servidor pueda interceptar nuestra comunicación y evitar un ataque de intermediario. Lamentablemente, esto no se aplica a la cookie de sesión, sino que también se envía a solicitudes no cifradas.

PHP ofrece la función session_set_cookie_params (...) con el parámetro $ secure. Esto es lo que necesitamos, pero nos deja el problema de que perdemos nuestra sesión cuando cambiamos a una página no segura.

La cookie de autenticación

La idea de la cookie de autenticación es que, cuando el usuario introduce su contraseña (aumenta sus privilegios de acceso), creamos una segunda cookie adicionalmente a la cookie de sesión no segura y nos aseguramos de que solo las páginas HTTPS cifradas tengan acceso a ella.

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>'');
  ...
?>

Ahora, cada página (HTTPS y HTTP) puede leer la cookie de sesión insegura, pero las páginas con información confidencial pueden buscar la cookie de autenticación segura.

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
  }

  ...
?>

Un atacante podría manipular la cookie de sesión, pero nunca tiene acceso a la cookie de autenticación. Solo la persona que ingresó la contraseña puede poseer la cookie de autenticación, siempre se envía a través de conexiones HTTPS cifradas.

Muchas gracias por cada respuesta!

Answer 1

Una alternativa más simple: se está convirtiendo en una alternativa cada vez más aceptada para usar TLS todo el tiempo, en lugar de alternar entre conexiones seguras y no seguras. La mayor parte del tiempo de procesamiento adicional se emplea para configurar el túnel seguro, pero esto solo se realiza una vez y se almacena en caché (normalmente). El cifrado simétrico del tráfico posterior es muy, muy rápido en los procesadores modernos. Es un poco anticuado pensar que esto causaría un problema de sobrecarga o escalabilidad del servidor.

En una publicación de blog reciente, un ingeniero de Google informó que cuando cambiaron a HTTPS solo para GMail, descubrieron que su servidor se escuchó incrementado en solo un 4%. (No se puede encontrar la cita)