Come nascondere un honeypot (esclusi CSS e JS esterni)

3

Aggiungo protezione anti-spam al mio framework php personale e penso che gli honeypot siano un ottimo modo per bloccare lo spam. Sfortunatamente non sono stati inventati ieri e probabilmente la maggior parte dei robot recupera i CSS e può capire se il campo è reale o meno. Ad esempio, se stavo progettando un bot per lo spam sarebbe molto intuitivo per me far sì che i miei bot perdessero i campi con display: none nel loro attributo di stile o nei campi che hanno attributi di stile relativamente grandi come width:0; height:0; border:none; background:none; position:absolute; cursor:defualt che è comunque quello che ho Attualmente sto usando. Inoltre se tutti gli altri campi mancano di un attributo di stile è altamente possibile che l'unico che non lo è è un honeypot.

In altre parole, mi sembra che i vasi di miele non siano così difficili da individuare. Qualcuno con la pratica può dirmi quale è il modo migliore per nascondere un honeypot?

E JavaScript non è davvero un'opzione perché sto costruendo questo, come ho detto, come parte di un framework, quindi non posso davvero hardcode alcuni JS in una funzione PHP.

E infine, non ci sono tag spam quindi sto taggando questo come sicurezza.

    
posta php_nub_qq 11.02.2015 - 16:56
fonte

1 risposta

3

Se stai creando un framework web, questo implica che puoi servire risorse come HTML, CSS e JS. Se deve esserlo, potresti persino integrare tutte le risorse in HTML. È quindi possibile utilizzare le tecniche basate su CSS e JavaScript per rendere arbitrariamente difficile lo spam del modulo.

Per ogni campo modulo, puoi applicare una percentuale diversa diclass. Solo uno di questi sarà usato per designare l'honeypot, e puoi usare i CSS per nascondere quell'input. Ciò richiede che i robot spam includano un parser CSS completo e scoprano se un determinato input sarà visibile. Questo è abbastanza non banale. L'uso di attributi di stile in linea non offre una protezione simile, dal momento che è possibile utilizzare un'espressione regolare come /\bdisplay:\s*none\b/ per rilevarli. L'uso di CSS come questo è il 20% di sforzo, l'80% di una soluzione di successo che vale davvero la pena fare.

Puoi facilmente migliorare questa protezione, ad es. applicando le classi necessarie tramite JavaScript. Ciò richiede che i robot eseguano un interprete JavaScript, ma questo risulta molto più semplice della risoluzione delle regole CSS. Puoi offuscare le tue regole CSS per richiedere ai robot di implementare pienamente i CSS. Pensa a regole come .the-next-one-is-spam + .field { display: none } . Puoi generare automaticamente identificatori di classe su ogni caricamento della pagina, in modo che le regole speciali per il tuo sito siano inutili per un bot. Oppure potresti rinunciare a provare a mettere insieme la tua soluzione e semplicemente utilizzare un captcha provider esistente.

Il problema con gli honeypot è che da un lato, devono essere indistinguibili dai campi di input reali. D'altra parte, ci possono essere utenti con browser basati su testo o utenti che fanno affidamento su tecnologie assistive. Altri utenti potrebbero sostituire i propri fogli di stile. Non puoi fare affidamento su tutti i tuoi utenti affinché JS e CSS siano abilitati, e sarebbe bello se il tuo sito fosse comunque utilizzabile. A seconda della giurisdizione e del tipo di progetto, potresti essere legalmente obbligato a supportare gli utenti delle tecnologie assistive.

Inoltre, gli honeypot non offrono protezione contro gli spammer umani che utilizzano browser reali. Gli honeypot possono essere uno strato di difesa, ma da soli non possono offrire una protezione totale. Sono utili solo per estirpare le orde di bot a basso sforzo in cerca di moduli di commento non protetti scritti con la comprensione della sicurezza di uno script di 90 anni.

    
risposta data 12.02.2015 - 12:38
fonte

Leggi altre domande sui tag