¿Pueden las bibliotecas de JavaScript de terceros acceder a los encabezados http de la página html de alojamiento?

2

Por lo tanto, tengo un sitio web, utiliza una cookie almacenada en el encabezado http del documento html descargado para mantener la sesión mientras el usuario final inicia sesión y accede a los datos "seguros". Esta página web también incluye javascripts alojados por terceros que se utilizan para fines de marketing y análisis. ¿Puede alguno de esos javascripts de terceros leer los encabezados http del documento http de alojamiento?

    
pregunta Sean Bradley 17.08.2015 - 08:12
fuente

2 respuestas

1

Como los comentaristas te sugirieron correctamente, necesitarás usar la solución HttpOnly como solución. Pero solo quiero agregar una nota con respecto a los comentarios correctos que recibiste sobre la marca HttpOnly .

De hecho, si un cliente de su sitio web utiliza un navegador Mozilla Firefox de la versión anterior a la 3.0.6 ( Bug 380418 : XMLHttpRequest permite leer cookies HTTPOnly ) y / o SeaMonkey de la versión anterior a 1.1.15 ( Rough Changelog para SeaMonkey 1.1.4 ) HttpOnly no será útil porque esta marca no podrá eliminar la información de cookies de los encabezados de respuesta en MLHttpObject.getAllResponseHeaders() .

Lecturas adicionales .

    
respondido por el user45139 17.08.2015 - 18:07
fuente
0

También se debe tener en cuenta que a pesar de que los scripts no pueden ver las cookies de sus usuarios (si usan HttpOnly), aún pueden ver todo el DOM (contenido de la página web) y pueden enviar solicitudes en nombre del usuario. El navegador incluirá automáticamente las cookies con cada solicitud a su servidor, aunque el script que envía la solicitud no puede ver las cookies. Desde la perspectiva del servidor, esto es idéntico al usuario que realiza la acción ellos mismos.

¡Incluir guiones de terceros es peligroso! No lo hagas a menos que confíes sinceramente en la fuente del script. Cualquier secuencia de comandos de terceros que incluya en su página es, desde un punto de vista de seguridad, continuamente en la posición de tener una explotación exitosa de XSS (Cross-Site Scripting) en sus usuarios ... y depende de ellos qué hacer con ella.

Incluso si la fuente del script no actúa maliciosamente , todavía pueden destruir su sitio literalmente por accidente si hay un error en el script o en un servidor Se va o algo así. Por ejemplo, considere esa vez que Facebook rompió la web porque el script que pone el botón Like en una página funcionó mal.

Puedes mitigar este riesgo un poco al alojar scripts, pero a veces eso no es una opción o, a veces, el propio script extrae recursos externos.

    
respondido por el CBHacking 16.09.2015 - 21:32
fuente

Lea otras preguntas en las etiquetas