¿Es necesario que una cookie CSRF sea HttpOnly?

Como joe dice , no existe un beneficio de seguridad real para esto. Es puro teatro de seguridad. Me gustaría resaltar esto en la documentación :

  

Si habilita esto y necesita enviar el valor del token CSRF con una solicitud AJAX, su JavaScript debe extraer el valor de una entrada de formulario de token CSRF oculta en la página en lugar de hacerlo desde la cookie.

El propósito de la bandera HttpOnly es hacer que el valor de la cookie no esté disponible en JavaScript, para que no pueda ser robado si existe una vulnerabilidad XSS. Pero el token CSRF debe estar disponible de alguna manera para que pueda enviarse por duplicado, ese es todo el punto con él, después de todo. Así que Django resuelve esto al incluir el valor en un campo de formulario oculto. Esto niega todo el beneficio de HttpOnly, ya que un atacante simplemente puede leer el valor del campo de formulario en lugar de la cookie.

Eso es correcto. Esto es un falso positivo y la persona que le proporciona este hallazgo no entiende lo que están haciendo desafortunadamente. Alguien que comprendiera los riesgos de los ataques mitm y csrf nunca te lo proporcionaría.

Si bien el token de CSRF no es secreto en una página con un formulario protegido por CSRF (y podría ser robado usando XSS), puede tener una vulnerabilidad de XSS en alguna página sin un formulario. Allí solo puede obtener el token de la cookie pero no de un campo oculto. En este caso, la seguridad se mejora mediante el uso de una cookie HttpOnly.

Todavía hay una manera de obtener el token solicitando una página que contiene un formulario a través de javascript. Puede haber formas de evitar esto, pero en la mayoría de los sitios, este ataque será posible.

  

Designar la cookie CSRF como HttpOnly no ofrece ninguna protección práctica porque CSRF es solo para proteger contra ataques entre dominios.

Esto se puede estipular de una manera mucho más general, y de una manera más simple eliminando el aspecto técnico de la "cookie CSRF".

Designar una cookie como HttpOnly, por definición, solo protege contra el acceso a través de document.cookie o métodos JS equivalentes. No evita ninguna interacción HTTP que pueda haber sido causada por el código JS; cualquier interacción que el usuario realice a través de elementos HTML, como un envío de formulario, puede ser iniciada por JS . No hay una distinción significativa de cómo se inició algo; de hecho, puede reclamar "el usuario lo inició" apuntando al usuario que lo escribe, la URL de la página web actual o la de alguna página web vinculada a la página web actual.

Esa es también la razón por la que el concepto de "reproducción automática de video" no está bien definido y no se puede prevenir de manera confiable: lo que constituye una acción voluntaria del usuario para iniciar un video es un concepto de interfaz de usuario, no un DOM (Documento Objeto modelo) concepto. El navegador no sabe que la reproducción automática del usuario hizo un gesto para reproducir un video, a menos que el video comience antes de que el usuario realice ningún movimiento (como "espacio para desplazarse hacia abajo"). (Uno puede intentar "reproducir un topo" en algunos casos, como uno puede tratar de "molestar" (detectar, en la lista negra) anuncios web molestos, o compartir información con dominios de terceros, pero sin garantía de cobertura .)

A menos que JS esté completamente desactivado en un dominio, cualquier acción del usuario dentro del marco controlado por el sitio web debe asumirse como factible por el script del sitio web. ¿Una de las redes modernas, que apaga JS completamente en la mayoría de los dominios? Casi nadie.

Entonces la observación generalizada es:

Designar cualquier cookie como HttpOnly no ofrece ninguna protección práctica contra cualquier ataque que realice acciones que el usuario pueda realizar a través de la interfaz del sitio web.

Tenga en cuenta que la lectura de todas las cookies (incluidas las marcadas como HttpOnly) no se realiza mediante la interfaz del sitio web, solo se puede hacer con la herramienta Inspector del navegador o el proxy HTTP para las cookies enviadas a través de HTTP.