Per tua informazione @codinghorror, il team di Chrome non ha ancora fatto nulla.
La situazione per Chrome rimane rotta; possiamo risolverla facilmente sostituendo il nostro honeypot di protezione dallo spam con una qualche forma di proof of work.
Chiuso per altri due mesi.
Il team di Chrome sembra molto interessato a risolvere il problema, ma ha bisogno dei log qui:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Vedrò se riesco a raccoglierne alcuni domani. Se qualcuno mi batte sul tempo, sei il mio eroe: contrassegna questo post.
AGGIORNAMENTO … ho inviato loro i log.
@codinghorror questo sta girando a vuoto da Google. Dicono che il comportamento è intenzionale e che non hanno modo di rilevare con precisione se un textarea è visibile o meno.
La risposta generale qui è: “È banale per un bot aggirare questo, quindi qual è lo scopo”. Non ho davvero una risposta, sono quasi d’accordo con loro: la trappola è un po’ assurda e potrei sostituirla facilmente con qualcos’altro per assicurarmi che almeno l’utente stia eseguendo JavaScript quando registra un account.
Ho già dedicato così tanto tempo a questo e mi sento come se stessi combattendo contro i mulini a vento. Voglio solo applicare una correzione e andare avanti.
Ok, ma voglio che sia una prova di lavoro piuttosto complessa. Esiste del codice già pronto che possiamo utilizzare?
Sì, posso mettere insieme qualcosa, sarà certamente migliore del nostro sistema attuale. Il nostro attuale sistema di “proof of work” è “invertire una stringa”.
Ho dedicato troppo tempo a pensare a questo problema, quindi ho deciso che è arrivato il momento di lasciarlo andare:
Con questo commit, l’OP qui è “risolto”
La correzione è piuttosto complessa e ha coinvolto due parti di cui sono felice di aver risolto.
Ho reso molto più rigorosa la logica per honeypot e challenge.
Ho aggiunto una soluzione temporanea lato client per un bug di Chrome nell’autocompletamento; ne sono soddisfatto perché non modifica in alcun modo il protocollo lato server.
In precedenza, riutilizzavamo la nostra stringa casuale per honeypot e challenge per tutte le registrazioni di account sul sito; questo rendeva banale scriptare la creazione di account, poiché bastava codificare a priori un valore.
La nuova implementazione assegna a ogni singolo utente una stringa univoca da validare, legata al tuo archivio cookie (nel nostro archivio sessioni sicuro). Questa stringa scade dopo un’ora.
Ciò significa che, quando si scripta questo tipo di attività, si è costretti a effettuare regolarmente chiamate per ottenere nuove challenge e honeypot tra una richiesta e l’altra, e non è più possibile creare account in massa senza ostacoli.
La soluzione temporanea al punto 2 consiste semplicemente nel rimuovere un INPUT che confonde Chrome e sostituirlo con un INPUT di tipo testo che non crea confusione.
Nel complesso, non ritengo che il punto (2) renda più facile per un bot “genericamente” codificato registrare account su siti sconosciuti. Per cominciare, il bot dovrebbe utilizzare Chrome WebDriver, analizzare tutto il nostro codice Ember e seguire un flusso molto specifico. Questa barriera è molto bassa e nulla in confronto alle nuove challenge rotanti per utente.
Per quanto riguarda l’aggiunta di una prova di lavoro, preferirei attendere un po’, non perché sia particolarmente difficile da implementare, ma soprattutto perché non voglio dover cercare l’algoritmo SHA1 più veloce disponibile e poi inviarlo al client su richiesta.
Lascio aperta questa discussione per un po’ in modo che le persone possano confermare che la mia correzione risolve il problema. La chiuderò tra una settimana.