¿Cómo debo asegurar un formulario de contacto que aparece en cada página de un sitio web?

Este es un buen artículo de resumen sobre CATPCHA:

enlace

Creo que tienes razón en no usar CAPTCHA. La investigación ha demostrado que CAPTCHA puede reducir sus tasas de conversión en un 3% y potencialmente hasta un 30% . Incluso contratar a alguien para filtrar manualmente o usar turco mecánico , yourmaninindia.com etc. tal vez sea más barato y mejor para su experiencia como cliente

Buenas medidas pasivas:

• La secuencia de comandos de Roboo . Realice una demostración en Blackhat este año y también le brinda cierta protección de DOS.

• Agregar un campo oculto de honeypot que nunca se debe completar. Puede usar Javascript para completar esto automáticamente en las presentaciones de formularios legítimos y validar el lado del servidor.

• Las medidas de velocidad, como la rapidez con la que se envía el formulario.

Todos estos no son perfectos, pueden causar problemas a las personas con discapacidad y pueden dar falsos positivos. Si aún recibe una cantidad inaceptable de spam o uso de robots, use la opción más popular y gratuita Re-Captcha. Lo ideal es combinar esto con los pasos pasivos anteriores para presentar solo el CAPTCHA si sospecha que se ha enviado un bot (es decir, un enfoque adaptable que no se presenta cada vez a los usuarios). Sí, Re-Captcha se ha roto en los laboratorios de investigación con tanto éxito como 25% utilizando técnicas de OCR, pero todavía es suficiente para disuadir a Dragnet bots que buscan objetivos desprotegidos (corriendo más rápido que el tipo que corre del oso). También estás ayudando a Google a traducir los libros del mundo y hasta que duolingo.com presente su próxima innovación, no es algo malo.

NoBot es una solución GRATUITA interesante de Microsoft

Descripción

NoBot es un control que intenta proporcionar prevención de bot / spam similar a CAPTCHA sin requerir la interacción del usuario. Este enfoque es más fácil de omitir que una implementación que requiera intervención humana real, pero NoBot tiene el beneficio de ser completamente invisible. Es probable que NoBot sea más relevante para los sitios con poco tráfico donde el spam de blog / comentarios es un problema y no se requiere una efectividad del 100%.

NoBot emplea algunas técnicas anti-bot diferentes: Obligando al navegador del cliente a realizar un cálculo configurable de JavaScript y verificando el resultado como parte de la devolución de datos. (Por ejemplo: el cálculo puede ser simple, numérico o también puede implicar al DOM para una mayor seguridad de que está involucrado un navegador) Hacer cumplir un retraso configurable entre el momento en que se solicita un formulario y cuándo se puede volver a enviar. (Por ejemplo: es poco probable que un humano complete un formulario en menos de dos segundos) Hacer cumplir un límite configurable para la cantidad de solicitudes aceptables por dirección IP por unidad de tiempo. (Por ejemplo: es poco probable que un humano envíe la misma forma más de cinco veces en un minuto)

NoBot puede probarse infringiendo cualquiera de las técnicas anteriores: publicar de forma rápida, publicar muchas veces o deshabilitar JavaScript en el navegador.

Creo que OWASP tiene algunos recursos para la anti-automatización.

Para su situación particular, podría recomendar el uso de algún tipo de token en cada enlace HTML (como los criterios de envío del formulario HTML para el formulario de contacto) y escribir código en sus páginas dinámicas para agregar un encabezado de Referencia para que pueda más tarde verifique la existencia de un encabezado de referencia que coincida con el token anterior.

Sin embargo, al hacerlo, podría crear muchos problemas. Por ejemplo, la inyección de encabezado HTTP podría ocurrir. Por supuesto, tiene los problemas que tiene cada página dinámica, como fallas de inyección, secuencias de comandos entre sitios, pérdida de ruta, pero también agrega problemas de concurrencia, problemas de manejo de excepciones, etc.

No te molestes en ir a CAPTCHA, que no tiene ningún valor.
En su lugar, implemente un mecanismo de regulación de velocidad racional, es decir, limite el número de solicitudes de "contacto" que pueden llegar desde una única dirección IP dentro de un período de tiempo determinado, para valores sensibles de "número" y "tiempo". P.ej. no más de 10 solicitudes de contacto por minuto, SI eso tiene sentido, o 5 cada hora, si ESO tiene sentido.

Por supuesto, no puede limitarlo DEMASIADO, dado que las direcciones IP no necesariamente se asignan uno a uno a los usuarios (DHCP, IP dinámica, por ejemplo, mediante acceso telefónico, proxy corporativo, etc.), por lo que necesita dejar un margen de maniobra allí, pero por otro lado, 2000 peticiones por minuto es demasiado.
No se puede implementar el acelerador por sesión, ya que es fácil de restablecer.

Considere también implementar un acelerador global, para cualquier dirección, con una tasa mucho más alta. Esto podría causar algún tipo de DoS, pero de nuevo asumo que la disponibilidad del formulario de contacto no es fundamental ...