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.
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:
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í:
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 .
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.
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.
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.
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.