Con referencia a un documento de seguridad que leí, descubrí que el cliente solo puede enviar una cookie con el conjunto de indicadores de seguridad a través de conexiones que usan HTTPS, no HTTP, pero que la propia cookie se puede configurar desde el servidor con un indicador seguro de una conexión HTTP insegura. ¿Por qué está permitido?
Las cookies seguras se pueden configurar a través de canales inseguros (por ejemplo, HTTP) según sección 4.1.2.5 de RFC 6265 . Menciona explícitamente que la marca de seguridad solo proporciona confidencialidad y no integridad, ya que una cookie de seguridad se puede configurar desde un canal inseguro, sobrescribiendo cualquier valor establecido previamente (a través de un canal seguro o de otra manera):
El atributo Seguro limita el alcance de la cookie a "seguro" canales (donde "seguro" está definido por el agente de usuario). Cuando un cookie tiene el atributo seguro, el agente de usuario incluirá el cookie en una solicitud HTTP solo si la solicitud se transmite a través de un canal seguro (generalmente HTTP sobre Seguridad de la capa de transporte (TLS) [RFC2818]).
Aunque parece ser útil para proteger las cookies de la red activa Para los atacantes, el atributo de seguridad protege solo a los cocineros. confidencialidad Un atacante de red activo puede sobrescribir seguro cookies de un canal inseguro, lo que altera su integridad (ver Sección 8.6 para más detalles).
La Sección 8.6 da varios ejemplos, pero no los copiaré y pegaré aquí debido a cómo La sección es larga.
En cuanto a por qué, no hay un caso de uso claro que yo sepa. Sospecho que el RFC se escribió desde la perspectiva de tener only el objetivo de proteger la confidencialidad y, por lo tanto, evitar que se acepten las cookies con marca segura cuando se configura a través de HTTP era una restricción innecesaria para ese objetivo. Mi conjetura sería que el fundamento era "si proporcionamos esta funcionalidad, la gente puede asumir que la integridad de las cookies está protegida por la marca de seguridad, y no queremos que la gente haga esa suposición".
Dicho esto, el hecho de que los datos puedan establecerse a través de un canal inseguro niega un poco el concepto de solo enviar el valor de cookie a través de un canal seguro, por lo que la sensibilidad de la decisión es discutible. El RFC al menos menciona que pierdes la confidencialidad si haces esto.
Citando rfc2965 que fue obsoleto por rfc6265 que Polinomio mencionó:
Seguro
OPCIONAL. El atributo seguro (sin valor) dirige al usuario Agente para utilizar solo medios seguros (no especificados) para contactar con el origen servidor cada vez que envíe esta cookie, para proteger el confidencialidad y autenticidad de la información en la cookie.
El agente de usuario (posiblemente con la interacción del usuario) PUEDE determinar qué nivel de seguridad que considere apropiado para las cookies "seguras". El atributo Seguro debe considerarse como un consejo de seguridad del servidor al agente de usuario, lo que indica que está en la sesión Interés por proteger los contenidos de las cookies. Cuando envía un "seguro" cookie de nuevo a un servidor, el agente de usuario DEBERÍA utilizar no menos de El mismo nivel de seguridad que se usó cuando recibió la cookie. desde el servidor.
(énfasis mío)
Mi interpretación es que querían que el servidor se encargara de la seguridad en el camino hacia el cliente y tener una manera de decirle al cliente que debería hacer lo mismo.
De hecho, el resultado es dudoso como se menciona en la respuesta de Polinomio.
Actualmente en la web, tenemos que aceptar que muchos navegadores y sus usuarios generalmente intentarán acceder a los recursos web a través de conexiones no seguras (HTTP).
Como tal, hay un poco de holgura en the RFC con respecto a cuando las cookies con Secure Se puede establecer una bandera de cookie. Específicamente, sí, está permitido establecer cookies con la marca de Seguridad incluso si lo está haciendo a través de una conexión HTTP.
El indicador de seguridad solo puede ser servidor para aumentar la seguridad, por lo que no hay razón para evitar que esto funcione desde un punto de vista técnico o de seguridad, aunque esto no quiere decir que sea una buena idea hacerlo. Desde un punto de vista de eficiencia, podría ser razonable responder a las solicitudes de inicio de sesión con la información de autenticación necesaria (en una cookie con el indicador de seguridad) y luego redirigir al usuario a HTTPS a donde realmente se enviará la nueva cookie de autenticación.
En este punto es posible que también se hayan enviado encabezados HSTS, por lo que el navegador no intentará usar HTTP nuevamente en el futuro, lo que mitigará futuros ataques de sobrescritura de cookies.
Ahora tendría razón al pensar que, en este punto, un atacante podría haber interceptado los datos iniciales de las cookies y, por lo tanto, utilizarlos para hacerse pasar por el usuario. Esto es menos que ideal. Pero también lo es dependiendo de que el usuario se conecte al sitio a través de HTTP y reciba un encabezado HSTS sin que un atacante manipule o elimine este encabezado. Es por eso que tenemos HSTS pre-carga. Con este fin, la precarga de la bandera de seguridad de cookies puede ser un concepto interesante.
Se puede suponer que después de configurar la cookie, el único riesgo para el usuario en términos de ataques a la red es que el navegador no tiene instrucciones HSTS para el dominio en cuestión. Luego, un atacante obliga al usuario a desinformarse (tal vez bloqueando el tráfico SSL y esperando que el usuario intente teclear nuevamente la dirección donde probablemente iniciará una conexión HTTP), intercepta las credenciales de autenticación y / o el token, elimina la seguridad marca y asegura que no se produzca una redirección de HTTPS para el cliente (mientras que potencialmente se negocia al servidor si es necesario).
Esto puede ser útil para la seguridad en ciertas situaciones, básicamente si su conexión a Internet fue alterada debido a la falta de cifrado HTTPS. Sin embargo, en la mayoría de los casos relevantes, la inyección de cookies es baja en la lista de preocupaciones en comparación con las otras funciones comprometidas.
El protocolo HTTP no ofrece actualmente una forma para que el cliente proporcione metadatos sobre la cookie.
Por ejemplo, si una cookie se configura con path=/ y luego una cookie se configura con path=/narrow-scope . Luego, si visita el sitio y visita una URL de /narrow-scope , se enviarán ambas cookies: Cookie: name=valueA, name=valueB .
El servidor no puede decir qué ruta específica se usó para cada cookie. Solo que los metadatos entre ellos son diferentes, de lo contrario se considerarían la misma cookie (con el mismo name )
De manera similar, no hay forma de marcar las Cookies como si el indicador Secure está establecido o HttpOnly . No se pasan metadatos del cliente al servidor.
Para evitar que una página HTTP establezca una cookie segura, se obtendrían dos posibilidades:
No se puede acceder a todas las cookies proporcionadas por HTTP cuando se visita la página HTTPS. Esto sería una ruptura significativa en la compatibilidad.
O los metadatos se agregan al valor Cookie proporcionado por el Cliente para que el servidor pueda saber algunas cosas al respecto. Por ejemplo, el servidor puede desear distinguir las cookies establecidas a través de JavaScript. O, como usted dice, si se configuró dentro de HTTPS o HTTP.
Esto sería un gran cambio, y no hay mucha demanda para ello. También en la mayoría de los casos no es igual a una función de seguridad.
En última instancia, la solución correcta es obligar a los usuarios a utilizar conexiones HTTPS .
La pregunta de dónde está documentado en la RFC ha sido respondida suficientemente.
Al igual que con otras funciones de seguridad, esta característica en particular ("cookie segura") tiene un único objetivo: evitar que un espectador / sniffer obtenga su cookie.
No pretende ser una panacea contra todos los tipos posibles de ataques de cookies, sino solo este ataque muy específico:
Podemos suponer que 1., 2. y 3. son más difíciles de atacar que 4./5.
El usuario podría estar capacitado para verificar que un formulario de inicio de sesión muestre una URL de HTTPS y una "bandera verde" al lado de la URL, según el navegador. En el momento en que ingresa sus credenciales, puede esperarse razonablemente que un usuario inteligente preste atención a la URL, en estos días. (Así es como funciona el ataque habitual de correo no deseado, engañándolos para que ingresen su nombre de usuario / pw en alguna URL arbitraria, un tema para otro día).
Es muy difícil atacar a menos que el servidor tenga errores: el servidor sabe perfectamente bien si la conexión es HTTP o HTTPS, por lo que solo creará una sesión si se trata de HTTPS. Un sistema realmente importante mejor no escuchará en HTTP de todos modos.
Las solicitudes regulares no necesitan ser atacadas. Revisarán una conexión HTTPS segura y todo estará bien.
Hacer que un navegador se conecte a direcciones URL arbitrarias es bastante fácil: solo tiene que colocar una etiqueta en algún lugar o disparar algo de AJAX, si puede. Y algunos servidores pueden descargar imágenes estáticas y, de todos modos, una conexión insegura para ahorrar CPU, por lo que un atacante no tendrá que hacer nada en absoluto.
Entonces, este escenario es evitado por la cookie segura. La cookie solo pasará por HTTPS, por lo que el atacante no puede oler la cookie.
Claro, hay muchos otros vectores de ataque para obtener la cookie (man-in-the-middle contra HTTPS; en su lugar, leerlo con Javascript (evitado por el indicador "httponly"); realizar una solicitud HTTPS a un sitio web del atacante con una cookie demasiado laxa (evitada por políticas del mismo origen o configurando el dominio de la cookie correctamente en el lado del servidor), etc.).
Tenga en cuenta que es difícil protegerse contra 4. Es bastante fácil hacer que un navegador solicite cualquier URL arbitraria. Tenga en cuenta que no es necesario que solicite realmente una URL válida , solo necesita que el navegador envíe la solicitud HTTP (incluida la cookie); no le importa el resultado, y es imposible que el servidor impida que el navegador envíe la solicitud insegura en primer lugar, excepto que no escuche en HTTP, es decir, que no tenga el puerto TCP / IP abierto. Pero incluso esto no es suficiente; Si el usuario pasa por un proxy (común en las intranets corporativas), entonces el navegador seguirá enviando la solicitud HTTP al proxy (a través de HTTP), y un atacante que se encuentre entre el navegador y el proxy todavía tendrá la cookie, incluso si el El servidor real nunca aceptó la conexión TCP / IP.
La cookie "segura" está destinada a proteger contra un problema muy específico que de otra forma sería imposible proteger contra.
No está pensado para proteger contra un servidor defectuoso, perezoso o mal configurado que envía la cookie a través de un canal inseguro en primer lugar.
Hacerlo de esta manera (es decir, una característica contra un ataque específico) es algo bueno, y es lo que hacen la mayoría de las características de seguridad. Se espera que razonen sobre los tipos de ataques contra los que una característica como esta no protege contra no ; y este razonamiento es bastante sencillo porque el alcance de la función es limitado.