Todas las soluciones (uso de tokens, por ejemplo) he visto hasta el momento detalles sobre cómo prevenir un CSRF desde un sitio web externo, es decir, prevenir un CSRF de evil.com a victim.com. Sin embargo, ¿cómo protegería uno de un CSRF desde el mismo sitio, es decir, alguien publica un enlace en victim.com que obliga a cualquiera que haga clic en él a eliminar su cuenta de victim.com?
Bueno, el CS en CSRF significa sitio cruzado.
Pero en general, el escenario de ataque que describe no debería ser posible por dos razones:
Si utiliza un enfoque basado en referencia para la protección CSRF (o si agrega automáticamente un token a todos los enlaces o formularios), y si las solicitudes GET cambian el estado del servidor (o si las solicitudes POST se pueden convertir en solicitudes GET, o Si permite que el usuario publique etiquetas de formulario, debe:
form que se necesitan para POST CSRF no deben permitirse, ya que permiten una serie de otros ataques (robo de información secreta, phishing, etc.). Los tokens de protección CSRF deben ser específicos del usuario . Puedo crear una solicitud que elimine mi cuenta (o lo que sea) incluyendo el token my , pero no tengo el token para nadie más , por lo que mi solicitud falsificada, si se envía con la cookie de ID de sesión de otra persona, fallaría (quedaría bloqueada por la protección CSRF).
Parece que te perdiste al menos un elemento crítico de la protección CSRF. O malinterpretaste que los tokens anti-CSRF deben ser únicos por usuario, o estás tratando de usar algún tipo de filtro de solicitud-origen (como los encabezados Referer o Origin) para detectar CSRF, y esa es la forma incorrecta de hacerlo. it.
Realmente no hace una diferencia si un enlace o formulario malicioso está en una página en el mismo dominio o en un dominio diferente.
Cuando requieres que la solicitud contenga un token de seguridad que solo sea válido para una situación muy específica, un atacante no podrá adivinar ese token incluso al contrabandear un enlace al contenido en el mismo dominio.
Además, no se debe permitir que ninguna actividad que modifique datos sea activada por una solicitud GET. Siempre requiere POST, además requiere un token de seguridad que esté conectado al usuario que está conectado actualmente y no se puede reutilizar en diferentes situaciones.