TECNOLÓGICO NACIONAL DE MÉXICO.

INSTITUTO TECNOLÓGICO DE AGUASCALIENTES.

Tecnologías de la Información y comunicaciones.
Materia:
Seguridad en Tecnologías de la Información.
Tema 3:
Cybersecurity Management.
Actividad:
T4. Secure coding Practices (Team 3).
Docente:
Ricardo Emmanuel Reyes Acosta.
Alumnos:
Castro Montante Oliver Moisés 21151074.
Gámez Aguilar Juan Iram 21151063.
Rangel García David Antonio 21151069.
Valdez Mora Alondra Rubí 21151091.

Fecha: 02/11/2025.
 Indice

Indice ...................................................................................................................................... 2
Introducción. .......................................................................................................................... 3
Practica Cross Site Request Forgery....................................................................................... 4
Materiales / Herramientas ................................................................................................. 4
Escenario ............................................................................................................................ 4
Vulnerabilidad .................................................................................................................... 6
Prueba de penetración y explotación de la vulnerabilidad ................................................ 9
Implementación de buenas prácticas ............................................................................... 10
Pruebas de penetración y comprobación de la solución .................................................. 16
Conclusiones. ........................................................................................................................ 19
 Introducción.
Cross-Site Request Forgery o CSRF es una vulnerabilidad crítica que explota la confianza
que una aplicación web tiene en el navegador de un usuario autenticada. Al incluir
automáticamente las cookies de sesión del usuario, es procesada por el servidor como una
acción legítima, permitiendo al atacante realizar operaciones sin el consentimiento explícito
de la víctima (como cambiar una contraseña, transferir fondos o realizar una compra). A lo
largo de esta práctica, se simulará un ataque CSRF en un entorno controlado para observar
sus efectos y se analizarán los requisitos clave para su éxito, sentando las bases para
implementar defensas efectivas.
 Practica: Cross Site Request Forgery.

Materiales / Herramientas
• Equipo de cómputo.
• Navegador Web.
• [Link]
• Servidor objetivo (encontrado en el GitHub proporcionado en el Foro).
• Paquete Serve (instalar con npm i -g serve).
• Servidor de ataque (encontrado en el GitHub proporcionado en el Foro).

Escenario
Para montar el escenario, deberemos entrar al GitHub proporcionado en el Foro de la clase,
o en el siguiente enlace: [Link]

Descargamos el repositorio como zip y extraemos su contenido.

Para poner en funcionamiento tanto el servidor objetivo, como el servidor de ataque
realizamos los siguientes pasos:

1. Abrimos una terminal en la carpeta “target-server”.

2. Iniciamos el servidor con el comando “npm run dev”. Con esto, el servidor de objetivo
estará en funcionamiento.

3. Ahora abriremos otra terminal aparte en la carpeta “attack-server”.

 4. Abriremos el servidor con el comando “serve -l 5000”, (si Windows no reconoce el
comando, instalamos la librería serve con el comando “npm i -g serve”, también
mostrado arriba).

Con todo esto, tendremos el escenario listo para la práctica.

Vulnerabilidad

En el escenario establecido anteriormente, se expondrá la vulnerabilidad Cross Site Request

Forgery, en el caso de este escenario de prueba, el servidor cuenta con un login, una página
de inicio que solo se puede acceder cuando se inició sesión, una base de datos simple con un
usuario de prueba y una página para editar las credenciales del usuario. Es esto último, lo
que nos interesa, ya que intentaremos mandar una petición desde el servidor de ataque al
objetivo.

La forma en la que funcionará esta practica es la siguiente: iniciaremos sesión con

normalidad en el servidor, después, entraremos al servidor de ataque (simulando que a
través de phishing, el usuario con su sesión iniciada dio clic en un enlace de un correo que
pretendía pertenecer al servidor objetivo), este servidor de ataque mandará al formulario de
editar credenciales en el servidor objetivo una petición con las credenciales
hacker@[Link] y “hacker” como email y contraseña respectivamente.
Si observamos el código del servidor de ataque, veremos que posee varias partes, primero
un formulario con inputs escondidos y valores predefinidos.

Así como un script que manda el formulario que manda el formulario junto con una
propiedad llamada “credentials”. Esta propiedad lo que hace, es mandar una cookie con un
sessionId, esto se explicará más adelante.

En el lado del servidor, podemos observar dos métodos para la ruta “/edit”, un GET y un
POST. El primero busca el id del usuario autenticado y renderiza el formulario para editar
las credenciales.
El segundo, obtiene los datos insertados en los inputs del formulario, pide el valor del
sessionId, valida si el correo contiene un “@” y si la contraseña contiene al menos 3
caracteres. Posterior a esto, cambia las credenciales a las nuevas ingresadas y lo escribe en
la base de datos, para después redirigirlo a la pagina de inicio.
Por lo que podemos ver, el servidor solo utiliza el sessionId para validar la sesión, cosa que
no es suficiente, ya que, si mantenemos la sesión activa, cualquier otra pagina puede utilizar
la cookie que contiene el sessionId de la página.

Prueba de penetración y explotación de la vulnerabilidad

Para probar la vulnerabilidad, iniciaremos sesión en el servidor objetivo con las credenciales
de la base de datos.

Una vez que entremos, en las herramientas de desarrollador, podremos observar la cookie
de sesión del servidor.
Si vemos el formulario de editar perfil, veremos que podremos cambiarlo y nos redirigirá de
nuevo al inicio y que las credenciales habrán cambiado.
Para iniciar el ataque, iremos al servidor de ataque con la sesión iniciada en el servidor
objetivo, (en este caso, la dirección es localhost:5000) nos redirigirá automáticamente al
inicio.

El servidor no nos avisará que la contraseña ni el correo cambiaron, pero si volvemos a ver
en la base de datos, veremos que cambio. También si intentamos recargar la página, veremos
que nos pide iniciar sesión de nuevo.
 Implementación de buenas prácticas

Hay muchas formas de evitar que ataques como este sucedan, una de estos, es imprimir el
origen de la petición, aunque esto no evitara por completo el ataque.

La forma en la que podemos evitar estos ataques es utilizar tokens de acceso para cada
usuario, donde un solo token tiene un tiempo de vida limitado. Para esto, primero
importaremos uuid, el cual nos permitirá crear los tokens.

Agregaremos también una parte que nos mencione CSRF esta activado en consola.
Despues haremos un mapeo de tokens, donde para cada sessionId, le corresponderá un
mapa de tokens. Este token lo pediremos cada que el usuario quiera hacer un cambio a sus
credenciales.

También podremos agregar una parte que reutilice los tokens si hay alguno.

Se agregará también información en la consola que nos muestre que está pasando.
Agregaremos validaciones de cabecera para ver las peticiones.

Agregaremos una parte que nos verifique si el token es valido para manejar los errores.
Y, por último, una sección donde consuma los tokens.

También deberemos agregar en el método POST del login una parte donde al sessionId se le
asigne su set de tokens.

En el logout, antes de destruir la sesión, también agregaremos código que elimine los tokens.

Para la ruta “/edit” agregaremos código que genere un token para el sessionId antes de
renderizar el formulario en el método GET.
Ahora con las nuevas medidas, probaremos si el mismo ataque funcionará.

Pruebas de penetración y comprobación de la solución

Con las modificaciones ya hechas, iniciaremos el servidor objetivo.

Iniciaremos sesión de nuevo.

Al entrar a la ruta /home, iremos a editar nuestro perfil.

Una vez en editar, cambiaremos únicamente el email para probar que este funciona.

Una vez que probamos que podemos cambiar nuestro email, probaremos hacer un ataque
de CSRF.

Accedemos de nuevo al servidor de ataque.

Como se puede ver en la imagen, el servidor objetivo esta vez responde con un error
mencionando que tiene un token invalido o expirado.

Observando el log del servidor de ataque, podemos ver que esta vez nos da un código 304,
en lugar del 200.

También se puede observar que nuestra sesión sigue activa, aunque se haya intentado el
ataque de CSRF.
Por último, en la base de datos podemos observar que las credenciales solo se modificaron
cuando accedimos desde el servidor objetivo.

Conclusiones.

Los hallazgos de esta práctica subrayan la necesidad de no confiar únicamente en los

mecanismos de autenticación basados en cookies de sesión. En definitiva, la prevención de
CSRF es un paso fundamental en el desarrollo de aplicaciones web seguras, ya que un ataque
exitoso puede llevar a un compromiso grave de la cuenta del usuario o, en el caso de un
administrador, de toda la aplicación.