¿Puede funcionar la protección CSRF incluso si existe una vulnerabilidad XSS?

No, no lo creo. Podría evitarse creando un iframe con display: none , que contenga la página add-users.php . Luego, todo lo que el atacante debe hacer es completar los campos del formulario y enviar el formulario con JavaScript, y el atacante ha agregado con éxito un usuario sin el consentimiento o conocimiento de la víctima. La comprobación del encabezado referer no lo detendría, ya que tendría el valor correcto.

OWASP dice lo siguiente en el uso de la referencia CSR. :

  

Aunque es trivial falsificar el encabezado del remitente en su propio navegador, es imposible hacerlo en un ataque CSRF. La comprobación del referente es un método comúnmente utilizado para prevenir CSRF en dispositivos de red incorporados porque no requiere un estado por usuario. Esto convierte a un referente en un método útil de prevención de CSRF cuando la memoria es escasa. Este método de mitigación de CSRF también se usa comúnmente con solicitudes no autenticadas, como las solicitudes realizadas antes de establecer un estado de sesión que es necesario para realizar un seguimiento de un token de sincronización.

     

Sin embargo, se considera que la verificación del referer es un elemento más débil de la protección CSRF. Por ejemplo, las vulnerabilidades de redireccionamiento abierto se pueden usar para explotar solicitudes basadas en GET que están protegidas con una verificación de referencia y algunas organizaciones o herramientas de navegador eliminan los encabezados de referencia como una forma de protección de datos. También hay errores comunes de implementación con las verificaciones de los remitentes. Por ejemplo, si el ataque CSRF se origina en un dominio HTTPS, se omitirá el referente. En este caso, la falta de un referente debe considerarse un ataque cuando la solicitud está realizando un cambio de estado. También tenga en cuenta que el atacante tiene una influencia limitada sobre el referente. Por ejemplo, si el dominio de la víctima es "site.com", entonces un atacante tiene el exploit CSRF originado en "site.com.attacker.com", lo que puede engañar a una implementación de verificación de remitente rota. XSS se puede utilizar para omitir una verificación de referencia.

     

En pocas palabras, la verificación de referencias es una forma razonable de detección y prevención de intrusos CSRF, aunque no es una protección completa. La comprobación de los remitentes puede detectar algunos ataques, pero no detener todos los ataques. Por ejemplo, si la referencia HTTP es de un dominio diferente y solo está esperando solicitudes de su dominio, puede bloquear esa solicitud de manera segura.

(En una nota al margen, cuestionaría que resolver este problema "mitigaría en gran medida" los daños de XSS. Un atacante aún podría robar contraseñas, además de las otras cosas que enumera. Eso todavía es bastante malo.)

  

¿No debería ser posible usar las verificaciones de referencia como protección CSRF que funciona incluso si existe una vulnerabilidad XSS?

No. Si recibe una secuencia de comandos inyectada, puede crear un <form> que apunta al mismo origen, incluir un token CSRF robado y enviarlo con el encabezado esperado Referer . (También las verificaciones de referencias son problemáticas en general, por supuesto, y es poco probable que sean de utilidad si se trata de una aplicación que hace algo con XHR).

  

¿Pero no funcionaría si se verifica el script exacto?

No. Una vez dentro de un origen no hay límite interno de seguridad. El script inyectado puede abrir cualquier URL dentro del origen (por ejemplo, en un iframe o emergente) e inyectar un script arbitrario directamente en esa ventana, desde donde devolverá la referencia exacta esperada. (Y en estos días con la API de historial de HTML5, puedes cambiar la URL del documento actual directamente de todos modos).

No hay casi nada que un usuario pueda hacer al interactuar con una página web que no pueda ser reproducida por un script en esa página. Entonces OWASP tiene razón en este caso: XSS en general le ofrece un superconjunto de vulnerabilidades más grave que XSRF. No hay mucho que pueda hacer para mitigarlo una vez que haya sucedido, por lo que el énfasis suele estar en hacer que el texto se maneje o se escape correctamente para evitar que se produzcan inyecciones.