Manipulación de campos ocultos en formularios en SPA y aplicaciones web antiguas
Que un formulario en un sitio parezca inofensivo no significa que sea seguro. Un ejemplo son los campos ocultos de formularios (hidden form fields), que pueden contener valores importantes: el precio de un producto, el identificador de un usuario, el nivel de acceso. Cuando esos campos no están protegidos, un atacante puede modificarlos fácilmente y enviar al servidor datos ya alterados. Este método se conoce como manipulación de campos ocultos.
Hoy, en el mundo de las SPA (aplicaciones de una sola página) y de las aplicaciones web clásicas, este problema se manifiesta de distintas formas, pero la esencia de la vulnerabilidad no cambia: se confía demasiado en el cliente.
Qué es la manipulación de campos ocultos
En los formularios HTML se puede encontrar el elemento <input type="hidden">. No se muestra en la interfaz, pero se envía al servidor al enviar el formulario. Los desarrolladores lo usan para transmitir datos auxiliares entre páginas sin la intervención del usuario.
Ejemplo de un campo oculto sencillo:
<form method="POST" action="/buy">
<input type="hidden" name="price" value="100">
<input type="submit" value="Comprar">
</form>
El problema es que el usuario puede cambiar fácilmente el valor de este campo mediante las herramientas de desarrollador del navegador. Por ejemplo, en vez de 100 poner 1 y comprar el producto casi gratis.
Por qué la vulnerabilidad sigue siendo relevante
Parece que este truco de la «vieja escuela» del hacking ya no funcionaría, pero la práctica demuestra lo contrario. En pruebas de penetración reales los campos ocultos todavía contienen datos críticos. Hay varias razones:
- Desarrollo rápido y copia de código antiguo sin revisar la seguridad.
- Migración de formularios antiguos a SPA sin revisar la arquitectura.
- Confianza en el cliente por la ilusión de que el código JavaScript está «protegido».
- Falta de validación en el servidor.
Los frameworks para SPA (React, Angular, Vue) tampoco protegen contra esta vulnerabilidad si la lógica de comprobación queda solo en el frontend. Los datos en HTML o en las peticiones de red se pueden interceptar y modificar.
Cómo se atacan los campos ocultos
El escenario de ataque suele ser así:
- Abrir la página con el formulario y localizar los campos ocultos mediante las herramientas de desarrollador.
- Modificar el valor directamente en el DOM o mediante JavaScript en la consola.
- Enviar el formulario con los datos alterados.
- Si el servidor no valida los valores, el ataque tiene éxito.
Además de la modificación manual, un atacante puede automatizar el proceso con Postman, cURL o proxies como Burp Suite.
Ejemplo de ataque en una SPA
En una SPA el campo oculto puede estar en un formulario renderizado dinámicamente. Por ejemplo, el botón «Comprar» provoca una petición POST con datos:
{
"productId": 123,
"price": 100
}
Si el precio se toma de un campo oculto en el frontend, se puede reemplazar y enviar la petición manualmente, evitando la interfaz de usuario.
Riesgos para el negocio
La manipulación de campos ocultos puede ocasionar:
- Pérdidas financieras (modificación de precios, descuentos, impuestos).
- Elusión de restricciones (por ejemplo, cambio del nivel de acceso).
- Sustitución de parámetros en transacciones.
- Divulgación de identificadores internos y de la lógica de negocio.
En algunos casos este ataque se utiliza como parte de una cadena para un compromiso más complejo: desde la falsificación de peticiones hasta la explotación de vulnerabilidades lógicas.
Cómo protegerse
El principio principal: no confíe en los datos del cliente. Todo lo que provenga del usuario (incluidos los campos ocultos) debe considerarse potencialmente manipulado.
Validación en el servidor
- Guarde y verifique en el servidor todos los valores críticos (precios, roles, límites).
- Compare los valores enviados con los datos de la base.
- No confíe en los campos ocultos como «fuente de la verdad».
Firma de datos
Si por arquitectura es necesario transmitir parámetros importantes a través de un formulario, se pueden firmar en el servidor y verificar la firma al recibirlos.
price=100&hash=5d41402abc4b2a76b9719d911017c592
El hash o la firma debe calcularse en base a una clave secreta no disponible para el cliente.
Uso de tokens
Para proteger contra CSRF y la sustitución de parámetros, utilice tokens de un solo uso que solo valgan para una operación concreta.
Evitar campos ocultos críticos
En aplicaciones modernas no es necesario almacenar el precio o el nivel de acceso en campos ocultos. Es mejor solicitar esos datos al servidor al enviar el formulario.
Cómo comprobar si la aplicación es vulnerable
Puede revisar sus formularios manualmente o con herramientas:
- OWASP ZAP
- Burp Suite
- Herramientas de desarrollador integradas en el navegador
Algoritmo de comprobación:
- Localizar todos los formularios con
type="hidden". - Modificar los valores y enviar el formulario.
- Observar la reacción del servidor.
Conclusión
La manipulación de campos ocultos es un ejemplo de cómo una «pequeñez» puede costar mucho dinero. En las SPA la vulnerabilidad a menudo se camufla como una transferencia «segura» de datos a través de una API, y en las aplicaciones antiguas puede arrastrarse durante años. La solución es una: verificar rigurosamente todos los datos entrantes en el servidor y diseñar la lógica para que los valores críticos nunca dependan del cliente.
