Isso pode ser uma alternativa ao não uso de CAPTCHA?

Como muitos de vocês tem observado, diversos sites tem usado sistema de cadastro sem o uso de CAPTCHA, estive quebrando um pouco a cabeça buscando uma alternativa, gostaria de compartilhar com vocês, essa ideia pra ver se é válida.

  1. Temos um site, exemplo usando PHP.
  2. Nesse site o desenvolvedor esconde um hash em arquivo
  3. O formulário tem um campo name=“hash” e no Value="" passa esse hash que é predefinido e guardado no site.
  4. No servidor avalia se esse hash é válido, caso sim, autoriza o recebimento.

Como os bots ao enviar verifica cada name e envia os dados, tendo esse hash escondido no site, torna uma alternativa válida? Deixe a opinião de vocês.

1 curtida

Um exemplo claro disso que você representou são os Frameworks para PHP que já vem com isso pronto para utilização, exemplo é o LARAVEL na sua documentação do CSRF Protection, relata bem claro como isso funciona.

Exemplo:

<input type="hidden" name="_token" value="<?php echo csrf_token(); ?>">

Essa tag acima demonstra um exemplo do _token criado e quando for submetido é verificado se o mesmo é válido, e só formulários de dentro do site podem mandar requisição para o mesmo site, limitando, que códigos de terceiros façam e utilize esses formulários.

Exemplos de Códigos Prontos que podem ser adaptados para Site que não utilize Framework ou que também utilizem:

  • force/token
    Simple Token Class

  • volnix/csrf
    CSRF protection library that compares provided token to session token to ensure request validity.

Você pode utiliza-los para adaptar em seus sites ou até mesmo como referencia de estudos.

De antemão agradeço a sua disponibilidade em responder esse artigo de forma excelente e clara, como observei essas alternativas usam Sessions, na arquitetura que estou em planejamento será em Restifull, terá acesso mobile,acho que usar sessions será inviável pois ainda tenho duvidas se outras aplicações mantem estados de Sessions.

Caro @Phablo_Raylan, a sua pergunta ficou genérica, mas, quando se trabalha com dispositivos moveis e tem um login a fazer ele trabalha com uma hash criada pelo servidor que você faz a requisição, a ideia é praticamente a mesma! Talvez mude o local de armazenamento outras configurações que lhe são peculiares, mas, a idéia centra é a mesma!

Claro que para sites isso vai funciona normalmente!

Desculpe não ter entendido completamente!

Exemplo: se tenho um site posso manter uma sessão até fechar o brownser, numa aplicação android acessando com alguma biblioteca cUrl, cria esses cookies de Sessão no servidor?

Se for um site rodando uma aplicação Web para Celulares, é do jeito que eu disse na resposta. Agora se sua aplicação é um Android, Windows Phone ou IOS ai tem que procurar coisa bem especifica e eu ainda não me aventurei a esse mundo !!! Desculpa em não pode ajudar tanto, se for WEB pode perguntar!

Então já que posso abusar um pouco rsrsrs, como funciona um refresh_token?

Da onde é refresh_token? (pode ser tanta coisa)