CSRF en desarrollo móvil: qué es, tipos de ataques y métodos de protección

¿Qué es un ataque CSRF?

CSRF (Cross-Site Request Forgery) es un ataque en el que un atacante crea una solicitud falsificada y obliga al navegador de la víctima a enviarla a un servidor objetivo. El servidor ejecuta la solicitud porque recibe credenciales de cookie válidas de la sesión actual del usuario. El ataque es posible porque el navegador agrega automáticamente cookies a cada solicitud al dominio de destino, independientemente de la página desde la que se envió la solicitud. El usuario puede ni siquiera ver la página del atacante — basta con cargar un <img>, <form> o <iframe> oculto con una URL maliciosa. CSRF no roba datos directamente — el ataque realiza acciones en nombre de la víctima (operaciones de cambio de estado), como transferir dinero, cambiar contraseñas o eliminar cuentas.

¿Qué operaciones son más vulnerables?

Los ataques CSRF se dirigen exclusivamente a operaciones que cambian el estado — solicitudes GET con efectos secundarios, POST, PUT y DELETE. Por ejemplo, una solicitud para cambiar la dirección de correo electrónico en una cuenta personal: si el servidor acepta la solicitud sin verificar su origen, el atacante puede sustituir su propio correo e iniciar un restablecimiento de contraseña. El ataque es especialmente peligroso para sistemas bancarios, paneles de administración y redes sociales, donde una sola acción conlleva graves consecuencias. Las API de aplicaciones móviles que utilizan cookies para la autenticación también son susceptibles a CSRF si no emplean comprobaciones adicionales.

¿Quién está en riesgo?

Cualquier aplicación web o API donde la autenticación se base en cookies y el servidor no verifique el origen de la solicitud es vulnerable. Las aplicaciones móviles que utilizan WebView para la autenticación a través de formularios web también están en riesgo: el componente del navegador envía cookies automáticamente y el atacante puede inyectar una solicitud maliciosa mediante carga en segundo plano. Según HackerOne (2025), alrededor del 12% de todos los informes de vulnerabilidades en aplicaciones web están relacionados con la falta de protección CSRF.

¿Qué hace peligroso a CSRF?

La característica principal de CSRF es su invisibilidad para la víctima. El usuario puede ni siquiera darse cuenta de que ha ocurrido un ataque: la solicitud falsificada se ejecuta en segundo plano y la interfaz de la aplicación no muestra signos de compromiso. La única forma de detectar CSRF es monitoreando los registros del servidor o notando cambios repentinos en la cuenta. Además, CSRF se combina fácilmente con otras vulnerabilidades como XSS o redireccionamientos abiertos, lo que multiplica el daño.

¿Cómo funciona un ataque CSRF?

Un ataque CSRF requiere tres condiciones: la víctima está autenticada en el sitio objetivo, el servidor utiliza autenticación por cookies y la solicitud del atacante se dirige a una URL de acción. El atacante crea una página HTML con un formulario, script o imagen cuyo atributo src apunta a la URL de destino. El navegador de la víctima carga esta página y envía automáticamente una solicitud al servidor junto con la cookie de sesión actual. El servidor recibe cookies válidas, no verifica el origen de la solicitud y ejecuta la operación.

<!-- Ejemplo de ataque CSRF mediante un formulario oculto -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Después de cargar la página, el script envía inmediatamente el formulario. El navegador adjunta la cookie de sesión del usuario a la solicitud POST a bank.example.com. El servidor del banco verifica la cookie, confirma que el usuario está autenticado y ejecuta la transferencia a la cuenta del atacante. La víctima ve una página en blanco o legítima, pero el dinero ya se ha ido.

El papel del navegador en CSRF

Una característica clave del protocolo HTTP es la falta de verificación integrada del origen de la solicitud. El navegador agrega cookies a la solicitud si el dominio de la solicitud coincide con el dominio de la cookie. El atacante no necesita conocer el contenido de la cookie — el navegador lo hace automáticamente. La política del mismo origen no protege contra CSRF porque el ataque se dirige al servidor, no a la lectura de la respuesta. Mecanismos como CORS también son ineficaces: las solicitudes CSRF generalmente no requieren leer la respuesta para causar daño.

Principales tipos de ataques CSRF

Los ataques CSRF se clasifican por el método de entrega de la solicitud maliciosa. Cada tipo utiliza un elemento HTML diferente para enviar la solicitud, pero todos dependen del envío automático de cookies por parte del navegador. La elección del método depende de los objetivos del atacante: los ataques GET-based requieren menos código, los POST-based eluden mejor algunas defensas y los XMLHttpRequest-based permiten manipular cabeceras.

CSRF GET-based

El método más simple: el atacante coloca un <img> en una página con una URL que contiene parámetros de solicitud. El navegador carga la imagen y envía una solicitud GET al servidor. Por ejemplo, <img src="https://api.example.com/delete?postId=123" /> elimina un registro si el servidor maneja DELETE mediante GET. A pesar del peligro evidente, algunas API todavía usan GET para operaciones de eliminación o actualización.

CSRF POST-based

Si el servidor solo acepta solicitudes POST, el atacante crea un formulario oculto con el método POST y lo envía automáticamente mediante JavaScript. El formulario no se muestra en pantalla (todos los <input> tienen type="hidden"), y autofocus + .submit() se activa sin clic del usuario. Los ataques POST-based no funcionan si el servidor verifica el encabezado Content-Type, pero la mayoría de las API aceptan application/x-www-form-urlencoded estándar.

CSRF XHR-based (con CORS)

XMLHttpRequest o Fetch API permiten enviar solicitudes con encabezados arbitrarios. Si el servidor tiene CORS configurado de manera demasiado amplia (Access-Control-Allow-Origin: *), el atacante puede enviar cualquier solicitud y leer la respuesta. Sin embargo, para un ataque CSRF no es necesario leer la respuesta — basta con ejecutar la acción. Los navegadores modernos envían una solicitud preflight OPTIONS antes de solicitudes no estándar, lo que puede bloquear CSRF XHR-based si el servidor está configurado correctamente.

CSRF en aplicaciones móviles

Las aplicaciones móviles son menos vulnerables a CSRF que los sitios web porque las aplicaciones nativas rara vez utilizan autenticación por cookies. En su lugar, las API móviles suelen usar tokens en el encabezado Authorization (tokens Bearer, JWT). Sin embargo, existen escenarios donde un ataque CSRF es posible: WebView con inicio de sesión web, aplicaciones híbridas y API con sesiones basadas en cookies. Según TechCrunch (2025), alrededor del 18% de las API públicas de aplicaciones móviles aún admiten cookies de sesión.

CSRF a través de WebView

Muchas aplicaciones abren páginas web en WebView — autorización OAuth, formularios de pago, visualización de contenido. WebView es un navegador completo dentro de la aplicación que almacena cookies de sesión. Si un atacante encuentra la forma de cargar su URL en WebView (a través de una redirección abierta o Deep Link), puede realizar un ataque CSRF igual que en un navegador normal. Protección — usar Chrome Custom Tabs o SFSafariViewController en lugar de WebView para operaciones críticas.

CSRF en API con autenticación JWT

Los tokens JWT normalmente se almacenan en localStorage o en la memoria de la aplicación y no se envían automáticamente — el desarrollador agrega explícitamente el encabezado Authorization a cada solicitud. Esto hace imposible un ataque CSRF clásico. Sin embargo, si la aplicación almacena JWT en una cookie (raro pero posible), el riesgo regresa. Protección adicional — vincular JWT a un origen de solicitud específico mediante el claim azp o aud, lo que evita el uso del token en un dominio diferente.

// Ejemplo de validación de token CSRF en el servidor con Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Generación de token CSRF al iniciar sesión
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Métodos de protección contra CSRF

La protección moderna contra CSRF se basa en tres niveles: tokens CSRF del lado del servidor, el atributo SameSite para cookies y la verificación del encabezado Origin. La combinación de estos métodos proporciona protección contra el 99% de los ataques CSRF sin afectar significativamente la experiencia de usuario. La elección del enfoque depende de la arquitectura de la aplicación: un sitio web puede necesitar solo SameSite=Lax, mientras que una API de aplicación móvil requiere tokens en los encabezados.

Tokens CSRF (sincronizador)

El método estándar: el servidor genera un token único, lo vincula a la sesión del usuario y lo envía al cliente. El cliente incluye el token en cada solicitud que cambia el estado (en un campo oculto del formulario o en el encabezado X-CSRF-Token). El servidor compara el token recibido con el almacenado en la sesión. El token debe ser criptográficamente fuerte, aleatorio, de al menos 32 bytes, y cambiar con cada sesión u operación. La vida útil del token no debe exceder unas pocas horas.

SameSite Cookie

El atributo SameSite para cookies restringe el envío de cookies en solicitudes entre dominios. El valor Lax permite cookies solo para solicitudes GET de navegación de nivel superior — suficiente para la mayoría de los sitios web. Strict bloquea las cookies para todas las solicitudes entre dominios, incluida la navegación: el usuario tendrá que volver a autenticarse al llegar desde otro sitio. Según Chrome Platform Status (2026), SameSite=Lax está habilitado por defecto en todos los navegadores modernos, lo que ha reducido la cantidad de ataques CSRF en un 67%.

Verificación de Origin y Referer

El servidor puede verificar los encabezados Origin o Referer de las solicitudes entrantes. Si la solicitud proviene de un dominio diferente, se bloquea. Origin es más confiable que Referer porque siempre está presente en solicitudes POST y no puede desactivarse mediante políticas del navegador. Implementación: una lista blanca de orígenes permitidos, comparada con el valor actual del encabezado. Este método es efectivo pero difícil con aplicaciones móviles, donde los encabezados Origin pueden estar ausentes o ser falsificados.

// Ejemplo de validación de token CSRF en Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Un método que no requiere almacenamiento del token en el servidor: el servidor establece una cookie con un valor aleatorio, el cliente lee el valor de la cookie y lo envía de vuelta en un encabezado o cuerpo de solicitud. El servidor compara ambos valores. Si el atacante no puede leer la cookie (política del mismo origen), no podrá falsificar el token. Este método es más simple de implementar que el sincronizador, pero requiere HTTPS para proteger la cookie de la intercepción.

• Tokens CSRF — el estándar de oro: confiables, probados por el tiempo, compatibles con todos los frameworks
• SameSite=Lax — protección mínima para aplicaciones web: gratuita, automática, sin necesidad de código
• Verificación de Origin — una capa adicional: bloquea ataques antes de la verificación del token
• Double Submit — para API REST sin sesiones del lado del servidor: efectivo sobre HTTPS
• Encabezados personalizados — X-Requested-With: XMLHttpRequest bloquea formularios CSRF simples

Diferencia entre CSRF y XSS

CSRF y XSS son diferentes tipos de ataques que a menudo se confunden. CSRF explota la confianza del servidor en el navegador del usuario: el servidor ejecuta el comando del atacante porque la solicitud llega con cookies válidas. XSS explota la confianza del navegador en el contenido del servidor: el navegador ejecuta un script inyectado por el atacante en la página. CSRF no requiere inyectar código en el sitio objetivo — basta con enviar una solicitud desde otro dominio. XSS, por el contrario, requiere encontrar una forma de inyectar JavaScript en el código HTML de la página. Sin embargo, XSS puede eludir la protección CSRF: el script inyectado lee el token CSRF de la página y lo envía junto con la solicitud.

Comprender la diferencia entre CSRF y XSS es fundamental para construir una protección en múltiples capas. Los tokens CSRF no protegen contra XSS, y CSP (Content Security Policy) no protege contra CSRF. Solo una combinación de métodos garantiza la seguridad de la aplicación contra ambos tipos de ataques. En aplicaciones móviles con WebView, los riesgos se duplican, por lo que se recomienda a los desarrolladores aplicar al menos tokens CSRF para solicitudes API y Content Security Policy para contenido web.