Siempre me ha gustado leer. YouTube tiene contenido buenísimo pero con un libro me concentro más; puedo parar, preguntarme y comprobar si lo entiendo. Todo eso lo puedo hacer con YouTube, simplemente me cuesta más, ya tengo demasiado asociada la plataforma a ver un vídeo y pasar al siguiente.

Del libro Python Crash Course (2.ª ed.) nació este blog. Quería mejorar mi Python y me interesa el hacking web, así que pensé: montar mi propia web desde cero me ayudaría a entender sus fundamentos y vulnerabilidades, ¿no? Como los últimos tres capítulos tratan sobre desplegar una web con Django, lo utilicé como guía.

En otro post contaré los pasos concretos y los problemas que encontré al desplegarla en una VPS de Hostinger; quizás sean útiles a otros. Aquí quiero centrarme en una lección de seguridad que surgió casi por accidente: el comportamiento del logout en Django y por qué dejarlo como un simple enlace puede ser peligroso.

El tema con los libros de tecnología es que se quedan desactualizados. Lo cual no tiene por qué ser un problema si te lo tomas como pequeños ejercicios.

El caso es que al implementar el botón de “Log out” en mi plantilla, recibí un error Method Not Allowed. Investigando, descubrí que versiones recientes de Django exigen que el logout se haga por POST (no por GET como decía el libro).

¿Por qué ese cambio? Porque permitir logout por GET puede facilitar ataques de CSRF (Cross-Site Request Forgery), tal como se discute en este ticket oficial de Django:

→ https://code.djangoproject.com/ticket/15619

Eso me lleva a la siguiente pregunta…

¿Qué es un CSRF?

De forma simple: es cuando un atacante provoca que el navegador de una víctima haga una acción en un sitio donde esa víctima ya está autenticada, sin que la víctima se dé cuenta.

Como cuando eras pequeño, tu amigo el tímido te hace llamar para pedir las pizzas y acabas dando tu nombre y teléfono. Pero esta vez un atacante consigue que tu navegador “pregunte” por ti a un servicio y ejecute una acción que no quieres (p. ej. cerrar sesión o, en casos más graves, cambiar configuraciones o incluso transferencias de dinero).

La clave está en que el navegador incluye automáticamente las cookies de sesión al hacer peticiones al dominio correspondiente. Es información que mandamos constantemente.

El ataque clásico necesita dos cosas:

1. La víctima está logeada en la web o sistema.
2. La víctima accede a la web o URL del atacante (puede ser mediante ingeniería social o phishing).

Bueno, vale, eso suena mal… ¿pero el logout? ¿Qué peligro conlleva? Parece inofensivo

Eso pensó también el usuario Russell en el ticket:

“As for CSRF; I fail to see why this is relevant. Given that there is no incoming data, and no data processing, I cannot see an CSRF weakness, even in-principle.”

A lo que le contestaron:

“The issue is that this presents a really tempting avenue for DoS type attacks.”

Por ejemplo, si dentro de una imagen ofensiva hay una URL que te fuerce a deslogearte:

<img src="https://tupagina.com/accounts/logout/" alt="gato gracioso">

Esto puede ser bastante molesto para los usuarios de esa web. Que es uno de los propósitos de los ataques DoS (Denial of Service), aunque el principal sería inhabilitar completamente tu web.

Respuesta corta: si puedes hacerlo más seguro sin un gran coste de usabilidad, hazlo. Nunca sabes de qué formas pueden utilizar esas vulnerabilidades.

¿Y por qué el POST ayuda?

Con el método POST, aparte de la interacción explícita del usuario, podemos pedir un token CSRF que la página genuina genera y que el servidor verifica. Viene a ser un identificador único que, asociado a la session-id de la cookie, no es público.

Un atacante que hostee una página maliciosa puede provocar un GET, pero no puede conocer ni reproducir el token CSRF legítimo que tu aplicación exige en un formulario POST.

Además, mecanismos como la política SameSite en cookies reducen la posibilidad de que las cookies se envíen en peticiones cross-site.

¿Significa esto que el POST es infalible? No. Como explican en OWASP:

→ https://owasp.org/www-community/attacks/csrf

Un POST sin verificación de token sigue siendo vulnerable, e incluso puede ejecutarse automáticamente.

En foros y discusiones históricas sobre Django se planteó esta misma cuestión desde hace años: el primer comentario del ticket es de 2011; la segunda edición del libro es de 2019; el cambio no ocurrió hasta 2022. Me sorprende el tiempo que llevó cambiarlo —sé que implica trabajo y alinear compatibilidad—, pero es un ejemplo de la poca importancia que a veces se presta a la seguridad.

Y CSRF sigue apareciendo en la práctica. Ejemplo reciente (octubre 2025):

→ ChatGPT Atlas Client-Side Attack (CSRF) – Chema Alonso
→ Informe original de LayerX: https://layerxsecurity.com/blog/layerx-identifies-vulnerability-in-new-chatgpt-atlas-browser/

Aquí el esquema es el mismo, pero en vez de forzar una acción del usuario, se inyectan instrucciones malignas en la “memoria a largo plazo” del agente GPT.

En mi caso particular, arreglar el logout para que use un formulario POST con el token fue suficiente.

Siguiendo mi curiosidad, aprendí sobre políticas web (CORS, SameSite), ataques CSRF y cómo pensar en las peticiones que un navegador hace por nosotros. Lo mejor es que cada camino lleva a más preguntas para profundizar en el tema. En el futuro quiero estudiar:

El ataque login CSRF que analizan en este paper: --> https://seclab.stanford.edu/websec/csrf/csrf.pdf Cómo proteger nuestro anonimato en la red, porque cuanta más información tengan sobre nosotros (búsquedas, páginas visitadas, etc.), más fácil será que caigamos en algún ataque.