Por cualquier motivo NO para configurar todas las cookies para que utilicen httpon y seguro

29

Suponiendo que un sitio usa todo el HTTPS todo el tiempo (LB redirige los puertos 80 a 443), ¿hay alguna razón para no forzar que todas las cookies establecidas por la aplicación utilicen BOTH secure AND httponly ?

Actualmente, por ejemplo, una exploración PCI solo marcará el jsessionid como que no usa el atributo secure , pero mañana podría ser el otro, así que estoy tratando de adelantarme.

    
pregunta user2145893 24.05.2018 - 20:08
fuente

5 respuestas

35

Sí, hay casos en los que no desea HTTP SÓLO o SEGURO.

Solo para HTTP, es posible que desee que javascript interactúe con la cookie. Tal vez rastree el estado de la página en una cookie, escriba en la cookie con JS y lea desde JS. También a menudo veo CSRF implementado con una cookie no solo de http.

Para la cookie segura, no esperaría que alguna cookie tuviera el atributo de seguridad, excepto en estos dos casos:

  1. los entornos de desarrollo a menudo no tienen o necesitan tener certificados TLS (aunque quizás deberían)
  2. para rastrear la actividad que se originó en http. Incluso puede utilizar su equilibrador de carga para establecer una cookie insegura antes de que envíe el redireccionamiento. Luego, el análisis de su aplicación puede rastrear qué URL ingresaron como HTTP.

En la práctica, si está ejecutando un sitio https, siempre configure la cookie segura , y si no conoce los requisitos de JS, siempre aparecerá el error en el lado con HTTPONLY configurado .

ACTUALIZAR PARA ABORDAR COMENTARIOS

Hablamos mucho sobre si deberías o no usar TLS en producción. Publiqué la pregunta aquí:

¿Debo desarrollar con TLS activado o desactivado?

    
respondido por el Jonathan 24.05.2018 - 22:48
fuente
20

Respecto a httponly , básicamente está preguntando si son casos de uso en los que JavaScript debe leer o configurar una cookie. Por lo general, algunas configuraciones de la interfaz de usuario (elección de idioma ...) se conservan de esta manera, lo que se rompería si la cookie es httponly.

En cuanto a secure : ya que de acuerdo con su descripción, el sitio usa https todo el tiempo, no es perjudicial tener todas las cookies secure .

    
respondido por el Steffen Ullrich 24.05.2018 - 20:28
fuente
9

Marca de seguridad

Teniendo en cuenta que la aplicación se ejecuta sobre HTTPS, es decir, LB redirige todo el tráfico del puerto 80 a 443, aún es necesario habilitar el indicador de seguridad a la luz del siguiente escenario.

  1. Supongamos que hay un problema de desarrollo como resultado de lo cual un hipervínculo contiene el enlace HTTP (por ejemplo, enlace ) en lugar de el enlace HTTPS (por ejemplo, enlace ).
  2. El navegador solicita el recurso web a través de HTTP y envía la cookie junto con él debido a la ausencia del indicador de seguridad.
  3. La solicitud llega al LB que redirige el tráfico al puerto 443, es decir, a través de HTTPS.
  4. El navegador reinicia la solicitud, pero esta vez a través de HTTPS con el valor de la cookie.

Por lo tanto, aunque el LB está configurado para redirigir el tráfico inseguro del puerto 80 al tráfico seguro del puerto 443, un ataque MiTM exitoso podría tener lugar en step 2 dando como resultado la suplantación de identidad de un usuario mediante el robo de cookies confidenciales. Además, verificar que los hipervínculos y las redirecciones estén correctamente codificados es una actividad comparativamente más vigorosa que habilitar el indicador de seguridad en las cookies confidenciales. Para concluir, aunque se establece una redirección en el nivel LB, podría haber posibles escenarios en los que se pudiera ejecutar un MiTM fructífero debido a la ausencia del indicador de seguridad.

enlace

Este es un indicador cuyo significado permanece independiente de la Seguridad de la capa de transporte (SSL / TLS). La marca httponly se usa para evitar que javascript acceda a cookies confidenciales como las cookies de sesión en el caso de un ataque exitoso de scripts entre sitios (XSS). Cuando la marca httponly no está configurada en el valor de la cookie, el javascript malicioso inyectado en la aplicación debido a una falla en el nivel de la aplicación podría terminar saboteando la confidencialidad, integridad y disponibilidad de las cuentas de usuario al leer cookies de sesión y enviarlas a servidores remotos, por ejemplo. , suplantando así con éxito a un usuario legítimo. Por lo tanto, la marca httponly siempre debe establecerse en todas las cookies o al menos en las sensibles.

    
respondido por el Tony Thomas 24.05.2018 - 21:45
fuente
4

Le daré un ejemplo práctico de una cookie no httponly.

Cuando un visitante llega a mi sitio, hay dos cookies que se le meten por la garganta.

phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax

El cookie_law contiene un objeto de cookie codificado en json codificado en base64 que almacena la configuración de la cookie.

Mi javascript lee esas cookies para determinar si se cargan los análisis, los adwords dependen del permiso o el estado.
Mi javascript también usa esa cookie para hacer que el editor de configuración de cookies funcione.

Si configuro el indicador httponly en las cookies, el javascript no puede leerlo. Y no puedo usar php para determinar el estado de la carga al renderizar los scripts debido a las múltiples capas de almacenamiento en caché. Es por eso que elegí dejar el httponly de esa cookie.

El javascript necesita acceso para poder leerlo.

    
respondido por el Tschallacka 25.05.2018 - 11:25
fuente
3

enlace A veces, las preferencias del usuario (tamaño de fuente, tema, idioma, ...) se establecen y se aplican en el lado del cliente. Este es el caso más común para que no se configuren solo en http.

seguro: Como el sitio / aplicación insiste en HTTPS, no hay ninguna razón para que no use la marca de seguridad. Si el sitio / aplicación necesita ofrecer acceso a través de HTTP y usted necesita que los detalles se transfieran entre contextos encriptados / sin contextos (quizás las preferencias de visualización del usuario nuevamente), entonces debe dejar esto apagado.

Si bien puede parecer que no importa ya que actualmente fuerza el acceso a HTTPS, debe permitir fallas en eso: su aplicación puede volver a implementarse con configuraciones incorrectas o sus usuarios pueden encontrarse sujetos a un MITM (ya sea algo malicioso o una proxy mal configurado) que tiene un efecto similar y, con este indicador, las cosas fallan de manera segura (desde un punto de vista de seguridad) al dejar de trabajar en lugar de trabajar de manera insegura.

General: Como son medidas de seguridad, por pequeñas que parezcan, siempre establezca ambas, a menos que tenga una razón específica para no hacerlo, en lugar de omitir omitirlas a menos que crea que son necesarias.

    
respondido por el David Spillett 25.05.2018 - 16:10
fuente

Lea otras preguntas en las etiquetas