parar os bots com Javascript

resumo rápido

é uma técnica conveniente para parar o spam, mas também é inacessível. Usando Javascript para remover atributos de formulário críticos, carregar o conteúdo do formulário dinamicamente e substituir os botões de envio pode ser uma alternativa eficaz que mantém a acessibilidade de seus sites.

anteriormente eu tinha usado. net MVC como a estrutura para o site CANAXESS. O formulário de contato tinha que ser acessível e não podia confiar em nenhum plugin que afetaria negativamente a capacidade do usuário de entrar em contato conosco. O formulário tinha um campo de formulário oculto CSS usando a técnica honeypot e a lógica do lado do servidor rejeitando todos os envios se o campo do formulário contivesse dados.

a teoria de que os bots não conseguem entender o que é um campo legítimo e o que não é e, portanto, o bot identifica e completa todos os campos de entrada e envia o formulário. Se o campo contiver dados, assumimos que, como um usuário não conseguiu navegar para o campo de formulário oculto, um usuário não enviou o formulário e descartou toda a entrada.

as técnicas de Honeypot são sempre identificadas como uma maneira eficaz de parar e-mails de spam e, para mim, a técnica funcionou bem para reduzir o spam a um nível gerenciável por dia. Dentro do meu cliente de E-mail, eu selecionaria todos os e-mails de spam e os excluiria em massa, tudo bem direto se demorado.

Mover para Netlify #

Como parte da mudança de infra-estrutura, o CANAXESS site foi movido para Netlify o que significava que a existente filtragem de spam técnica baseou-teria de ser repensado como o anterior site foi criado .NET e hospedado em um .NET ambiente.

inicialmente optei por não ter proteção contra spam e apenas ver como foi. Como você esperaria, as postagens de spam vieram grossas e rápidas.

usando um honeypot #

o Netlify fornece um recurso honeypot que segue a mesma técnica de usar um campo de entrada oculto e, se for preenchido, todos os e-mails são enviados para a pasta spam.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">
<input class="actual-hidden" name="bot-field" tabindex="-1">

a técnica funcionou de forma muito eficaz; nenhum e-mail legítimo estava chegando à pasta de E-mail normal.

mas a pasta de spam contou outra história. Havia páginas de resultados de spam, onde anteriormente eu podia selecionar todos os e-mails em massa e excluir, a abordagem do Netlify significava que apenas 10-20 e-mails eram devolvidos de cada vez com paginação usada para passar para os próximos dez e-mails. Não havia nenhum recurso de exclusão em massa e eu tive que excluir os individuais.

isso foi incrivelmente demorado e tedioso. Escrevi um bookmarklet Javascript que esperava facilitar a verificação de todos os controles da caixa de seleção na página e a exclusão de todos os registros.

infelizmente, a lógica da página não estava reconhecendo meu bookmarklet como tendo interagido fisicamente com cada controle e não permitiria a seleção de todos os e-mails em massa.

eu também não poderia ter certeza se quaisquer E – mails na pasta de spam eram falsos positivos-e-mails identificados incorretamente, o que significava que eu tinha que vasculhar todos os e-mails para confirmar.

desconto re #

Netlify fornecer Google re e eu inicialmente considerou o seu uso como os e-mails estavam aumentando diariamente.

no entanto, a percepção de uma empresa de Acessibilidade web usando um método conhecido inacessível para as pessoas contatá-los não era uma boa aparência.

eu escrevi anteriormente sobre o quão terrível é uma técnica para minar a acessibilidade de um site e pensei que se eu não pudesse resolver este problema que esperança existe para os outros.

decidi programar minha saída.

torne o formulário menos atraente para bots #

eu precisava fazer o formulário de contato parecer menos um formulário de contato e menos atraente para bots. Comecei a remover o atributo method no elemento do formulário. Se não houver nenhum atributo method, achei que o formulário não poderia ser enviado.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">

infelizmente, embora o atributo tenha sido removido, o Netlify aplicou o atributo method de volta ao formulário enquanto o site era implantado e isso era algo que eu não conseguia controlar.

<form name="contactSubmission" method="post">

usando jQuery para remover um atributo #

decidi usar Javascript (jQuery) para remover dinamicamente o atributo method após o carregamento da página. Usando o evento jQuery ready, o elemento form é selecionado e o atributo method é removido.

$(function(){
$("#contactSubmission").removeAttr("method");
});

eu então exigi uma maneira de adicionar o atributo de volta ao elemento do formulário antes de enviar. Eu tive que adicioná-lo de volta em uma sequência para ter certeza de que o atributo existe antes que o formulário seja enviado, caso contrário, o formulário irá errar e o usuário encontrará um formulário de contato quebrado, dificilmente ideal!

substituindo o botão enviar #

além disso, decidi remover o botão submit também. Descobrir se não havia botão submit o formulário não pode ser enviado por meio de um navegador sem cabeça (se os spammers usaram essa técnica), pois se parece menos com um formulário de contato e mais com uma coleção de campos de entrada.

o envio do formulário ocorreria apenas programaticamente por meio de um elemento button regular.

<input type="button" value="Contact CANAXESS" 
class="contactForm-button submit">

adicionando o atributo method no submit #

o botão regular tinha um manipulador de eventos click que adicionou o atributo method e o valor de volta ao elemento form.

quando o botão é clicado, o atributo é adicionado, mas pode haver casos em que o tempo dos elementos do script acontece ao contrário de como eu queria.

para superar isso, adicionei um intervalo de temporizador. Isso verifica repetidamente o elemento form para o atributo method a cada 100 milissegundos, se nenhum atributo method existir, o formulário não será enviado.

$("input.contactForm-button").click(function(){
$("#contactSubmission").attr("method", "post");
var checkExist = setInterval(function(){ 
var attr = $("#contactSubmission").attr("method");
if (typeof attr !== typeof undefined && attr !== false)
{
$("#contactSubmission").submit();
clearInterval(checkExist);
}
}, 100);
});

o envio do formulário ocorre apenas quando o atributo method existe, e isso ocorreria programaticamente. Quando o formulário foi submetido, o temporizador de intervalo terminaria.

clearInterval(checkExist);

eu pensei que esta era uma maneira bastante eficaz de sobre a engenharia de um formulário de contato para parar bots, mas minha confiança não era para durar. Voltei algumas horas depois para encontrar e-mails de spam coletando novamente.

o envio do formulário está acontecendo via HTTP #

e então me ocorreu que os bots provavelmente nem estão visitando a página pelo navegador, eles não se importam com todo o script jQuery que é executado nos elementos de remoção do clientside.

o atributo method existe quando a página é carregada e, a partir daí, é um simples recorte do HTML e envio do formulário por meio de uma postagem HTTP sem nunca interagir com a página.

e foi essa percepção que me fez identificar a técnica que não apenas retardaria os e-mails de spam, mas os interromperia. Desde a aplicação desta técnica, não tive e-mails, nenhum, zilch.

separando a página do formulário #

a técnica está carregando o fragmento de formulário via Javascript após o carregamento da página. Percebendo que os bots de spam provavelmente não estão usando um navegador sem cabeça para navegar na página de contato e enviar o formulário, em vez disso, fiz o formulário aparecer apenas quando a página foi carregada de um navegador.

a página de contato renderizada no navegador é uma página, mas na realidade é composta por duas partes. A página principal com um espaço reservado para o componente do formulário e o próprio conteúdo do formulário.

<div></div>

Carregando o formulário no carregamento da página #

quando a página é carregada, um evento jQuery ready carrega o fragmento de formulário adicional no contêiner do formulário DIV quase imediatamente.

a página do fragmento de formulário nunca é identificada por um bot como a página inicial que o bot está vendo não tem elemento de formulário, isso só é carregado depois que a página é carregada através de Javascript.

<script>
$(function(){
$("#formContainer").load("formfragment.html");
});
</script>

em resumo #

a técnica requer Javascript para operar. Como o Javascript se tornou uma parte Aceita do desenvolvimento da web, acho que é uma solução realista para parar o spam em certas situações específicas.

a outra técnica de usar campos de honeypot é sempre problemática, pois, pela minha experiência, não foi tão eficaz.

Spam ainda encontraria um caminho e, se eu for honesto, a técnica honeypot só pode ser classificada como um limitador de spam, reduzindo as instâncias de spam.

enquanto o uso funcionaria e seria uma solução rápida, seu uso está prejudicando a acessibilidade da web para pessoas com deficiência.

ao remover o formulário de contato de ser renderizado como parte de uma solicitação HTTP get regular, sua visibilidade para bots parece ser significativamente reduzida e, portanto, reduz (e, no meu caso, parou) os bots de serem capazes de enviar spam por meio do formulário de contato.

coisas para você tentar #

independentemente da estrutura que seu site está usando, se seu formulário de contato estiver sendo comprometido por spam, tente essas abordagens:

• Separar a página e o formulário
• Carregar o formulário depois que a página foi carregada
• Somente formulários de envio de programação usando button os elementos
• Remover method atributo em formulários e adicioná-los como parte do envio do formulário