El ataque que nadie ve llega por el formulario de contacto de tu web
El formulario de contacto parece inofensivo. Es la puerta más abierta que tienes, y casi nadie la cierra con llave.
Todo el mundo protege el login. Nadie mira el formulario de contacto. Y sin embargo acepta entrada de cualquiera, sin autenticación, sin fricción, muchas veces sin siquiera un límite de envíos.
Esa es la asimetría que busca el atacante. Una caja de texto que habla con tu servidor de correo, con tu base de datos o con un webhook interno. Tú ves un campo "mensaje". Él ve una línea de comandos.
Por qué este objetivo resulta tan apetecible
Un formulario de contacto reúne tres propiedades raras en un mismo sitio. Acepta entrada no confiable. Ejecuta lógica en el servidor. Y casi nunca se audita. El programador comprobó que el mensaje llega al correo. Ahí se detuvo.
El problema es que "el mensaje llega al correo" esconde un camino entero. El texto del usuario se monta dentro de una cabecera SMTP, se concatena en una consulta o se envía a un servicio de terceros. Cada una de esas fronteras es una oportunidad de inyección.
Inyección de cabeceras de correo
El caso clásico se llama email header injection. Si tomas el campo "asunto" o "remitente" y lo pegas directamente en la cabecera del mensaje, un atacante escribe un salto de línea y añade sus propias cabeceras. Un Bcc a mil direcciones, por ejemplo.
De repente tu servidor está enviando spam. No en tu nombre por casualidad, sino literalmente desde tu infraestructura, con tu IP y tu dominio. El resultado es previsible: los grandes proveedores marcan tu dominio como fuente de spam y tu correo de negocio deja de llegar a ninguna parte.
El texto que se convierte en código
Después vienen los escenarios peores. Si guardas el mensaje en una base de datos sin parametrizar la consulta, abres la puerta a SQL injection. Si muestras el mensaje en un panel de administración sin escapar el HTML, el atacante planta un script que se ejecuta en el navegador de tu equipo cuando abre el lead. Esto es XSS almacenado, y es de los vectores más subestimados que existen.
Fíjate en el patrón. En ninguno de estos casos el atacante "invadió" nada. Usó el formulario exactamente como está diseñado para usarse. La vulnerabilidad no es un fallo exótico. Es la ausencia de una regla simple: nunca confíes en lo que entra.
Qué hacer, por orden de prioridad
No necesitas un WAF ni un consultor de seguridad para cerrar el 90% de esto. Necesitas disciplina en cuatro puntos.
- Valida en el servidor, nunca solo en el navegador. La validación de front-end es comodidad para el usuario, no es seguridad. El atacante no usa tu formulario, hace POST directo al endpoint.
- Escapa en la salida, siempre. Al grabar en base de datos usa consultas parametrizadas. Al mostrar en un panel escapa el HTML. Trata cada mensaje como hostil hasta que se demuestre lo contrario.
- Rechaza los saltos de línea en los campos de cabecera. El asunto, el nombre y el correo no tienen razón para contener \r o \n. Fíltralos antes de tocar el SMTP.
- Limita la tasa de envíos y añade un desafío invisible. Rate limiting por IP y un honeypot o hCaptcha frenan bots automáticos sin estropear la experiencia de quien es humano.
Y el lado que casi todo el mundo olvida
Un formulario de contacto recoge datos personales. Nombre, correo, muchas veces teléfono y el contenido del mensaje. Eso te coloca dentro del RGPD, te guste o no. Necesitas una base legal para tratar esos datos, y el consentimiento tiene que ser informado.
En la práctica significa tres cosas concretas. Un aviso claro de privacidad enlazado al formulario. Una base legal definida, normalmente el interés legítimo del artículo 6 o el consentimiento explícito. Y una política de retención, porque guardar leads para siempre no es una estrategia, es una responsabilidad acumulada. Si te roban la base de datos de leads, el problema deja de ser técnico y pasa a ser regulatorio.
Seguridad de formulario no es un firewall caro. Es negarte a confiar en el texto que un extraño escribió.— Krivar Diário
La moraleja es aburrida y por eso funciona. El ataque que nadie ve llega por la puerta que nadie mira. Trata tu formulario de contacto con el mismo respeto que le das al login y la mayoría de estos problemas nunca llegan a ocurrir.