2011-04-30 16 views
27

Actualización: Tenga en cuenta que cada sitio web que cambie entre HTTP no seguro y páginas HTTPS encriptadas, 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.Alternar entre páginas HTTP y HTTPS con cookie de sesión segura

Es un escenario común, que un sitio web tiene páginas con datos confidenciales, a los que se debe acceder solo con el protocolo HTTPS, y otros 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 quisiera que le pida alguna pista sobre los defectos en el concepto. Todo el artículo que puede encontrar aquí: Secure session cookie with SSL (por supuesto, también me complace escuchar que es seguro).

El problema

HTTPS se asegura, que nadie entre cliente y servidor puede espiar nuestra comunicación e impide un ataque man-in-the-middle. 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 galletas, además, a la insegura sesión en cookies, y hacer Asegúrese de que solo las páginas HTTPS cifradas tengan acceso.

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 sesión en cookies no segura, pero las páginas con información sensible puede comprobar 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!

+0

Pero con esto, una ID de sesión interceptada todavía se puede usar en páginas que no sean HTTPS. – Gumbo

+2

Eso es cierto, pero solo verá datos no críticos. Puede solicitar todas las páginas con HTTPS, si lo considera necesario. – martinstoeckli

+1

hacer que todos los sitios sean solo https, es lo que propongo. No solo elimina problemas como este, sino que también mejora la privacidad general de todos los que navegan por su sitio. Los problemas más preocupantes surgen si alguna vez desea mantener los datos de inicio de sesión entre varios servidores y diferentes dominios porque desea servir archivos ubicados en diferentes lugares ... – nus

Respuesta

23

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.)

+1

También leo el artículo, y esta parece ser una alternativa real. Una cosa en la que pensé es que todos los recursos, como las imágenes, están encriptados también y las inclusiones externas darían como resultado una página parcialmente encriptada (en una página que de otro modo sería insegura). ¿Tiene alguna información sobre el almacenamiento en caché de PHP? ¿Funciona con HTTPS? – martinstoeckli

+0

El artículo de Google se encuentra en algún lugar del [blog de Adam Langley] (http://www.imperialviolet.org/). –

+4

Enlace del artículo: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html – stukelly

Cuestiones relacionadas