validar validacion vacios registro formularios formulario ejemplos datos con capturar campos javascript jquery forms security spam

validacion - validar formulario de registro con javascript



Prevención de la presentación de formularios bot (9)

Estoy tratando de encontrar una buena manera de evitar que los bots envíen mi formulario, mientras mantengo el proceso simple. He leído varias ideas geniales, pero pensé en agregar una opción de confirmación cuando se envíe el formulario. El usuario hace clic en enviar y aparece un mensaje de confirmación de Javascript que requiere la interacción del usuario.

¿Esto evitaría los bots o podría un bot resolver esto demasiado fácil? A continuación se muestra el código y JSFIddle para demostrar mi idea:

JSFIDDLE

$(''button'').click(function () { if(Confirm()) { alert(''Form submitted''); /* perform a $.post() to php */ } else { alert(''Form not submitted''); } }); function Confirm() { var _question = confirm(''Are you sure about this?''); var _response = (_question) ? true : false; return _response; }


¡Podría medir el tiempo de registro ofrecido sin necesidad de llenar la eternidad en los cuadros de texto!


Esta es una versión muy corta que no ha fallado desde que se implementó en mis sitios hace 4 años con variaciones adicionales según sea necesario con el tiempo. Esto se puede construir con todas las variables y, si no, las declaraciones que necesite

function spamChk() { var ent1 = document.MyForm.Email.value var str1 = ent1.toLowerCase(); if (str1.includes("noreply")) { document.MyForm.reset(); } <input type="text" name="Email" oninput="spamChk()">

En realidad, hoy he venido aquí para averiguar cómo redireccionar determinadas direcciones IP de spam a HELL ... solo por diversión.


Este es un problema que mucha gente ha encontrado. Como señala pst, el bot solo puede enviar información directamente al servidor, omitiendo el javascript (vea utilidades simples como cURL y Postman ). Muchos bots son capaces de consumir e interactuar con el javascript ahora. Hari krishnan señala el uso de captcha , el más frecuente y exitoso de los cuales (a mi entender) es reCaptcha . Pero los captchas tienen sus problems y están desanimados por el compendio de la World Wide Web, principalmente por razones de ineficacia e inaccesibilidad .

Y no olvidemos que un atacante siempre puede desplegar inteligencia humana para derrotar a un captcha. Hay historias de atacantes que pagan para que la gente saque los captchas con fines de spam, sin que los trabajadores se den cuenta de que participan en actividades ilegales. Amazon ofrece un servicio llamado Mechanical Turk que aborda cosas como esta. Amazon se opondría enérgicamente si utilizaras su servicio con fines maliciosos, y tiene el inconveniente de costar dinero y crear un rastro en papel. Sin embargo, hay más proveedores erhm por ahí que no albergarían tales objeciones.

¿Entonces que puedes hacer?

Mi mecanismo favorito es una casilla oculta. Haga que tenga una etiqueta como "¿Está de acuerdo con los términos y condiciones de uso de nuestros servicios?" Tal vez incluso con un enlace a algunos términos de aspecto serio. Pero lo configura como desactivado y oculto a través de css: colóquelo fuera de la página, colóquelo en un contenedor con una altura cero o un ancho cero, coloque un div sobre la parte superior con un índice z más alto. Rueda tu propio mecanismo aquí y se creativo.

El secreto es que ningún humano verá la casilla de verificación, pero la mayoría de los robots rellenan los formularios al inspeccionar la página y manipularla directamente, no a través de la visión real. Por lo tanto, cualquier formulario que venga con ese conjunto de valores de casilla de verificación le permite saber que no fue llenado por un humano. Esta técnica se llama una trampa de bot . La regla de oro para el tipo de robots de relleno de formulario automático es que si un humano tiene que interceder para superar un sitio individual, entonces ha perdido todo el dinero (en la forma de su tiempo) que habría hecho al difundir su Anuncios de spam.

(La regla de oro anterior asume que está protegiendo un foro o un formulario de comentarios. Si hay dinero real o información personal en la línea, entonces necesita más seguridad que solo una heurística. Esto sigue siendo seguridad en la oscuridad , simplemente resulta que la oscuridad es suficiente para protegerte de ataques ocasionales y con secuencias de comandos. No te engañes pensando que esto protege tu sitio web contra todos los ataques. )

La otra mitad del secreto lo guarda. No altere la respuesta de ninguna manera si la casilla está marcada. Muestra la misma confirmación, gracias, o cualquier mensaje o página posterior. Eso evitará que el bot sepa que ha sido rechazado.

También soy un fan del método de tiempo. Tienes que implementarlo completamente en el lado del servidor. Registre la hora en que se sirvió la página de manera persistente (esencialmente la sesión) y compárela con la hora en que se envía el formulario. Esto evita la falsificación o incluso permite que el bot sepa que se está cronometrando, si hace que la hora servida sea parte de la forma o javascript, luego les dejas saber que estás al tanto de ellos, invitando a un enfoque más sofisticado.

Sin embargo, una vez más, simplemente descarte la solicitud mientras sirve la misma página de agradecimiento (o introduzca un retraso en la respuesta al formulario de correo no deseado, si desea ser vengativo, esto puede evitar que abruman a su servidor y puede incluso dejarlos abrumar). más rápido, manteniendo más conexiones abiertas por más tiempo. En ese momento, necesita una solución de hardware, un firewall en una configuración de equilibrador de carga).

Hay muchos recursos disponibles para retrasar las respuestas del servidor a ralentizar a los atacantes, con frecuencia en forma de intentos de contraseña de fuerza bruta. Esta pregunta de seguridad de TI parece un buen punto de partida.

Actualización sobre Captcha''s.

Había estado pensando en actualizar esta pregunta por un tiempo con respecto al tema de la visión por computadora y el envío de formularios. Recientemente apareció un artículo que me señaló esta publicación de blog de Steve Hickson , un entusiasta de la visión por computadora. Snapchat (al parecer, ¿alguna plataforma de redes sociales? Nunca lo he usado, me siento más viejo cada día ...) lanzó un nuevo sistema parecido a captcha en el que tienes que identificar imágenes (dibujos animados, en realidad) que contienen un fantasma. Steve demostró que esto no verifica la posición en cuclillas sobre el remitente, porque de manera típica, las computadoras son mejores y más rápidas para identificar este tipo simple de imagen.

No es difícil imaginar un enfoque similar para otros tipos de Captcha. Hice una búsqueda y encontré estos enlaces interesantes también:

Es reCaptcha roto?
Captchas prácticos, no basados ​​en imágenes.
Si sabemos que CAPTCHA puede ser vencido, ¿por qué los seguimos usando?
¿Existe una verdadera alternativa al uso de imágenes CAPTCHA?
Cómo un trío de piratas informáticos puso de rodillas al reCaptcha de Google, muy interesante porque se trata de los Captchas de audio.

Ah, y difícilmente estaríamos completos sin un cómic obligatorio de XKCD .


Hoy detuve con éxito un spam continuo de mi formulario. Puede que este método no siempre funcione, por supuesto, pero fue simple y funcionó bien para este caso en particular.

Hice lo siguiente:

  • Establecí la propiedad de acción del formulario en mustusejavascript.asp, que solo muestra un mensaje que indica que el envío no funcionó y que el visitante debe tener habilitado javascript.

  • Establecí la propiedad onsubmit del formulario en una función javascript que establece la propiedad action del formulario en la página de recepción real, como receivemessage.asp

El bot en cuestión aparentemente no maneja javascript, así que ya no veo ningún spam en él. Y para un humano (que tiene activado javascript) funciona sin ningún inconveniente o interacción adicional. Si el visitante tiene desactivado javascript, recibirá un mensaje claro al respecto si realiza un envío.


Me encontré con una validación de entrada de formulario que impedía que la entrada programática se registrara.

Mi táctica inicial fue agarrar el elemento y configurarlo en la Opción que quería. Activé el enfoque en los campos de entrada y simulé clics en cada elemento para obtener los menús desplegables que se muestran y luego establecer el valor que activa los eventos para cambiar los valores. pero cuando intenté hacer clic en guardar las entradas donde no estaba registrado como que había cambiado.

;failed automation attempt because window doesnt register changes. ;$iUse = _IEGetObjById($nIE,"InternalUseOnly_id") ;_IEAction($iUse,"focus") ;_IEAction($iUse,"click") ;_IEFormElementOptionSelect($iUse,1,1,"byIndex") ;$iEdit = _IEGetObjById($nIE,"canEdit_id") ;_IEAction($iEdit,"focus") ;_IEAction($iEdit,"click") ;_IEFormElementOptionSelect($iEdit,1,1,"byIndex") ;$iTalent = _IEGetObjById($nIE,"TalentReleaseFile_id") ;_IEAction($iTalent,"focus") ;_IEAction($iTalent,"click") ;_IEFormElementOptionSelect($iTalent,2,1,"byIndex") ;Sleep(1000) ;_IEAction(_IETagNameGetCollection($nIE,"button",1),"click")

Esto me hizo reconsiderar cómo se podría ingresar la entrada manipulando directamente las acciones del mouse para simular más selección con el comportamiento del tipo de mouse. No hace falta decir que no tengo que subir manualmente las imágenes 1 por 1 para actualizar las imágenes de los productos para las empresas. usé el número de Windows antes de las letras para tener mi script al final del directorio y cuando aparece la ventana de carga de la imagen, tengo que usar la accesibilidad activa para obtener la vista del syslistview de la ventana y seleccionar el segundo elemento que es una imagen, el primer elemento es una carpeta . o el primer elemento en un retorno de findfirstfile solo llama a los archivos. Utilizo el nombre para buscar el elemento en una base de datos de elementos y luego accedo a esos elementos y actualizo algunos atributos después de cargar las imágenes, luego muevo el archivo de esa carpeta a otra carpeta para que no se vuelva a procesar y pase al siguiente primer archivo de la lista y haga un bucle hasta que se encuentre el nombre del script al final de la actualización.

Solo compartiendo cómo una persona de entrada de datos humilde ahorra tiempo y lucha contra todas estas verificaciones de validación de forma malvada.

Saludos.


No puedes lograr tu objetivo con javascript. porque un cliente puede analizar su javascript y omitir sus métodos. Tienes que hacer la validación en el lado del servidor a través de captchas. la idea principal es que almacene un secreto en el lado del servidor y valide el formulario enviado desde el cliente con el secreto en el lado del servidor.


No, ¿realmente sigues pensando que Captcha o ReCap son seguros?

Bots nowDays son inteligentes y pueden reconocer fácilmente las letras en las imágenes usando las herramientas de OCR (búsquelas para entender)

¡Digo que la mejor manera de protegerse del envío automático de formularios es agregar un hash oculto generado (y almacenado en la sesión en su servidor del cliente actual) cada vez que muestre el formulario para enviarlo!

Eso es todo cuando el Bot o cualquier Zombie envían el formulario para verificar si el hash dado es igual al hash almacenado en la sesión;)

para más información lea sobre CSRF !


Simplemente puede agregar captcha a su formulario. Dado que los captchas serán different y también en images , los bots no pueden decode eso. Este es uno de los sistemas de seguridad más utilizados para todos los sitios web ...


Su código no evitaría el envío de bots, pero no se debe a cómo es su código. El bot típico que hay por ahí probablemente hará una solicitud POST externa / automatizada a la URL (atributo de action ). Los bots típicos no están mostrando HTML, CSS o JavaScript. Están leyendo el HTML y actuando sobre ellos, por lo que no se ejecutará ninguna lógica de cliente. Por ejemplo, CURLing una URL obtendrá el marcado sin cargar ni evaluar ningún JavaScript. Uno podría crear un script simple que busque <form> y luego haga un CURL POST a esa URL con las claves correspondientes.

Con eso en mente, es necesaria una solución del lado del servidor para evitar el envío de bots. Captcha + CSRF debería ser suficiente. ( http://en.wikipedia.org/wiki/Cross-site_request_forgery )