Me pregunto si alguien sabe si un robot de spam podrá enviar un formulario si no hay un botón de enviar en la página. Solo intento hacer una prevención básica de spam sin usar CAPTCHA. La idea es usar jQuery para presentar el botón de enviar si el usuario interactúa con el formulario de alguna manera. Cualquier pensamiento sería apreciado.¿Un bot de spam podrá enviar un formulario si no hay un botón de enviar en la página?
Un spambot que consiste en un envoltorio de código alrededor de WebKit o algún otro núcleo del navegador puede obligar al DOM "submit()" a ejecutarse, o (incluso más radical) simplemente iniciar una transacción POST propia.
Lo mejor es pensar en un spambot como un robot malvado masivamente poderoso con un navegador que no sigue ninguna regla unida por haces de energía atómica a su cerebro robótico. Pero es un robot que no puede leer muy bien.
Sí, sería posible, un bot no necesita un botón de envío.
Si usted tiene (pseudohtml):
<form action="POST" target="posting.php">
<input name="something"/>
<!-- some logic for the submit button -->
</form>
El robot podría simplemente analizar la etiqueta form y los nombres de los campos del formulario y emitir el POST por su cuenta, sin tener que tocar el botón de envío.
Sí, pueden. El botón no está completamente necesario:
$('#form_id').submit(); /* This is a jQuery trigger */
Pero el robot podría ser desagradable y emitir su propia solicitud de POSTa su servidor, ya que no es tan difícil de hacer.
Pero si creó un <input type="hidden" /> con un valor secreto-ish (conocido por el servidor y recuperado dinámicamente para cada sesión) con jQuery y solo acepta envíos si ese valor estuviera presente, detendría todos los bots no habilitados para JS .
El inconveniente es que evitará que los usuarios habilitados para JS no utilicen su página web. Pero esa es la batalla constante que tiene que luchar para matar a los spammers ...
Creo que podemos decir con seguridad que el caso de palabras reales en el que Javascript está deshabilitado puede ignorarse. ¿Puedes mencionar un caso práctico que no involucre a este tipo: http://dailyyeah.com/wp-content/uploads/2010/05/unix-based-computer-reboot.jpg? – korona
^Eso incluye a todos los usuarios de Mac. (Yo uso Linux, entonces estoy excluido). ¿Has oído hablar del complemento NoScript Firefox? Impide que JS se ejecute hasta que lo permita, y es bastante popular, por lo que aún pensaría en las personas sin JavaScript cuando diseñe. – Blender
Al no haber codificado nunca un robot de spam, solo puedo hacer suposiciones. Pero supongo que la presencia de un botón de enviar no haría mucha diferencia. Lo más probable es que esté mirando la etiqueta <form> y determine en función de eso dónde debería hacer una solicitud POST/GET. Una mejor apuesta (pero de ninguna manera a prueba de tontos) sería no usar un <form>, pero haga un $ .post manualmente (ya que mencionó usar jQuery) cuando se hace clic en un botón o enlace de su elección, recolectando datos POST de elementos sobre la marcha.
Un bot definitivamente va a poder encontrar su botón de publicación, aunque sea con poca frecuencia.
Un método muy popular tipo de como lo que estás intentando es crear un elemento de formulario honeypot. Los campos de honeypot editables en el formulario son invisibles para las personas (puede usar jQuery/CSS para ocultar estos elementos de formulario). Se validan cuando se publican los datos del formulario y si contienen alguna entrada, el remitente debe ser un bot de algún tipo.
El uso de nombres de campo oscurecidos y la validación también pueden detener estos bots. Si el campo de correo electrónico debe tener un signo @, y el bot no puede decir qué campo es el correo electrónico y cuál no, las posibilidades de que se publique correctamente se han reducido considerablemente.
Exactamente sobre lo que había leído en la revista Pragmatic Programmers. – I82Much
+1 Nunca escuché/usé este enfoque, #loveit – xandercoded
Empecé a usarlo hace un tiempo y estoy sorprendido de lo poco que la gente todavía no sabe/usa esto. – ashurexm
Normalmente hacemos un campo oculto con un nombre "jugoso atractivo" como "Nombre".
Luego, en el código subyacente se corre algo como:
if FirstName.text <> "" Then
<insert your "what I want to happen" code. maybe a popup saying "oops an error has been made" or just not submit the form. maybe redirect to a fake error page. like
response.redirect("thisisabot.aspx")
endif
O tal vez ** no hacer nada **. Proporcionar spammers con información de error es una mala idea :) ¡déjelos pensar que todo ha ido bien! ;) –
No hay necesidad de hacer que el botón de enviar tan a menudo los datos se envían desde un servidor remoto en lugar de llenado de la página en sí. CAPTCHA es horrible, a veces es tan claro que no entiendo lo que dice. Utilizo tres métodos a la vez para detener bots.
También registré los intentos con las direcciones IP en una tabla de base de datos. Los intentos fallaron en una, dos o todas las pruebas.
Sin embargo, detener a los spammers de sweatshops es otra historia. Los spammers de la mafia son personas empleadas de forma barata para enviar spam manualmente. Si tiene un sitio más grande, puede valer la pena utilizar un servicio que se ocupe de este tipo de correo no deseado. Algunos servicios también lidian con lenguaje abusivo también.
creo que no deberías volver a inventar la rueda ... todo puede ser pasado por alto y pirateado, la pregunta es ¿realmente tu sitio es ese tipo de peligro ?. Lo mejor será tener deffence del servidor también. pero agian ... todo se puede pasar por alto –
Leí sobre un enfoque alternativo para engañar a los robots de spam, que es agregar campos ocultos a su formulario que un ser humano normal no modificaría/publicaría en el servidor. El bot de spam puede llenar esos campos, en cuyo caso puedes detectarlo y rechazar lo que estén publicando. – I82Much
@guy: al contrario. Aquí, reinventar la rueda lo defenderá contra spambots no dedicados. – SLaks