Estoy trabajando en un proyecto que requiere tener una funcionalidad de registro / inicio de sesión expuesta a los socios que administran su propio sitio web. Para algunos de estos sitios web, reutilizan nuestro propio backend, y solo cambian el estilo css, pero otros son completamente independientes: por esta razón, se ha pensado para preparar un formulario de inicio de sesión estático que se entregaría a los socios, lo que provocaría un POST solicitud a nuestros propios servidores.
(dependiendo de los argumentos en el formulario, haríamos un seguimiento de qué socio nos trajo qué usuarios, que aparentemente cubre una necesidad comercial de análisis)
Actualmente, estamos perdiendo la protección CSRF en algunos puntos finales, como el inicio de sesión. Cuando se me pidió que lo investigara, me di cuenta de que, con un formulario estático, no podríamos agregar tokens CSRF.
Parece ser un problema menor, pero sería bueno proteger a nuestros usuarios del inicio de sesión CSRF. Por esta razón pensé en 2 alternativas:
- agregue un paso de confirmación antes de iniciar sesión en el usuario cuando se encuentre un conflicto en la cookie de sesión (descartado debido a que los cambios en el flujo lógico para la administración de la sesión son demasiado invasivos)
- en lugar de un formulario estático, permita que nuestros socios utilicen un iframe que contendrá nuestro propio formulario de inicio de sesión, con protección CSRF y todo. Esto requeriría relajar el
X-FRAME-OPTIONSespecíficamente para la página que mostrará este formulario de inicio de sesión
¿Hay una mejor solución? No creo que el clickjacking en nuestro formulario de inicio de sesión deba ser realmente una preocupación (y el clickjacking se usa normalmente para hacer lo que de otra manera podría obtenerse de manera trivial con un CSRF, creo que ... corregir este último parece tener una prioridad más alta)