Esenciales de Seguridad Web: SSRF, CSRF y CORS Explicados

En el panorama web moderno, la seguridad no es solo una característica, es una base. A medida que las aplicaciones se vuelven más interconectadas, comprender los matices de cómo se manejan las solicitudes en diferentes orígenes y servidores es crucial para cualquier desarrollador.

Hoy, profundizamos en tres conceptos críticos que todo desarrollador web debe dominar: SSRF, CSRF y CORS. Aunque puedan sonar a sopa de letras, representan las primeras líneas de la seguridad de las aplicaciones web.

1. SSRF (Falsificación de Solicitud del Lado del Servidor)

El SSRF es una vulnerabilidad en la que un atacante puede obligar a una aplicación del lado del servidor a realizar solicitudes HTTP a un dominio arbitrario elegido por el atacante.

Cómo Funciona

Imagina una aplicación web que toma una URL como entrada (por ejemplo, para obtener una foto de perfil o previsualizar un enlace) y luego realiza una solicitud a esa URL desde el servidor. Si la aplicación no valida correctamente esta URL, un atacante podría proporcionar una dirección IP interna o una dirección de bucle invertido (127.0.0.1).

El servidor, actuando como un proxy, podría entonces obtener datos sensibles de servicios internos que no están expuestos a la internet pública, tales como:

• Metadatos de la Nube: Acceder a 169.254.169.254 en AWS/GCP para recuperar credenciales de IAM.
• Paneles de Administración Internos: Acceder a herramientas internas como Jenkins o paneles de control de Kubernetes.
• Escaneo de Puertos: Descubrir otros servicios que se ejecutan en la red interna.

Prevención

• Listas de Permitidos (Allowlisting): Solo permite solicitudes a una lista predefinida de dominios de confianza.
• Validación de Entradas: Asegúrate de que la URL utilice protocolos permitidos (por ejemplo, solo https://) y no apunte a rangos de IP internos.
• Segregación de Red: Asegúrate de que el servidor web tenga acceso restringido a los recursos internos.

2. CSRF (Falsificación de Solicitud en Sitios Cruzados)

El CSRF es un ataque que engaña al navegador de una víctima para que realice una acción no deseada en otro sitio web donde la víctima está autenticada actualmente.

Cómo Funciona

Este ataque explota el hecho de que los navegadores incluyen automáticamente credenciales ambientales, como cookies de sesión, con cada solicitud a un dominio.

1. Un usuario inicia sesión en bank.com.
2. El usuario visita un sitio malicioso evil.com en otra pestaña.
3. evil.com contiene un formulario oculto que envía una solicitud POST a bank.com/transfer?amount=1000&to=attacker.
4. El navegador envía la solicitud junto con la cookie de sesión del usuario para bank.com.
5. bank.com ve una sesión válida y procesa la transferencia.

Prevención

• Tokens Anti-CSRF: Incluye un token único, secreto e impredecible en cada solicitud que cambie el estado. El servidor verifica este token antes de procesar.
• Cookies SameSite: Establece el atributo SameSite en las cookies como Strict o Lax para evitar que se envíen en solicitudes entre sitios.
• Encabezados Personalizados: Para solicitudes AJAX, requiere un encabezado personalizado (por ejemplo, X-Requested-With) que no pueda ser establecido por un formulario HTML estándar.

3. CORS (Intercambio de Recursos de Origen Cruzado)

A diferencia de SSRF y CSRF, el CORS no es una vulnerabilidad en sí misma, sino un mecanismo de seguridad. Es una forma de que los servidores le digan al navegador: “Está bien que este origen externo específico acceda a mis recursos”.

Por Qué Existe

Por defecto, los navegadores aplican la Política de Mismo Origen (SOP), que impide que un script en un sitio lea datos de otro sitio. Esto evita que evil.com lea tus correos electrónicos en gmail.com.

El CORS permite a los servidores relajar esta política de forma segura. Cuando una aplicación web realiza una solicitud de origen cruzado, el navegador envía un encabezado Origin. El servidor responde con Access-Control-Allow-Origin.

Configuraciones Erróneas Comunes

• Origen Comodín (*): Permitir todos los orígenes. Aunque está bien para las API públicas, es peligroso si se combina con Access-Control-Allow-Credentials: true.
• Reflejar el Origen: Establecer dinámicamente el origen permitido basándose en el encabezado Origin sin validación. Esto efectivamente elude la SOP por completo.

Mejores Prácticas

• Sé Específico: Solo permite los dominios específicos que necesitan acceso.
• Evita las Credenciales si es posible: Si tu API no necesita cookies o encabezados de autorización, no los permitas.
• Usa un Middleware de Seguridad: Utiliza bibliotecas bien probadas para manejar la configuración de CORS en lugar de administrar los encabezados manualmente.

Resumen Comparativo

Comprender estos tres pilares de la seguridad web es esencial para construir aplicaciones modernas y robustas. Al implementar estrategias de defensa en profundidad, puedes proteger tanto la infraestructura interna de tu servidor como los datos privados de tus usuarios.

¡Mantente seguro y feliz programación!