session - secure - Cookies seguras y uso mixto del sitio https/http

set cookie httponly

Question

Muchos sitios parecen ser compatibles con https, pero no usan cookies seguras. Quiero que mi sitio use cookies seguras, pero para permitir que se acceda a cierto contenido usando http en su lugar.

Una forma sensata de hacer esto parece ser tener una cookie segura para la sesión real, y una cookie no segura que es solo una bandera para indicar si el usuario está conectado o no (para mostrar cosas diferentes en el encabezado, como un enlace de cierre de sesión en lugar de un enlace de inicio de sesión). Esta cookie no contendría ninguna información de sesión "real" y es solo para que el sitio pueda mostrar las páginas de forma ligeramente diferente para los usuarios que iniciaron sesión en comparación con los desconectados en porciones de http del sitio.

Tener todo el sitio como https es otra opción, pero esto parece ser bastante más lento que el simple http, por lo que no es realmente ideal.

¿Por qué los sitios no usan este tipo de configuración y tienen cookies seguras? La posibilidad de robo de cookies parece hacer que las cookies seguras sean una necesidad hoy en día. ¿Hay una mejor manera de lograr lo mismo?

Answer 1

Desde el punto de vista de la seguridad, nunca debe confiar en ningún contenido enviado a través de una conexión no segura. Entonces, con eso en mente, entonces es seguro usar una cookie enviada a través de una conexión no encriptada solo si el costo del robo o mal uso de esa cookie es aproximadamente cero.

Con esto en mente, la mayoría de los sitios están diseñados de tal manera que no se permite que los datos "se filtren" entre los canales. Después de todo, los datos provenientes del lado encriptado generalmente son privilegiados, y por lo tanto no deberían permitirse en el canal normal, mientras que los datos provenientes del canal no encriptado son potencialmente falsos y no deben ser confiables.

Si tiene datos que no se ajustan a esas generalizaciones, entonces siéntase libre de hacer con ellos lo que desee.

Answer 2

La solución que usted propone parece funcionar, siempre y cuando no le importe que las personas no autorizadas puedan ver la parte no segura (http) del sitio como si estuvieran conectadas, es decir, siempre y cuando la parte http del sitio no contiene ninguna información confidencial, y la única diferencia entre los usuarios que iniciaron sesión y los que no iniciaron sesión es algo inofensivo en el encabezado.

La razón por la que no se usa con mucha frecuencia puede ser una de las siguientes:

• Este escenario puede no ser muy común. Por lo general, si le importa lo suficiente como para hacer que una parte de su sitio sea segura, restringiría la sesión de inicio de sesión solo a esa parte segura, o haría que todo el sitio siempre use HTTPS (como Paypal).
• Existen soluciones preexistentes que son seguras y que son capaces de más que esto, por ejemplo, iniciar sesión en alguien en un formulario de inicio de sesión HTTPS y mantener esa sesión mientras se transfieren a HTTP. OpenID es un ejemplo. También piense en flickr o gmail: su página de inicio de sesión siempre es HTTPS, pero una vez que se inicia la sesión, vuelve a migrar a HTTP mientras mantiene la sesión de forma segura.

Actualización (agosto de 2014)

Desde que escribí esto en 2009, la práctica de tener una conexión segura para la pantalla de inicio de sesión, pero volver a HTTP una vez que inició sesión, casi ha desaparecido.

La sobrecarga de usar HTTPS en todo el lado ya no se ve como un gran problema. El nuevo protocolo SPDY iniciado por Google (ahora evolucionado a HTTP / 2) es compatible con varios navegadores y por los principales servidores web y mejora la velocidad de HTTPS.

Y, por último, la privacidad se considera más importante que nunca, incluso para acciones que no son críticas para la autenticación, como escribir comentarios, cargar fotos y más.

Google incluso ha dicho recientemente que los sitios que solo son HTTPS comenzarán a beneficiarse en los rankings de los motores de búsqueda.

Answer 3

La transferencia de cookies de sesión a través de HTTP me ha estado molestando por un tiempo. Creo que la técnica que describió es la única forma sensata de proteger las cookies, al tiempo que permite a los usuarios que inician sesión navegar por páginas HTTP como si estuvieran conectadas. Sin embargo, rara vez lo he implementado.

¿Por qué los sitios no usan este tipo de configuración y tienen cookies seguras?

Creo que la razón principal de la falta de adopción es la gestión del riesgo :

• Robar tokens de sesión a través de escuchas es mucho más difícil que, por ejemplo, scripts de sitios cruzados (suponiendo que exista una vulnerabilidad). Necesita acceso a la red (por ejemplo, LAN o ISP del usuario). Por lo tanto, de acuerdo con la priorización basada en el riesgo, los desarrolladores deben abordar primero los problemas de XSS porque proporcionan una superficie de ataque mucho más grande (la probabilidad de un ataque es mucho mayor).
• Lo mismo es cierto para la corrección de CSRF y UI (también conocido como click-jacking).
• Si el impacto comercial de las sesiones que se piratean es alto (por ejemplo, almacenando tarjetas de crédito para su uso posterior en una tienda web), es mejor que restrinja todo su sitio a HTTPS.

Otra razón puede ser la preocupación por la usabilidad: con el esquema propuesto, se administran efectivamente dos sesiones simultáneas para un solo usuario. Esto es bastante fácil siempre que el indicador de inicio de sesión sea el único estado almacenado en la sesión insegura. Si también puede cambiar la configuración, como el idioma y el país, desde ambas sesiones, puede volverse complicado (implementar o usar).

¿Hay una mejor manera de lograr lo mismo?

De la aplicación web Hacker''s Handbook :

Si las cookies HTTP se utilizan para transmitir tokens, éstas deben marcarse como secure para evitar que el navegador del usuario las transmita por HTTP. Si es factible, se debe usar HTTPS para cada página de la aplicación, incluido el contenido estático, como páginas de ayuda, imágenes, etc.

En serio, haz que todo el sitio use HTTPS. Hace unos años, esto podría no haber sido posible principalmente debido a CDN que no proporcionaban soporte HTTPS. Sin embargo, hoy en día se trata principalmente de equilibrar el desarrollo y los costos operativos.

Answer 4

Soy plenamente consciente de que la práctica recomendada es simplemente forzar SSL en todo el sitio. Sin embargo, existen casos únicos en los que elegir y elegir entre HTTP y HTTPS podría ser útil.

Me encontré con un escenario similar al de @Dsavid Gardner. Mi empresa utiliza un proveedor externo para administrar la porción de nuestra tienda en nuestro sitio, y esa tienda reside en el subdominio " https://store.mysite.com ". Tenemos 15 años de contenido de video, y nuestro proveedor actual de gestión de video se rompe cuando un video está incrustado en un SSL. (Supongo que está extrayendo recursos de los dominios HTTP, pero ese es otro problema para otro día)

Claro, podría comprar un SSL y pasar por el proceso de depuración de dos proveedores externos, así como hacer una búsqueda y reemplazar en toda nuestra base de datos (o un archivo .htaccess, pero estoy divagando) para corregir cualquier recurso HTTP enlaces, solo para poder tener un mensaje en el encabezado que dice "Bienvenido ''YourName''", pero eso simplemente parece excesivo.

Aquí hay una solución de Javascript simple que se me ocurrió que establece una cookie insegura en todo el sitio basada en las cookies seguras que ya están configuradas.

Primero, agarré algunas funciones de cookies de JavaScript . Continúe y coloque este código en la parte segura de su sitio:

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

En este caso, lo único que filtramos a nuestro servidor HTTP es el nombre del cliente. Sin embargo, si desea aún más seguridad, puede establecer la configuración de su servidor para permitir el acceso a ciertas cookies (es decir, "firstNameCookie") mediante una solicitud HTTP, y eso agrega una capa adicional de protección. Puede aprender cómo hacerlo aquí

Claro, esta no es la solución más ideal. En el futuro, planeo implementar SSL en todo el sitio, pero tener una función simple de javascript para reemplazarlo mientras tanto es seguro de tener.