Honeypot para formularios de WordPress: cómo ReportedIP Hive reduce el spam en los comentarios casi a cero
Un campo «Honeypot» por sí solo detiene a los bots que rellenan todos los campos de entrada; sin embargo, no sirve de nada frente a un script programado para saltarse el único campo que debería omitir. ReportedIP Hive 2.1.53 combina su Comment Honeypot ya existente con una prueba de ejecución que detecta también este segundo tipo de bots, y evalúa ambos elementos conjuntamente, de modo que un envío automatizado mediante script casi nunca llega a la bandeja de entrada ni a un hilo de comentarios.
Qué hace realmente un campo «Honeypot» de WordPress
Un campo «Honeypot» es un campo de entrada adicional añadido a un formulario, oculto a los visitantes videntes mediante CSS, oculto a los lectores de pantalla mediante aria-hidden, y al que nunca accede un usuario que no pueda verlo. Un envío automatizado que rellena todos los campos que encuentra también rellena ese campo, y un Honeypot rellenado es prueba de automatización sin excepción legítima alguna. ReportedIP Hive lleva uno en su formulario de comentarios desde la versión 2.1.2: un campo llamado reportedip_hive_hp, situado fuera de la pantalla, excluido del orden de tabulación y del autocompletado.
¿Por qué un Honeypot por sí solo dejó de ser suficiente?
Un «Honeypot» solo detecta scripts que rellenan campos de forma indiscriminada. Un script diseñado para un sitio web concreto, o uno que lea el código de un formulario y omita cualquier elemento con aria-hidden o una clase fuera de pantalla, lo pasa por alto sin más. Esta brecha tampoco pueden subsanarla las heurísticas de contenido, ya que la redacción cambia más rápido de lo que un filtro puede aprenderla, por lo que ReportedIP Hive 2.1.53 añadió una segunda pregunta independiente: ¿cargó este cliente alguna vez la página y ejecutó su JavaScript?
A esa pregunta no le importa lo que diga el comentario. Un usuario que publique directamente en wp-comments-post.php sin haber cargado nunca la página del artículo no puede haber ejecutado un script que se encuentre en esa página, independientemente de lo que afirme el cuerpo del comentario.
Cómo llega la prueba de ejecución a su veredicto
El servidor inserta un campo de anclaje oculto en el formulario. A continuación, un pequeño script añade un segundo campo junto a él, cuyo nombre varía en cada instalación, de modo que una carga maliciosa diseñada específicamente no pueda utilizarse en dos sitios web distintos. Al leer ambos campos al enviar el formulario, cada solicitud se clasifica en una de estas cuatro categorías:
| Veredicto | Contenido de la propuesta | Qué significa |
|---|---|---|
tripped | El campo «Honeypot», rellenado | Comportamiento típico de un bot: ha rellenado un campo que un humano nunca ve |
proved | El «Honeypot» está vacío; hay un campo de prueba | Un navegador ha cargado el formulario y ha ejecutado su script |
failed | El «Honeypot» está vacío, falta el campo de verificación; se sabe que este formulario lo muestra correctamente | Se ha accedido a una página real; el script nunca se ejecutó; no hay indicios evidentes de que haya una persona detrás de ello |
ausente | No se ha rellenado ninguno de los dos campos | Esta solicitud nunca se tramitó a través de nuestro formulario |
La distinción entre failed y absent es importante en un caso límite real: un visitante que haya desactivado JavaScript. Hive registra, como máximo una vez al día, que un formulario de comentarios ha generado realmente el enlace; ese registro determina si la ausencia de un campo de prueba se interpreta como «el script nunca se ejecutó aquí» o «nunca incluimos un campo en este formulario». Un tema con marcado de comentarios escrito a mano, o un sitio web que haya desactivado la capa, recibe una interpretación indulgente absent en lugar de ser tratado como sospechoso por algo que nunca ha tenido.
Qué peso tiene cada señal en la puntuación de spam
Los comentarios se procesan a través de un sistema de puntuación independiente, ReportedIP_Hive_Comment_Spam_Filter que combina el veredicto de la prueba de ejecución con señales de enlaces e identidad. Un comentario necesita una puntuación de 4 o más para ser clasificado como spam:
| Señal | Puntuación | ¿Alcanza el umbral de 4 por sí solo? |
|---|---|---|
Campo «Honeypot» rellenado (tripped) | +6 | Sí, con dos puntos de ventaja |
Se ha generado el formulario, pero el script nunca se ha ejecutado (failed) | +4 | Sí, justo en la línea |
| El nombre del autor es, en sí mismo, una URL | +4 | Sí |
| Un enlace sin mensaje en un comentario breve | +4 | Sí |
| Hay más enlaces que el máximo configurado | +3 | No, hace falta una segunda señal |
La solicitud no contiene ningún campo «Honeypot» (absent, ni historial de renderizado) | +1 | No, hace falta una segunda señal |
Un «Honeypot» lleno por sí solo supera el umbral con holgura. La ausencia de una prueba de ejecución por sí sola lo supera exactamente, lo cual es intencionado: es la única señal que un lector auténtico sin JavaScript puede generar por sí mismo, por lo que el sistema se limita a enviar el comentario para su revisión manual, en lugar de introducir la dirección en la lista de bloqueo de IP.
Lo que ocurra a continuación dependerá del formulario
Las tres superficies que cubre la capa no entrañan el mismo riesgo, por lo que no tienen las mismas consecuencias:
- Los comentarios cuya puntuación supere el umbral se clasifican como spam o se rechazan directamente, según la acción que se haya configurado en el sitio web en «Firewall → Defensa contra el spam». Un visitante sin JavaScript no sufre ninguna consecuencia, salvo un retraso debido a la aprobación manual.
- Los formularios de registro rechazan directamente los envíos fallidos y explican el motivo, ya que crear una nueva cuenta supone un compromiso mayor que dejar un comentario.
- El restablecimiento de la contraseña se rechaza si se detecta un «Honeypot» activo, pero nunca solo por la falta de una prueba: que un administrador se quede sin acceso a su propio sitio web es peor que el spam que esto evita, por lo que un navegador sin JavaScript sigue pudiendo recuperar una cuenta.
Cada rechazo falla de forma abierta. Una cuota de consultas agotada, un tiempo de espera agotado o una red inaccesible se interpretan como «sin resultado» en lugar de como un bloqueo, y al activar el Report-Only Mode se registra cada veredicto sin rechazar ni una sola solicitud, lo cual resulta útil para revisar los registros de toda una semana antes de decidir qué medidas aplicar.
¿Desde cuándo y cómo se desactiva?
El Honeypot de comentarios funciona desde Hive 2.1.2. La prueba de ejecución, el veredicto de cuatro categorías y la puntuación descritos anteriormente se incluyeron juntos en la versión 2.1.53, junto con la ampliación de la comprobación de reputación de la comunidad, que antes solo se aplicaba a la página de Login, a los comentarios, los registros y los restablecimientos de contraseña. Ambas capas se ejecutan de forma gratuita en todos los planes.
Toda la capa a prueba de ejecuciones se encuentra en «Firewall → Defensa contra el spam», con un interruptor para todo el sitio web y otro independiente para los formularios de registro y de restablecimiento de contraseña. Un sitio web cuyo formato de los comentarios sea lo suficientemente inusual como para provocar falsos failed, puede desactivar la capa por completo mediante REPORTEDIP_HIVE_DISABLE_FORM_PROOF en wp-config.php.
Preguntas frecuentes
¿Puede un campo «Honeypot» bloquear a un visitante real?
No por sí solo. El campo «Honeypot» es invisible y no puede ser modificado por nadie que utilice el ratón, el teclado o un lector de pantalla, por lo que ningún usuario lo rellena. El único caso que requiere una regla específica es el de un visitante que tenga desactivado JavaScript; por eso, si falta la prueba de ejecución, el proceso se limita a enviar un comentario para su revisión, en lugar de bloquear la dirección.
¿Influye el campo «Honeypot» en la accesibilidad?
El campo contiene aria-hidden="true", un tabindex de -1 y autocomplete="off", por lo que tanto la tecnología de apoyo como los gestores de contraseñas lo omiten de la misma forma que lo haría un usuario vidente que utiliza el ratón.
¿Es un «Honeypot» de formularios conforme al RGPD?
El campo y el script de comprobación no recopilan ningún dato sobre el visitante más allá de si había dos campos ocultos en el momento del envío; no se realiza ningún tipo de identificación digital ni se envían solicitudes a terceros. Consulta la documentación del plugin de WordPress para ver el resumen completo sobre el tratamiento de datos del plugin.
Lecturas relacionadas
- Prueba de ejecución del formulario y la nueva guía de inicio rápido, en su versión completa
- Un «Honeypot» diferente: bloquear los escáneres en su primer intento de explorar la ruta de un archivo señuelo
La propia referencia del gancho «comment_form» de WordPress indica dónde se muestra el campo «Honeypot». Consulta la documentación del plugin de WordPress para ver la referencia completa de la configuración. Explora ReportedIP Hive →