He mitigado los scripts de sitios cruzados en mi código mediante validación de entrada, caracteres de listas blancas (etiquetas HTML también) y uso de encabezados de protección X-XSS. ¿Las soluciones que he implementado para mitigar el ataque CSRF de XSS en mi aplicación?
En un ataque CSRF, el atacante del sitio A puede usar el navegador del usuario U como trampolín para desencadenar una solicitud autenticada contra el sitio B, siempre que el usuario U ya esté autenticado contra el sitio B y B no tenga protección CSRF.
Un ejemplo sería incluir una imagen en el sitio A de esta manera:
<img src=http://site-B/unwanted_action?some_parameters>
Al incluir la imagen, se enviará una solicitud contra el sitio B, que incluye las cookies existentes y la información de autenticación básica que el usuario U tiene dentro del navegador del sitio B. Por lo tanto, la solicitud parece autenticada y el sitio B se ejecutará si no hay protección CSRF. lugar. Por lo tanto, todo lo que se necesita para el ataque es que el usuario U visite el sitio A, ya sea a sabiendas porque el atacante podría incrustar dicho enlace en un sitio del foro público, o sin saberlo porque dicho enlace está incrustado en un anuncio. Y dado que esta es una imagen, el usuario no debe realizar ninguna acción y probablemente ni siquiera se dará cuenta de que algo malo sucedió, como en Cómo se piratearon millones de módems DSL en Brasil, para pagar a las prostitutas de Río .
Dado el ejemplo anterior, debe quedar claro que no se necesita XSS para ejecutar un CSRF y que ni TLS ni la protección de la cookie de sesión contra la manipulación ayudarán a CSRF.
Quería agregar un addendum a la respuesta de @ steffenullrich (totalmente correcta): solo porque su ejemplo usa una solicitud GET para el CSRF (porque eso es lo más fácil de demostrar), simplemente haciendo que todas las solicitudes de cambio de estado solo sean utilizables a través de POST hace NO protege contra CSRF. Un atacante aún puede falsificar una solicitud POST con bastante facilidad. Algunas formas de hacer esto:
<form> de HTML que se envíe al sitio vulnerable cuando se envíe, llénelo con <input> s que haga lo que usted quiere que haga, agregue JavaScript para enviar automáticamente el formulario y coloque el conjunto cosa en un pequeño <iframe> invisible en un sitio que tú (el atacante) controla. La víctima visita su sitio, el iframe se carga, el JS envía el formulario como una solicitud POST al sitio vulnerable, el navegador de la víctima envía las cookies, el encabezado Authorization y / o cualquier otro método automático de autenticación (IPSec, TLS certificado de cliente, verificación simple de la dirección IP, lo que sea), el servidor realiza la acción solicitada y la víctima ni siquiera ve porque nada parece suceder en la página principal. Access-Control-Allow-Origin correspondiente u otras cabeceras de respuesta de CORS, la solicitud todavía será procesada por el servidor (y Fetch permite, opcionalmente, enviar las solicitudes a ciegas sin usar CORS, como si enviado a través de un formulario de presentación). Los verbos HTTP que no sean los comunes (GET, POST y, en menor medida, HEAD y OPTIONS) son más seguros; Los formularios HTML no pueden usar esos métodos, y las solicitudes CORS que los usan deben pasar una verificación de "verificación previa" en la que el cliente consulta el servidor antes de enviar la solicitud real, y no la enviará si el servidor no lo hace. responda apropiadamente. Sin embargo, la mejor protección contra CSRF es tener un valor secreto (adjunto o relacionado con su token de sesión), que se incluye en formularios HTML válidos (y, por lo tanto, en solicitudes no falsificadas de esos formularios) pero es diferente para cada sesión de usuario para que el atacante no pueda predecir cuál sería el token anti-CSRF de la víctima. Si este token falta o no es correcto para la sesión del usuario que lo envía, asuma que es un ataque CSRF e ignore la acción solicitada.