¿La configuración de la ruta de las cookies me protege de XSS de otro contexto?

Una vulnerabilidad XSS en www.example.com significa que se pueden leer todas las cookies relacionadas con ese dominio, independientemente de la ruta. (Si app1 fuera http y app2 fuese https, sería un poco diferente, pero me imagino que no lo son y rara vez sería el caso).

Los subdominios funcionarían, por ejemplo. app1.example.com tiene diferentes cookies para app2.example.com, suponiendo que se hayan establecido en el subdominio correcto (en lugar de solo en example.com).

No. La Política del mismo origen de JavaScript le permite ejecutar código en cualquier documento en un nombre de host dado desde cualquier otro documento en el mismo nombre de host (+ esquema + puerto).

El código comprometido en www.example.com/app1 puede interactuar con www.example.com/app2 a través de, por ejemplo, formularios, iframes y AJAX, lo que le da una capacidad casi completa para hacerse pasar por un usuario genuino, que es más que un problema de filtración de cookies. La protección CSRF no le ayuda, ya que el código del script puede leer el token CSRF.

La función path= de las cookies solo sirve para prevenir choques accidentales; No tiene valor de seguridad. Solo debe revertir las dos aplicaciones proxy en el mismo nombre de host si confían totalmente entre sí.

De lo contrario, mire los subdominios o dominios completamente separados. (Los subdominios evitan que las aplicaciones lean las cookies de otros, pero no evitan que se use domain= para hacer que una cookie esté disponible en el otro sitio. Esto no suele ser un problema de seguridad como tal, pero puede ser una molestia cuando se enmascara una cookie real e impide que la aplicación funcione.

Existe la posibilidad de que una cookie de app1 y app2 pueda ser robada debido a una vulnerabilidad de XSS. Como mencionó específicamente XSS, un XSS basado en DOM que ejecuta un javascript en el navegador de los clientes en la primera aplicación puede leer la cookie en la segunda aplicación ya que el nombre de dominio es el mismo www.example.com .

Por ejemplo, si app1 es vulnerable a XSS, http://www.example.com/app1/submit.php?subject=<SCRIPT>alert(document.cookie);</SCRIPT> leerá las cookies establecidas para http://www.example.com/app2/ también.

Una vez que se lee la cookie, se puede publicar en otro lugar utilizando un javascript. Esto es irrelevante para la ruta de las cookies y CSRF. Por lo tanto, configurar la cookie path no lo salvará de que XSS robe la cookie de otra aplicación.

También debes tomar en consideración el ataque CSRF .

La adición de la ruta en su cookie solo evita que la cookie se comparta entre las dos aplicaciones, no se aplica a XSS.

Con el ataque CSRF, si alguien está conectado en tus dos aplicaciones, y una de ellas tiene un defecto XSS, puedo crear una publicación de formulario que pondrá contenido en la otra aplicación, como eliminar entradas.

Según enlace :

  

Es importante tener en cuenta que la restricción path no protege   contra la lectura no autorizada de la cookie desde un camino diferente. Eso   se puede omitir fácilmente con DOM simple (por ejemplo, creando un   El elemento oculto iframe con la ruta de acceso de la cookie, luego accede a este   propiedad iframe contentDocument.cookie ). La única forma de proteger   el acceso a las cookies es mediante el uso de un dominio o subdominio diferente, debido a la   misma política de origen.

Por lo tanto, tiene que usar diferentes dominios para diferentes aplicaciones si la seguridad es importante, la configuración de Cookie path por sí sola no lo protegerá contra XSS basado en JavaScript entre las aplicaciones en absoluto.