Su formulario de contacto es una puerta de entrada: cómo protegerlo
Los formularios de contacto y de pedido aceptan texto de cualquiera, también de bots. Spam, inyección de código, subida de archivos, captcha y honeypot, y quién puede leer lo que la gente envía.
Un formulario es el único lugar de su web donde cualquiera puede escribir lo que quiera y el sitio tiene que aceptarlo. Normalmente es un cliente que pregunta por un precio o una fecha. A veces es un bot que rellena formularios en un sitio tras otro durante todo el día. Y a veces es una persona que prueba qué se traga el formulario sin protestar.
Por eso los formularios de contacto, de pedido y de reserva de citas están entre lo primero que mira un atacante. A continuación, los riesgos, cómo reconocerlos y qué preguntar a quien se ocupa de su web.
Una avalancha de spam es algo más que una bandeja desordenada
El problema más común es también el menos peligroso, al menos a primera vista. Los bots envían a través de su formulario cientos de mensajes llenos de anuncios y enlaces. La bandeja de entrada se llena y la consulta real de un cliente se pierde en medio.
Es peor cuando el formulario envía una confirmación o una copia del mensaje a la dirección que se haya escrito en él. El bot escribe entonces direcciones de desconocidos, y su servidor les manda correos desde su dominio. Eso daña rápidamente la reputación del dominio: los proveedores de correo empiezan a tratarlo como fuente de spam, y sus correos reales, facturas incluidas, acaban en la carpeta de spam de sus clientes. Su proveedor de alojamiento puede además bloquear el envío desde toda la cuenta.
Si su formulario tiene la opción «enviarme una copia», pregúntese si de verdad la necesita.
Tres ataques en una frase cada uno
Los nombres suenan alarmantes, pero el principio es sencillo. Todos funcionan porque el formulario se fía de lo que alguien escribió.
Inyección en cabeceras de correo: alguien escribe saltos de línea y direcciones adicionales en el campo del correo o del asunto, y un formulario mal hecho envía entonces mensajes desde su servidor a las direcciones que esa persona quiera.
Inyección SQL: alguien escribe en un campo un fragmento de una orden de base de datos, y un formulario que pasa el texto directamente a la base de datos lo ejecuta, lo que puede revelar o modificar los datos guardados en ella.
Cross-site scripting (XSS): alguien escribe un trozo de script en lugar de su nombre, y cuando usted abre ese envío en el panel de administración, el script se ejecuta en su navegador con sus permisos de administrador.
Su desarrollador le protege de los tres: los datos se comprueban y filtran antes de llegar a un correo o a la base de datos, y se muestran en el panel de administración de forma que no puedan ejecutarse. Los plugins populares y actualizados lo hacen por defecto. El riesgo mayor es un formulario programado a mano hace unos años que nadie ha vuelto a mirar. Así que pregunte directamente si su formulario viene de un plugin o se programó desde cero, y en ese caso, quién lo revisó por última vez y cuándo.
Archivos de los clientes
Muchos formularios permiten adjuntar un archivo: un currículum, la foto de un daño, un documento escaneado, un plano para un presupuesto. Es cómodo, y también es la parte más arriesgada de un formulario.
El mayor peligro es un archivo que se hace pasar por imagen pero en realidad es un programa, por ejemplo uno llamado factura.jpg.php. Si el servidor lo acepta y deja que se ejecute, el atacante toma el control del sitio. Por eso, pida a su desarrollador que confirme que:
- el formulario solo acepta tipos de archivo concretos, como PDF, JPG y PNG, y comprueba el contenido del archivo, no solo el final de su nombre,
- hay un límite de tamaño,
- los archivos subidos van a una carpeta donde el servidor no ejecuta nada, idealmente fuera de la parte pública del sitio,
- los archivos guardados reciben nombres nuevos y aleatorios.
Lo que queda de su parte es abrirlos con cuidado. Un documento de Word que nada más abrirlo pide activar las macros es una forma clásica de infectar un ordenador. Recuerde también que los currículums y las fotos enviadas a una clínica son datos personales, a veces sensibles, así que no los guarde más tiempo del necesario.
Captcha, honeypot y limitación de envíos
Hay tres formas de lidiar con los bots, y funcionan mejor juntas.
Un honeypot es un campo adicional del formulario que las personas no ven. Los bots rellenan todos los campos, así que si ese tiene algo escrito, el formulario descarta el mensaje sin avisar. Los clientes no notan nada y los bots más simples desaparecen.
Un captcha distingue a las personas de los bots. Los más recientes, como Google reCAPTCHA v3, Cloudflare Turnstile o hCaptcha, funcionan sobre todo en segundo plano, sin copiar letras ni hacer clic en fotos de semáforos. Tenga en cuenta que transmiten información sobre sus visitantes a otra empresa, por lo que su política de privacidad debe mencionarlos.
La limitación de envíos fija cuántos mensajes pueden enviarse desde una misma dirección en poco tiempo. Es muy poco probable que un cliente real lo note, pero frena las avalanchas de spam y las pruebas automáticas del formulario. Se configura en el servidor o en un servicio de cortafuegos como Cloudflare.
Para empezar, un honeypot más la limitación de envíos suele bastar. Añada un captcha si el spam sigue entrando.
Adónde van los envíos y quién puede leerlos
Un mensaje de su formulario puede acabar en dos sitios: una bandeja de correo y la base de datos de la web. Algunos plugins solo envían un correo. Otros, además, guardan cada envío en el panel de administración, normalmente en un menú llamado algo así como «Entradas» o «Envíos». Entre en el panel y vea cuál es su caso.
Luego responda a unas preguntas:
- ¿Quién tiene acceso a la bandeja que recibe los mensajes? ¿Alguien la reenvió a una cuenta personal de Gmail antes de marcharse?
- ¿Quién tiene una cuenta de administrador en el panel? Cada una de esas personas puede leer todos los envíos guardados.
- ¿Cuánto tiempo se conservan los envíos? Algunos plugins permiten borrar automáticamente las entradas antiguas.
- ¿La página del formulario funciona con HTTPS, con el candado a la vista?
Cada envío con nombre, correo electrónico y teléfono son datos personales de los que usted es responsable. Qué significa eso según el RGPD lo explicamos en el artículo sobre el RGPD y la seguridad de la web.
Un plugin actualizado, y uno en lugar de tres
Los plugins de formularios están entre los más instalados que existen, así que los atacantes les prestan mucha atención. En ellos se descubren y corrigen fallos de seguridad con regularidad, y por eso una actualización de su plugin de formularios no debería esperar semanas en la cola.
Ya puestos, compruebe cuántos plugins de formularios tiene instalados. A veces resultan ser tres: uno de la primera versión del sitio, otro del rediseño y el que de verdad se usa. Borre los que no use, en lugar de solo desactivarlos, porque sus archivos siguen en el servidor.
Y un hábito que no cuesta nada: una vez al mes, envíe un mensaje de prueba a través de su propio formulario. Los formularios pueden dejar de funcionar sin ningún aviso, y entonces el cliente cree que usted le ignora mientras usted ni siquiera sabe que le escribió.