Ho accettato una risposta, ma purtroppo credo che siamo bloccati con il nostro scenario peggiore originale: CAPTCHA tutti nei tentativi di acquisto della merda . Breve spiegazione: le cache / web farm rendono impossibile tenere traccia degli hit e qualsiasi soluzione alternativa (invio di un web beacon non memorizzato nella cache, scrittura su una tabella unificata, ecc.) Rallenta il sito in modo peggiore rispetto ai bot. Probabilmente esiste un hardware costoso di Cisco o simili che può aiutare a un livello elevato, ma è difficile giustificare il costo se CAPTCHA è una alternativa per tutti. Cercherò una spiegazione più completa in seguito, oltre a ripulirla per i futuri ricercatori (anche se altri sono invitati a provare, poiché è wiki della comunità).

Situazione

Si tratta delle vendite di cazzate su woot.com. Sono il presidente di Woot Workshop, la consociata di Woot che si occupa della progettazione, scrive descrizioni dei prodotti, podcast, post di blog e modera i forum. Lavoro con CSS / HTML e conosco a malapena altre tecnologie. Lavoro a stretto contatto con gli sviluppatori e ho parlato di tutte le risposte qui (e di molte altre idee che abbiamo avuto).

L'usabilità è una parte enorme del mio lavoro e rendere il sito eccitante e divertente è la maggior parte del resto. Ecco dove derivano i tre obiettivi sottostanti. CAPTCHA danneggia l'usabilità e i robot rubano il divertimento e l'eccitazione delle nostre vendite di merda.

I robot stanno sbattendo la nostra prima pagina decine di volte una seconda schermata che raschia (e / o scansiona il nostro RSS) per la vendita di Schifezze Casuali. Nel momento in cui lo vedono, innesca una seconda fase del programma che accede, fa clic su I want One, compila il modulo e acquista la merda.

Valutazione

lc : su StackOverflow e altri siti che utilizzano questo metodo, hanno quasi sempre a che fare con utenti autenticati (registrati), perché l'attività che si sta tentando lo richiede.

Su Woot, gli utenti anonimi (non registrati) possono visualizzare la nostra home page. In altre parole, i robot che sbattono possono essere non autenticati (e sostanzialmente non tracciabili tranne che per indirizzo IP).

Quindi torniamo alla ricerca di IP, che a) è abbastanza inutile in questa era di reti cloud e zombie spambot eb) cattura troppi innocenti dato il numero di aziende che provengono da un indirizzo IP (per non parlare dei problemi con ISP IP non statici e potenziali risultati delle prestazioni nel tentativo di rintracciarlo).

Oh, e avere persone che ci chiamano sarebbe lo scenario peggiore possibile. Possiamo farti chiamare?

BradC : I metodi di Ned Batchelder sembrano piuttosto interessanti, ma sono abbastanza ben progettati per sconfiggere i bot creati per una rete di siti. Il nostro problema è che i robot sono creati appositamente per sconfiggere il nostro sito. Alcuni di questi metodi potrebbero probabilmente funzionare per un breve periodo di tempo fino a quando gli script non hanno evoluto i loro bot per ignorare l'honeypot, lo screen-scrape per i nomi delle etichette nelle vicinanze invece degli ID dei moduli e utilizzare un controllo browser compatibile con javascript.

Ancora una volta : "A meno che, ovviamente, l'hype faccia parte del tuo schema di marketing." Sì, lo è sicuramente. La sorpresa di quando appare l'oggetto, così come l'eccitazione se riesci a ottenerne uno è probabilmente tanto o più importante della merda che effettivamente ottieni. Tutto ciò che elimina il primo arrivato / primo servito è dannoso per il brivido di "vincere" la merda.

novatrust : E, per uno, accolgo con favore i nostri nuovi signori bot. In realtà offriamo RSSfeed per consentire alle app di terze parti di scansionare il nostro sito alla ricerca di informazioni sui prodotti, ma non in anticipo rispetto all'HTML del sito principale. Se lo sto interpretando bene, la tua soluzione aiuta l'obiettivo 2 (problemi di prestazioni) sacrificando completamente l'obiettivo 1 e semplicemente dimettendosi dal fatto che i robot compreranno la maggior parte della merda. Ho votato a favore della tua risposta, perché il tuo ultimo pessimismo del paragrafo mi sembra accurato. Sembra che qui non ci siano proiettili d'argento.

Le altre risposte si basano generalmente sul tracciamento IP, che, di nuovo, sembra sia inutile (con reti bot / zombi / rete cloud) sia dannoso (catturare molti innocenti che provengono da destinazioni dello stesso IP).

Altri approcci / idee? I miei sviluppatori continuano a dire "facciamo semplicemente CAPTCHA" ma spero che ci siano metodi meno invadenti per tutti gli umani reali che vogliono un po 'della nostra merda.

Domanda originale

Supponiamo che tu stia vendendo qualcosa di economico che ha un valore percepito molto elevato e che hai un importo molto limitato. Nessuno sa esattamente quando venderai questo oggetto. E oltre un milione di persone vengono regolarmente per vedere cosa stai vendendo.

Ti ritrovi con scripter e robot che tentano di capire programmaticamente [a] quando vendi detto articolo, e [b] assicurati che siano tra i primi a comprarlo. Questo fa schifo per due motivi:

1. Il tuo sito è bloccato da non umani, rallentando tutto per tutti.
2. Gli scripter finiscono per "vincere" il prodotto, facendo sentire tristi i clienti abituali.

Una soluzione apparentemente ovvia è quella di creare dei cerchi che i tuoi utenti possano saltare prima di effettuare l'ordine, ma ci sono almeno tre problemi con questo:

• L'esperienza dell'utente fa schifo per gli umani, poiché devono decifrare CAPTCHA, scegliere il gatto o risolvere un problema di matematica.
• Se il beneficio percepito è abbastanza alto e la folla abbastanza grande, alcuni gruppi troveranno il modo di aggirare qualsiasi modifica, portando a una corsa agli armamenti. (Ciò è particolarmente vero quanto più semplice è la modifica; modulo nascosto di "commenti", riorganizzazione degli elementi del modulo, etichettatura errata, testo nascosto di "gotcha" tutto funzionerà una volta e quindi dovrà essere modificato per combattere il targeting di questo modulo specifico .)
• Anche se gli scripter non riescono a "risolvere" il tuo tweak, ciò non impedisce loro di sbattere la tua prima pagina, e quindi emettere un allarme affinché lo scripter compili manualmente l'ordine. Dato che traggono vantaggio dalla risoluzione di [a], probabilmente vinceranno ancora [b] poiché saranno i primi umani a raggiungere la pagina dell'ordine. Inoltre, 1. si verifica ancora, causando errori del server e una riduzione delle prestazioni per tutti.

Un'altra soluzione è quella di controllare se gli IP colpiscono troppo spesso, bloccarli dal firewall o impedire loro di ordinare. Questo potrebbe risolvere il 2. e prevenire [b] ma il colpo di prestazione della scansione per gli IP è enorme e probabilmente causerebbe più problemi come 1. che gli scripter stavano causando da soli. Inoltre, la possibilità di rete in rete e zombie spambot rende il controllo IP abbastanza inutile.

Una terza idea, forzando il caricamento del modulo d'ordine per un po 'di tempo (diciamo, mezzo secondo) potrebbe potenzialmente rallentare l'avanzamento degli ordini rapidi, ma, ancora una volta, gli scripter sarebbero ancora i primi a entrare, a qualsiasi velocità non dannosa per utenti reali.

obiettivi

1. Vendi l'oggetto a umani non scripting.
2. Mantieni il sito in esecuzione a una velocità non rallentata dai robot.
3. Non disturbare gli utenti "normali" con nessuna attività da completare per dimostrare che sono umani.

Che ne dici di implementare qualcosa come SO fa con i CAPTCHA?

Se stai usando il sito normalmente, probabilmente non ne vedrai mai uno. Se ti capita di ricaricare la stessa pagina troppo spesso, pubblicare commenti successivi troppo rapidamente o qualcos'altro che innesca un allarme, fai loro dimostrare che sono umani. Nel tuo caso, si tratterebbe probabilmente di ricaricare costantemente la stessa pagina, seguendo rapidamente ogni link su una pagina o compilando un modulo d'ordine troppo velocemente per essere umano.

Se falliscono il controllo x volte di seguito (diciamo, 2 o 3), assegna a quell'IP un timeout o altra misura simile. Quindi alla fine del timeout, scaricarli di nuovo al controllo.

Dato che hai utenti non registrati che accedono al sito, hai solo gli IP per continuare. Puoi inviare sessioni a ciascun browser e tracciare in questo modo, se lo desideri. E, naturalmente, lancia un controllo umano se troppe sessioni vengono (ri) create in successione (nel caso in cui un bot continui a eliminare il cookie).

Per quanto riguarda la cattura di troppi innocenti, è possibile presentare una dichiarazione di non responsabilità nella pagina di controllo umano: "Questa pagina può anche apparire se troppi utenti anonimi stanno visualizzando il nostro sito dalla stessa posizione. Ti consigliamo di registrarti o accedere per evitare Questo." (Regola la formulazione in modo appropriato.)

Inoltre, quali sono le probabilità che X persone stiano caricando le stesse pagine contemporaneamente da un IP? Se sono alti, forse hai bisogno di un meccanismo di attivazione diverso per il tuo allarme bot.

Modifica: un'altra opzione è se falliscono troppe volte e sei sicuro della domanda del prodotto, per bloccarli e farli CHIAMARE personalmente per rimuovere il blocco.

Far chiamare le persone sembra una misura asinina, ma si assicura che ci sia un umano da qualche parte dietro il computer . La chiave è avere il blocco in atto solo per una condizione che non dovrebbe quasi mai accadere a meno che non sia un bot (es. Fallire il controllo più volte di seguito). Quindi FORZA l'interazione umana - per alzare il telefono.

In risposta al commento di avermi chiamato, c'è ovviamente quel compromesso qui. Sei abbastanza preoccupato di garantire che i tuoi utenti siano umani per accettare un paio di telefonate quando vanno in vendita? Se fossi così preoccupato per un prodotto che arriva agli utenti umani, dovrei prendere questa decisione, forse sacrificando un po 'del mio tempo nel processo.

Dal momento che sembra che tu sia determinato a non permettere ai robot di avere il sopravvento / sbattere il tuo sito, credo che il telefono possa essere una buona opzione. Dal momento che non traggo profitto dal tuo prodotto, non ho interesse a ricevere queste chiamate. Se dovessi condividere parte di quel profitto, tuttavia, potrei diventare interessato. Poiché questo è il tuo prodotto, devi decidere quanto tieni e implementare di conseguenza.

Gli altri modi per rilasciare il blocco non sono altrettanto efficaci: un timeout (ma dovrebbero sbattere di nuovo il tuo sito dopo, risciacquare-ripetere), un lungo timeout (se fosse davvero un essere umano che cerca di acquistare il tuo prodotto, sarebbero SOL e puniti per aver fallito il controllo), e-mail (facilmente eseguita dai robot), fax (stesso) o posta ordinaria (impiega troppo tempo).

Ovviamente, invece, potresti avere un aumento del periodo di timeout per IP ogni volta che ottengono un timeout. Assicurati solo di non punire inavvertitamente i veri umani.

Devi trovare un modo per fare in modo che i robot acquistino roba che è enormemente costosa: galletto da 12 mm: $ 20. Scopri quanti robot si attivano prima che gli sceneggiatori decidano che stai giocando.

Usa i profitti per acquistare più server e pagare per la larghezza di banda.

La mia soluzione sarebbe quella di rendere inutilizzabile lo screen-scraping inserendo un ritardo di circa 10 minuti per "robot e script".

Ecco come lo farei:

• Accedi e identifica tutti i ripetitori.

Non è necessario registrare ogni indirizzo IP ad ogni hit. Traccia solo uno su ogni 20 colpi circa. Un trasgressore ripetuto apparirà comunque in un tracciamento occasionale randomizzato.

• Conserva una cache della tua pagina da circa 10 minuti prima.

• Quando un ripetitore / bot colpisce il tuo sito, dai loro la pagina cache di 10 minuti.

Non sapranno immediatamente che stanno ottenendo un vecchio sito. Saranno in grado di raschiarlo e tutto il resto, ma non vinceranno più alcuna gara, perché le "persone reali" avranno un vantaggio di 10 minuti.

Benefici:

• Nessuna seccatura o problema per gli utenti (come CAPTCHA).
• Implementato completamente sul lato server. (nessuna dipendenza da Javascript / Flash)
• La pubblicazione di una pagina cache più vecchia dovrebbe richiedere meno prestazioni rispetto a una pagina live. Puoi effettivamente ridurre il carico sui tuoi server in questo modo!

svantaggi

• Richiede il monitoraggio di alcuni indirizzi IP
• Richiede il mantenimento e il mantenimento di una cache di pagine precedenti.

Cosa ne pensi?

Dai un'occhiata a questo articolo di ned Batchelder qui . Il suo articolo riguarda l'interruzione degli spambots, ma le stesse tecniche potrebbero facilmente applicarsi al tuo sito.

Invece di fermare i robot facendo in modo che le persone si identifichino, possiamo fermarli rendendo difficile per loro pubblicare un post di successo o facendoli inavvertitamente identificarsi come bot. Ciò rimuove l'onere delle persone e lascia il modulo di commento libero da misure anti-spam visibili.

Questa tecnica è come prevenire gli spambots su questo sito. Funziona. Il metodo descritto qui non esamina affatto il contenuto.

Alcune altre idee:

• Crea un meccanismo di notifica automatica ufficiale (feed RSS? Twitter?) A cui le persone possono abbonarsi quando il tuo prodotto è in vendita. Ciò riduce la necessità per le persone di creare script.
• Cambia la tua tecnica di offuscamento poco prima che un nuovo articolo venga messo in vendita. Quindi, anche se gli scripter possono intensificare la corsa agli armamenti, sono sempre indietro di un giorno.

MODIFICA: Per essere totalmente chiari, l'articolo di Ned sopra descrive i metodi per impedire l'acquisto automatico di articoli impedendo a un BOT di esaminare i moduli per inviare un ordine. Le sue tecniche non sarebbero utili per impedire ai robot di graffiare lo schermo della home page per determinare quando un Bandoleer di carote è in vendita. Non sono sicuro che prevenire QUELLO sia davvero possibile.

Per quanto riguarda i tuoi commenti sull'efficacia delle strategie di Ned: Sì, discute gli honeypot, ma non credo sia la sua strategia più forte. La sua discussione sullo SPINNER è il motivo originale per cui ho citato il suo articolo. Mi dispiace di non averlo chiarito nel mio post originale:

Lo spinner è un campo nascosto utilizzato per alcune cose: racchiude insieme un numero di valori che impediscono manomissioni e ripetizioni e viene utilizzato per oscurare i nomi dei campi. Lo spinner è un hash MD5 di:

• Il timestamp,
• L'indirizzo IP del cliente,
• L'ID della voce del blog commentato e
• Un segreto.

Ecco come è possibile implementarlo su WOOT.com:

Modifica il valore "segreto" utilizzato come parte dell'hash ogni volta che un nuovo articolo viene messo in vendita. Ciò significa che se qualcuno progetterà un BOT per l'acquisto automatico di articoli, funzionerebbe solo fino a quando l'articolo successivo non sarà in vendita !!

Anche se qualcuno è in grado di ricostruire rapidamente il proprio bot, tutti gli altri utenti effettivi avranno già acquistato un BOC e il tuo problema è risolto!

L'altra strategia che discute è di cambiare la tecnica honeypot di volta in volta (di nuovo, cambiarla quando un nuovo oggetto viene messo in vendita):

• Utilizzare le classi CSS (ovviamente randomizzate) per impostare i campi o un elemento contenente da visualizzare: nessuno.
• Colora i campi allo stesso (o molto simile a) lo sfondo della pagina.
• Utilizzare il posizionamento per spostare un campo fuori dall'area visibile della pagina.
• Rendi un elemento troppo piccolo per mostrare il campo honeypot contenuto.
• Lascia i campi visibili, ma usa il posizionamento per coprirli con un elemento oscuro.
• Usa Javascript per effettuare queste modifiche, richiedendo a un bot di avere un motore Javascript completo.
• Lascia gli honeypot visualizzati come gli altri campi, ma dì alle persone di non inserire nulla al loro interno.

Immagino che la mia idea generale sia quella di CAMBIARE IL DESIGN DELLA FORMA quando ogni nuovo articolo sarà messo in vendita. O almeno, cambiarlo quando viene messo in vendita un nuovo BOC.

Qual è cosa, un paio di volte al mese?

Se accetti questa risposta, mi darai un avvertimento quando è prevista la prossima? :)

D: Come impediresti agli scripter di sbattere il tuo sito centinaia di volte al secondo?
A: Non lo fai. Non è possibile impedire questo comportamento da parte di agenti esterni.

Potresti impiegare una vasta gamma di tecnologie per analizzare le richieste in arrivo e tentare euristicamente di determinare chi è e non è umano ... ma fallirebbe. Alla fine, se non immediatamente.

L'unica soluzione praticabile a lungo termine è cambiare il gioco in modo che il sito non sia adatto ai bot o meno attraente per gli script.

Come si fa a farlo? Bene, questa è una domanda diversa! ;-)

...

OK, alcune opzioni sono state fornite (e rifiutate) sopra. Non ho familiarità con il tuo sito, dopo averlo guardato una sola volta, ma poiché le persone possono leggere il testo in immagini e i robot non possono farlo facilmente, cambia l'annuncio in un'immagine. Non un CAPTCHA , solo un'immagine -

• genera l'immagine (ovviamente memorizzata nella cache) quando viene richiesta la pagina
• mantieni lo stesso nome della fonte dell'immagine, in modo da non dare via al gioco
• la maggior parte delle volte l'immagine avrà un testo normale e sarà allineata per far parte della pagina HTML incorporata
• quando il gioco è "acceso", l'immagine cambia nel testo dell'annuncio
• il testo dell'annuncio rivela un URL e / o un codice che deve essere inserito manualmente per acquisire il premio. CAPTCHA il codice se vuoi, ma probabilmente non è necessario.
• per ulteriore sicurezza, il codice può essere un token una tantum generato appositamente per la richiesta / IP / agente, in modo che le richieste ripetute generino codici diversi. Oppure puoi pre-generare un gruppo di codici casuali (un pad una tantum) se la generazione su richiesta è troppo faticosa.

Esegui le prove a tempo di persone reali che rispondono a questo, e ignora ('oops, si è verificato un errore, scusa! Per favore riprova') le risposte più velocemente di (diciamo) metà di questo tempo. Questo evento dovrebbe anche innescare un avviso agli sviluppatori che almeno un bot ha capito il codice / gioco, quindi è tempo di cambiare il codice / gioco.

Continua comunque a cambiare periodicamente il gioco, anche se nessun robot lo attiva, solo per perdere tempo negli script. Alla fine gli scripter dovrebbero stancarsi del gioco e andare altrove ... speriamo ;-)

Un ultimo suggerimento: quando arriva una richiesta per la tua pagina principale, inseriscila in una coda e rispondi alle richieste in ordine in un processo separato (potresti dover hackerare / estendere il web server per farlo, ma probabilmente sarà vale la pena). Se arriva un'altra richiesta dallo stesso IP / agente mentre la prima richiesta è in coda, ignorarla. Ciò dovrebbe eliminare automaticamente il carico dai robot.

EDIT: un'altra opzione, oltre all'uso delle immagini, è usare javascript per compilare il testo compra / no-compra; i robot raramente interpretano javascript, quindi non lo vedrebbero

Non so quanto sia fattibile: ... vai all'offensiva.

Scopri quali dati stanno cercando i robot. Dai loro i dati che stanno cercando quando NON vendi la merda. Fallo in modo da non disturbare o confondere gli utenti umani. Quando i robot attivano la fase due, accedono e compilano il modulo per acquistare $ 100 roombas anziché BOC. Naturalmente, questo presuppone che i robot non siano particolarmente robusti.

Un'altra idea è quella di implementare cali di prezzo casuali nel corso del periodo di vendita di bag o crap. Chi comprerebbe una valigia a caso per $ 150 quando DICHIARA CHIARAMENTE che vale solo $ 20? Nessuno ma robot troppo zelanti. Ma poi 9 minuti dopo sono $ 35 dollari ... poi 17 minuti dopo sono $ 9. O qualunque cosa.

Certo, i re degli zombi sarebbero in grado di reagire. Il punto è rendere i loro errori molto costosi per loro (e farli pagare per combatterli).

Tutto questo presuppone che tu voglia far incazzare alcuni signori dei bot, il che potrebbe non essere consigliabile al 100%.

Quindi il problema sembra essere davvero: i robot vogliono la loro "borsa", perché ha un alto valore percepito a un basso prezzo percepito. A volte offri questo oggetto e i robot si nascondono, aspettando di vedere se è disponibile e poi acquistano l'oggetto.

Dal momento che sembra che i proprietari dei bot stiano realizzando un profitto (o potenzialmente realizzando un profitto), il trucco è renderlo non redditizio per loro incoraggiandoli ad acquistare la merda.

Per prima cosa, offri sempre il "bag 'o crap".

In secondo luogo, assicurati che la merda sia di solito una merda.

Terzo, ruota frequentemente le schifezze.

Semplice no?

Avrai bisogno di un permanente "perché la nostra merda a volte è una schifezza?" link accanto all'offerta per spiegare agli umani cosa sta succedendo.

Quando il bot vede che c'è una schifezza e la schifezza viene acquistata automaticamente, il destinatario sarà terribilmente arrabbiato per aver pagato $ 10 per uno stecchino rotto. E poi un sacco della spazzatura vuoto. E poi un po 'di sporco dal fondo della scarpa.

Se acquistano abbastanza di questa merda in un periodo di tempo relativamente breve (e hai grosse dichiarazioni di non responsabilità in tutto il luogo che spiegano perché lo stai facendo), perderanno un "bag 'o cash" equo sul tuo " bag 'o crap ". Anche l'intervento umano da parte loro (verificando che la cagata non sia una cagata) può fallire se si ruota la cagata abbastanza spesso. Cavolo, forse i robot noteranno e non compreranno nulla che è stato nella rotazione per un tempo troppo breve, ma ciò significa che gli umani compreranno la non merda.

Diamine, i tuoi clienti abituali potrebbero essere così divertiti da poterlo trasformare in un'enorme vittoria di marketing. Inizia a pubblicare quanta parte della carpa "merda" viene venduta. Le persone torneranno solo per vedere quanto sono stati morsi i robot.

Aggiornamento: mi aspetto che potresti ricevere alcune chiamate in anticipo con le persone che si lamentano. Non penso che tu possa fermarlo del tutto. Tuttavia, se questo uccide i robot, puoi sempre fermarlo e riavviarlo in seguito.

1. Vendi l'oggetto a umani non scripting.

2. Mantieni il sito in esecuzione a una velocità non rallentata dai robot.

3. Non disturbare gli utenti "normali" con nessuna attività da completare per dimostrare che sono umani.

Probabilmente non vorrai sentirlo, ma # 1 e # 3 si escludono a vicenda.

Beh, nessuno sa nemmeno che sei un robot. Non esiste un modo programmatico per dire se c'è un essere umano dall'altra parte della connessione senza richiedere alla persona di fare qualcosa. Impedire a script / bot di fare cose sul web è il motivo principale per cui sono stati inventati i CAPTCHA. Non è che questo sia un nuovo problema che non ha visto molti sforzi. Se ci fosse un modo migliore per farlo, uno che non ha comportato la seccatura per gli utenti reali di un CAPTCHA, tutti lo userebbero già.

Penso che tu debba affrontare il fatto che se vuoi tenere i robot fuori dalla tua pagina degli ordini, un buon CAPTCHA è l'unico modo per farlo. Se la domanda per le tue schifezze casuali è abbastanza alta da consentire alle persone di fare di tutto per ottenerle, gli utenti legittimi non saranno scoraggiati da un CAPTCHA.

Il metodo utilizzato da Woot per combattere questo problema sta cambiando il gioco - letteralmente. Quando presentano in vendita un oggetto straordinariamente desiderabile, fanno in modo che gli utenti giochino un videogioco per ordinarlo.

Questo non solo combatte con successo i robot (possono facilmente apportare piccole modifiche al gioco per evitare i giocatori automatici o persino fornire un nuovo gioco per ogni vendita), ma dà anche l'impressione agli utenti di "vincere" l'oggetto desiderato mentre rallenta il processo di ordinazione.

Si esaurisce ancora molto rapidamente, ma penso che la soluzione sia buona: rivalutare il problema e modificare i parametri ha portato a una strategia di successo in cui semplicemente non esistevano soluzioni strettamente tecniche.

L'intero modello di business si basa sul "primo arrivato, primo servito". Non puoi fare ciò che hanno fatto le stazioni radio (non vincono più il primo chiamante, vincono il 5 ° o 20 ° o 13 ° chiamante) - non corrisponde alla tua caratteristica principale.

No, non c'è modo di farlo senza cambiare l'esperienza di ordinazione per gli utenti reali.

Supponiamo che tu attui tutte queste tattiche. Se decido che questo è importante, farò semplicemente lavorare 100 persone con me, creeremo software per funzionare sui nostri 100 computer separati e accederemo al tuo sito 20 volte al secondo (5 secondi tra gli accessi per ciascun utente / cookie / account / indirizzo IP).

Hai due fasi:

1. Guardando la prima pagina
2. ordinazione

Non puoi mettere un captcha che blocchi # 1 - questo perderà i clienti reali ("Cosa? Devo risolvere un captcha ogni volta che voglio vedere l'ultimo woot?!?").

Quindi il mio piccolo gruppo guarda, cronometrato insieme in modo da ottenere circa 20 controlli al secondo, e chiunque vede la modifica per primo avvisa tutti gli altri (automaticamente), che caricherà di nuovo la prima pagina, seguirà il collegamento dell'ordine ed eseguirà la transazione ( che può anche accadere automaticamente, a meno che tu non implementi captcha e lo cambi per ogni wootoff / boc).

Puoi mettere un captcha di fronte al n. 2, e mentre detesti farlo, potrebbe essere l'unico modo per assicurarti che anche se i robot guardano la prima pagina, gli utenti reali stanno ottenendo i prodotti.

Ma anche con captcha la mia piccola banda di 100 avrebbe ancora un vantaggio significativo sulla prima mossa - e non c'è modo di dire che non siamo umani. Se inizi a programmare i nostri accessi, aggiungeremmo un po 'di jitter. Potremmo selezionare casualmente il computer da aggiornare in modo che l'ordine degli accessi cambi costantemente - ma sembra ancora abbastanza come un essere umano.

Per prima cosa, sbarazzati dei semplici robot

È necessario disporre di un firewall adattivo che segua le richieste e se qualcuno sta facendo l'ovvia stupida cosa: rinfrescare più di una volta al secondo allo stesso IP, quindi utilizzare tattiche per rallentarle (rilasciare i pacchetti, rispedire rifiutati o 500 errori, ecc. ).

Ciò dovrebbe ridurre in modo significativo il traffico e alterare le tattiche utilizzate dagli utenti di bot.

In secondo luogo, rendere il server incredibilmente veloce.

Davvero non vuoi sentire questo ... ma ...

Penso che ciò di cui hai bisogno sia una soluzione completamente personalizzata dal basso verso l'alto.

Non è necessario pasticciare con lo stack TCP / IP, ma potrebbe essere necessario sviluppare un server personalizzato molto, molto, molto veloce, appositamente progettato per correlare le connessioni utente e reagire in modo appropriato a vari attacchi.

Apache, lighthttpd, ecc. Sono tutti ottimi per essere flessibili, ma gestisci un sito web a scopo unico e devi davvero essere in grado di fare entrambi più di quanto gli attuali server siano in grado di fare (sia nella gestione del traffico, sia nella lotta appropriata dei bot ).

Servendo una pagina Web in gran parte statica (aggiornamenti ogni 30 secondi circa) su un server personalizzato non dovresti essere in grado di gestire solo 10 volte il numero di richieste e traffico (perché il server non sta facendo altro che ottenere la richiesta e leggere la pagina dalla memoria al buffer TCP / IP) ma ti darà anche accesso a metriche che potrebbero aiutarti a rallentare i robot. Ad esempio, correlando gli indirizzi IP è possibile semplicemente bloccare più di una connessione al secondo per IP. Gli umani non possono andare più veloci di così, e anche le persone che usano lo stesso indirizzo IP NAT saranno raramente bloccate. Vorresti fare un blocco lento: lascia la connessione sola per un secondo intero prima di terminare ufficialmente la sessione. Questo può alimentare un firewall per fornire blocchi a più lungo termine a trasgressori particolarmente gravi.

Ma la realtà è che, qualunque cosa tu faccia, non c'è modo di distinguere un essere umano da un robot quando il robot è stato creato su misura da un essere umano per un unico scopo. Il bot è semplicemente un proxy per l'umano.

Conclusione

Alla fine della giornata, non puoi distinguere un essere umano e un computer per guardare la prima pagina. Puoi fermare i robot nella fase di ordinazione, ma gli utenti dei bot hanno ancora un vantaggio sulla prima mossa e hai ancora un carico enorme da gestire.

Puoi aggiungere blocchi per i semplici robot, che aumenteranno il livello e un minor numero di persone con problemi. Questo potrebbe essere abbastanza.

Ma senza cambiare il tuo modello base, sei sfortunato. Il meglio che puoi fare è occuparti dei semplici casi, rendere il server così veloce che gli utenti regolari non notano e vendere così tanti articoli che, anche se hai pochi milioni di bot, tutti gli utenti regolari che li vogliono li otterranno .

Potresti considerare di configurare un honeypot e di contrassegnare gli account utente come utenti bot, ma ciò avrà un enorme contraccolpo di comunità negativo.

Ogni volta che penso a un "beh, che ne dici di fare questo ..." posso sempre contrastarlo con un'adeguata strategia bot.

Anche se rendi la pagina iniziale un captcha per arrivare alla pagina di ordinazione ("Il pulsante di ordinazione di questo articolo è blu con scintillii rosa, da qualche parte in questa pagina") i robot apriranno semplicemente tutti i collegamenti sulla pagina e utilizzeranno qualunque verrà indietro con una pagina di ordinazione. Non è proprio il modo di vincere.

Rendi veloci i server, inserisci un reCaptcha (l'unico che ho trovato che non può essere facilmente ingannato, ma probabilmente è troppo lento per la tua applicazione) nella pagina degli ordini e pensa a come modificare leggermente il modello gli utenti regolari hanno le stesse possibilità degli utenti bot.

-Adamo

Disclaimer: questa risposta è completamente non legata alla programmazione. Tuttavia, cerca di attaccare il motivo degli script in primo luogo.

Un'altra idea è se hai davvero una quantità limitata da vendere, perché non la cambi da una metodologia di primo arrivato? A meno che, ovviamente, l'hype sia parte del tuo schema di marketing.

Ci sono molte altre opzioni e sono sicuro che altri possano pensare ad alcune diverse:

• una coda di ordinazione (sistema di pre-ordine): alcuni script potrebbero comunque finire nella parte anteriore della coda, ma probabilmente è più veloce inserire semplicemente le informazioni.

• un sistema di lotteria (tutti coloro che cercano di ordinarne uno vengono inseriti nel sistema) - In questo modo le persone con gli script hanno le stesse possibilità di quelle senza.

• una coda prioritaria - Se c'è davvero un alto valore percepito, le persone potrebbero essere disposte a pagare di più. Implementa una coda di ordinazione, ma consenti alle persone di pagare di più per essere posizionate più in alto nella coda.

• asta (il merito va a David Schmitt per questo, i commenti sono miei) - Le persone possono ancora usare gli script per accedere all'ultimo minuto, ma non solo cambia la struttura dei prezzi, ma si aspettano che lo stiano combattendo con gli altri . Puoi anche fare qualcosa per limitare il numero di offerte in un determinato periodo di tempo, fare in modo che le persone telefonino in anticipo per un codice di autorizzazione, ecc.

Non importa quanto i nazisti pensassero sicuri delle loro comunicazioni, gli alleati spesso rompevano i loro messaggi. Indipendentemente dal modo in cui si tenta di impedire ai bot di utilizzare il proprio sito, i proprietari dei bot si adopereranno per aggirarlo. Mi dispiace se questo ti rende il nazista :-)

Penso che sia necessaria una mentalità diversa

• Non tentare di impedire ai bot di utilizzare il tuo sito
• Non cercare una soluzione che funzioni immediatamente, gioca con il gioco lungo

Pensa che non importa se il cliente del tuo sito è un essere umano o un bot, entrambi pagano solo clienti; ma uno ha un vantaggio sleale rispetto all'altro. Alcuni utenti senza molta vita sociale (eremiti) possono essere altrettanto fastidiosi per gli altri utenti del tuo sito come i robot.

Registra l'ora in cui pubblichi un'offerta e l'ora in cui un account decide di acquistarla.

Questo ti dà una registrazione di quanto velocemente il cliente sta acquistando roba.

Varia l'ora del giorno in cui pubblichi le offerte.

Ad esempio, avere una finestra di 3 ore a partire da qualche ora oscura del giorno (mezzanotte?) Solo i robot e gli eremiti aggiorneranno costantemente una pagina per 3 ore solo per ottenere un ordine in pochi secondi. Non variare mai il tempo di base, solo le dimensioni della finestra.

Nel tempo emergerà un'immagine.

01: puoi vedere quali account acquistano regolarmente prodotti in pochi secondi dal momento in cui vengono pubblicati. Suggerendo che potrebbero essere dei robot.

02: Puoi anche guardare la finestra del tempo usata per le offerte, se la finestra è di 1 ora, alcuni dei primi acquirenti saranno umani. Tuttavia, un essere umano raramente si aggiorna per 4 ore. Se il tempo trascorso è abbastanza coerente tra pubblicazione / acquisto indipendentemente dalla durata della finestra, si tratta di un bot. Se il tempo di pubblicazione / acquisto è breve per finestre piccole e aumenta per finestre grandi, è un eremita!

Ora, invece di impedire ai bot di utilizzare il tuo sito, hai abbastanza informazioni per dirti quali account sono sicuramente utilizzati dai bot e quali account saranno probabilmente utilizzati dagli eremiti. Quello che fai con queste informazioni dipende da te, ma puoi certamente usarlo per rendere il tuo sito più giusto per le persone che hanno una vita.

Penso che vietare gli account dei bot sarebbe inutile, sarebbe come telefonare a Hitler e dire "Grazie per le posizioni delle tue U-boat!" In qualche modo è necessario utilizzare le informazioni in un modo che i proprietari dell'account non realizzeranno. Vediamo se riesco a sognare qualcosa .....

Elaborare gli ordini in una coda:

Quando il cliente effettua un ordine, riceve immediatamente un'e-mail di conferma in cui informa che il suo ordine è stato inserito in una coda e verrà avvisato al momento dell'elaborazione. Provo questo genere di cose con l'ordine / la spedizione su Amazon e non mi disturba affatto, non mi dispiace ricevere un'e-mail giorni dopo che mi dice che il mio ordine è stato spedito fintanto che ricevo immediatamente un'e-mail che mi dice che Amazon sa che voglio il libro. Nel tuo caso sarebbe una e-mail per

1. Il tuo ordine è stato effettuato ed è in coda.
2. Il tuo ordine è stato elaborato.
3. I tuoi ordini sono stati spediti.

Gli utenti pensano di essere in una coda equa. Elabora la coda ogni 1 ora in modo che anche gli utenti normali possano sperimentare una coda, in modo da non destare sospetti. Elaborare gli ordini da account bot ed eremiti solo dopo che sono stati in coda per il "tempo medio di ordinazione umano + x ore". Ridurre efficacemente i robot per l'uomo.

Dico esporre le informazioni sui prezzi utilizzando un'API. Questa è la soluzione non intuitiva ma funziona per darti il ​​controllo della situazione. Aggiungi alcune limitazioni all'API per renderlo leggermente meno funzionale rispetto al sito Web.

Puoi fare lo stesso per l'ordinazione. Potresti sperimentare piccole modifiche alla funzionalità / prestazioni dell'API fino a ottenere l'effetto desiderato.

Esistono proxy e botnet per sconfiggere i controlli IP. Ci sono script di lettura captcha che sono estremamente buoni. Ci sono persino squadre di lavoratori in India che sconfiggono i captcha a un piccolo prezzo. Qualsiasi soluzione che puoi trovare può essere ragionevolmente sconfitta. Anche le soluzioni di Ned Batchelder possono essere superate utilizzando un controllo WebBrowser o un altro browser simulato combinato con un elenco di botnet o proxy.

Per fare ciò stiamo attualmente utilizzando i bilanciatori di carico BigIP di ultima generazione di F5. Il BigIP ha funzionalità avanzate di gestione del traffico in grado di identificare raschiatori e robot in base alla frequenza e ai modelli di utilizzo anche tra una serie di fonti dietro un singolo IP. Può quindi limitarli, offrire loro contenuti alternativi o semplicemente taggarli con intestazioni o cookie in modo da poterli identificare nel codice dell'applicazione.

Prima di tutto, lasciami riassumere ciò che dobbiamo fare qui. Mi rendo conto che sto solo parafrasando la domanda originale, ma è importante ottenere questo risultato al 100%, perché ci sono molti ottimi suggerimenti che danno 2 o 3 su 4 giusti, ma come dimostrerò, avrai bisogno di un approccio poliedrico per soddisfare tutti i requisiti.

Requisito 1: sbarazzarsi del "bot slamming":

Lo "sbattere" rapido della tua prima pagina sta danneggiando le prestazioni del tuo sito ed è al centro del problema. Lo 'slamming' proviene da entrambi i bot a singolo IP e - presumibilmente - anche dalle botnet. Vogliamo sbarazzarci di entrambi.

Requisito 2: non scherzare con l'esperienza dell'utente:

Potremmo risolvere la situazione del bot in modo abbastanza efficace implementando una brutta procedura di verifica come telefonare a un operatore umano, risolvere un gruppo di CAPTCHA o simili, ma sarebbe come costringere ogni passeggero aereo innocente a saltare attraverso pazzi cerchi di sicurezza solo per la scarsissima possibilità di catturare il più stupido dei terroristi. Oh aspetta - lo facciamo davvero. Ma vediamo se possiamo non farlo su woot.com.

Requisito 3: evitare la "corsa agli armamenti":

Come accennato, non vuoi essere coinvolto nella corsa agli armamenti di spambot. Quindi non puoi usare semplici modifiche come campi di forma nascosti o confusi, domande di matematica, ecc., Poiché sono essenzialmente misure di oscurità che possono essere banalmente individuate e aggirate.

Requisito 4: contrastare i robot di "allarme":

Questo potrebbe essere il più difficile dei tuoi requisiti. Anche se siamo in grado di fare un'efficace sfida di verifica umana, i bot potrebbero comunque effettuare il polling della tua prima pagina e avvisare lo script quando c'è una nuova offerta. Vogliamo anche rendere impossibile quei robot. Questa è una versione più forte del primo requisito, poiché non solo i robot non possono emettere richieste di fuoco rapido dannose per le prestazioni, ma non possono nemmeno emettere richieste ripetute sufficienti per inviare un "allarme" allo scripter in tempo per vincere l'offerta.

Ok, quindi vediamo se possiamo soddisfare tutti e quattro i requisiti. Innanzitutto, come ho già detto, nessuna misura farà il trucco. Dovrai combinare un paio di trucchi per raggiungerlo e dovrai ingoiare due fastidi:

1. Sarà richiesto un numero limitato di utenti per saltare attraverso i cerchi
2. Un numero limitato di utenti non sarà in grado di ottenere le offerte speciali

Mi rendo conto che sono fastidiosi, ma se riusciamo a rendere il numero "piccolo" abbastanza piccolo , spero che concorderai che gli aspetti positivi superano quelli negativi.

Prima misura: limitazione basata sull'utente:

Questo è un gioco da ragazzi, e sono sicuro che lo fai già. Se un utente ha effettuato l'accesso e continua ad aggiornare 600 volte al secondo (o qualcosa del genere), smetti di rispondere e gli dici di raffreddarlo. In effetti, probabilmente rallenti le sue richieste in modo significativo prima di quello, ma ti viene l'idea. In questo modo, un bot connesso verrà bannato / limitato non appena inizierà il polling del tuo sito. Questa è la parte facile. I robot non autenticati sono il nostro vero problema, quindi per loro:

Seconda misura: qualche forma di limitazione dell'IP, come suggerito da quasi tutti:

Indipendentemente da ciò, dovrai fare un po 'di throttling basato su IP per contrastare il "bot slamming". Poiché sembra importante per voi per permettere ai visitatori non autenticato (non loggato) per ottenere le offerte speciali, hai solo IP per andare inizialmente, e anche se non sono perfetti, fare il lavoro contro i bot single-IP. Le botnet sono una bestia diversa, ma tornerò a quelle. Per ora, faremo qualche semplice limitazione per battere i bot single-IP a fuoco rapido.

Il risultato è trascurabile se si esegue il controllo IP prima di ogni altra elaborazione, si utilizza un server proxy per la logica di limitazione e si memorizzano gli IP in una struttura ad albero ottimizzata per la ricerca memcached.

Terza misura: occultare l'acceleratore con le risposte memorizzate nella cache:

Con i bot a IP singolo a fuoco rapido limitati, dobbiamo ancora affrontare i bot a IP singolo lento, vale a dire. i robot che sono specificamente modificati per "volare sotto il radar" spaziando le richieste leggermente più distanti rispetto a quanto impedisce la limitazione.

Per rendere istantaneamente inutili i bot lenti a IP singolo, è sufficiente utilizzare la strategia suggerita da abelenky: servire pagine memorizzate nella cache di 10 minuti a tutti gli IP rilevati nelle ultime 24 ore (circa). In questo modo, ogni IP ottiene una "possibilità" al giorno / ora / settimana (a seconda del periodo scelto) e non ci saranno fastidi visibili agli utenti reali che stanno solo colpendo "ricarica", tranne per il fatto che non vincono l'offerta.

Il bello di questa misura è che sono anche i "robot di allarme", purché non provengano da una botnet.

(So ​​che probabilmente lo preferiresti se agli utenti reali fosse consentito di aggiornare più e più volte, ma non c'è modo di distinguere un umano di aggiornamento spam da un bot di richiesta di spam senza CAPTCHA o simili)

Quarta misura: reCAPTCHA:

Hai ragione sul fatto che i CAPTCHA danneggiano l'esperienza dell'utente e dovrebbero essere evitati. Tuttavia, in una sola situazione possono essere i tuoi migliori amici: se hai progettato un sistema molto restrittivo per contrastare i robot, questo - a causa della sua limitatezza - cattura anche un numero di falsi positivi; quindi un CAPTCHA servito come ultima risorsa consentirà a quegli utenti reali che vengono catturati dalla tua limitazione (evitando così fastidiose situazioni DoS).

Il punto debole, ovviamente, è quando TUTTI i robot vengono catturati nella tua rete, mentre estremamente pochi utenti reali vengono infastiditi dal CAPTCHA.

Se tu, quando offri le pagine memorizzate nella cache di 10 minuti, offri anche un "aggiornamento della pagina iniziale" alternativo, facoltativo , verificato da CAPTCHA, gli umani che vogliono davvero continuare a rinfrescarsi, puoi comunque farlo senza ottenere la vecchia pagina memorizzata nella cache , ma a costo di dover risolvere un CAPTCHA per ogni aggiornamento. Questo è un fastidio, ma facoltativo solo per gli utenti irriducibili, che tendono a perdonare di più perché sanno che stanno giocando il sistema per migliorare le loro possibilità e che le migliori possibilità non sono gratuite.

Quinta misura: schifo di esca:

Christopher Mahan ha avuto un'idea che mi piaceva piuttosto, ma ci avrei messo un altro giro. Ogni volta che stai preparando una nuova offerta, prepara anche altre due "offerte", che nessun essere umano sceglierebbe, come un galletto da 12 mm per $ 20. Quando l'offerta appare sulla prima pagina, inserisci tutte e tre le "offerte" nella stessa immagine, con i numeri corrispondenti a ciascuna offerta. Quando l'utente / bot effettivamente procede per ordinare l'oggetto, dovrà scegliere (un pulsante di opzione) quale offerta desidera e, dal momento che la maggior parte dei robot si limiterebbe a indovinare, in due casi su tre, i robot acquisterebbero inutili Rifiuto.

Naturalmente, questo non riguarda i "robot di allarme", e c'è una (sottile) possibilità che qualcuno possa costruire un bot in grado di scegliere l'oggetto corretto. Tuttavia, il rischio di acquistare accidentalmente spazzatura dovrebbe far girare completamente gli scripter dai robot completamente automatizzati.

Sesta misura: Botnet Throttling:

[Soppresso]

Okay ............ Ora ho trascorso gran parte della mia serata a pensarci, provando approcci diversi ... ritardi globali .... token basati su cookie ... servizio in coda ... 'Stranger throttling' .... E semplicemente non funziona. Non Ho capito che il motivo principale per cui non avevi ancora accettato una risposta era che nessuno aveva proposto un modo per contrastare un attacco distribuito / zombie net / botnet .... quindi volevo davvero risolverlo. Credo di aver risolto il problema della botnet per l'autenticazione in un thread diverso , quindi avevo anche grandi speranze per il tuo problema. Ma il mio approccio non si traduce in questo. Hai solo IP da percorrere e una botnet abbastanza grande non si rivela in nessuna analisi basata su indirizzi IP.

Quindi il gioco è fatto : la mia sesta misura è nulla. Niente. Cerniera lampo. A meno che la botnet non sia piccola e / o abbastanza veloce da rimanere intrappolata nella consueta accelerazione IP, non vedo alcuna misura efficace contro le botnet che non implichi una verifica umana esplicita come i CAPTHA. Mi dispiace, ma penso che combinare le cinque misure di cui sopra sia la soluzione migliore. E probabilmente potresti fare benissimo solo con il trucco della cache di 10 minuti di abelenky da solo.

Che ne dici di introdurre un ritardo che richiede l'interazione umana, come una sorta di "gioco CAPTCHA". Ad esempio, potrebbe essere un piccolo gioco Flash in cui per 30 secondi devono far scoppiare le palle a scacchi ed evitare di far scoppiare palle solide (evitando problemi di daltonismo!). Al gioco verrebbe assegnato un seme di numero casuale e ciò che il gioco trasmette al server sarebbero le coordinate e i timestamp dei punti cliccati, insieme al seme usato.

Sul server simuli le meccaniche di gioco usando quel seme per vedere se i clic avrebbero effettivamente fatto scoppiare le palle. Se lo facessero, non solo erano umani, ma impiegavano 30 secondi per convalidare se stessi. Dai loro un ID di sessione.

Lascia che l'id della sessione faccia quello che gli piace, ma se fa troppe richieste, non possono continuare senza giocare di nuovo.

Ci sono alcune altre / migliori soluzioni già pubblicate, ma per completezza, ho pensato di menzionarlo:

Se la tua preoccupazione principale è il degrado delle prestazioni e stai osservando il vero martellamento , allora stai effettivamente affrontando un attacco DoS e probabilmente dovresti provare a gestirlo di conseguenza. Un approccio comune è semplicemente quello di eliminare i pacchetti da un IP nel firewall dopo un numero di connessioni al secondo / minuto / ecc. Ad esempio, il firewall Linux standard, iptables, ha una funzione di corrispondenza delle operazioni standard 'hashlimit', che potrebbe essere utilizzata per correlare le richieste di connessione per unità di tempo a un indirizzo IP.

Sebbene, questa domanda sarebbe probabilmente più adatta per il prossimo derivato SO menzionato nell'ultimo podcast SO, non è ancora stato lanciato, quindi credo che sia giusto rispondere :)

EDIT:
Come sottolineato da Novatrust, in realtà ci sono ancora ISP che NON assegnano IP ai propri clienti, così efficacemente un cliente script di un tale ISP disabiliterebbe tutti i clienti da quell'ISP.

Scrivi un proxy inverso su un server Apache di fronte alla tua applicazione che implementa un Tarpit (Articolo di Wikipedia) per punire i robot. Gestirebbe semplicemente un elenco di indirizzi IP collegati negli ultimi secondi. Rileva un'esplosione di richieste da un singolo indirizzo IP e ritarda esponenzialmente tali richieste prima di rispondere.

Certo, più umani possono provenire dallo stesso indirizzo IP se si trovano su una connessione di rete NAT ma è improbabile che un umano si preoccupi del tempo di risposta andando da 2mS a 4mS (o anche 400mS) mentre un bot sarà ostacolato dal ritardo crescente piuttosto rapidamente.

1. Fornisci un feed RSS in modo che non consumino la tua larghezza di banda.
2. Al momento dell'acquisto, fai aspettare a tutti un tempo casuale fino a 45 secondi o qualcosa del genere, a seconda di cosa stai cercando esattamente. Quali sono esattamente i tuoi vincoli temporali?
3. Dare a tutti 1 minuto per inserire il proprio nome per il disegno e quindi selezionare casualmente le persone. Penso che questo sia il modo più giusto.
4. Monitorare gli account (includere alcune volte nella sessione e archiviarlo?) E aggiungere ritardi agli account che sembrano essere al di sotto della soglia di velocità umana. Ciò renderà almeno i robot programmati per rallentare e competere con gli umani.

Prima di tutto, per definizione, è impossibile supportare transazioni senza stato, cioè veramente anonime, pur essendo in grado di separare i robot dagli utenti legittimi.

Se possiamo accettare una premessa che possiamo imporre dei costi a un visitatore di woot nuovo di zecca sulle sue hit della prima pagina, penso di avere una possibile soluzione. Per mancanza di un nome migliore, chiamerò vagamente questa soluzione "Una visita al DMV".

Supponiamo che ci sia un concessionario di automobili che offre una nuova auto diversa ogni giorno e che in alcuni giorni è possibile acquistare un'auto sportiva esotica per $ 5 ciascuno (limite 3), più una tassa di destinazione di $ 5.

Il problema è che la concessionaria richiede di visitare la concessionaria e mostrare una patente di guida valida prima che ti sia permesso entrare dalla porta per vedere quale auto è in vendita. Inoltre, per poter effettuare l'acquisto è necessario aver dichiarato la patente di guida valida.

Quindi, al visitatore per la prima volta (chiamiamolo Bob) a questo concessionario viene rifiutato l'ingresso e viene inviato all'ufficio DMV (che si trova proprio accanto) per ottenere la patente di guida.

Altri visitatori con una patente di guida valida sono ammessi dopo aver mostrato la patente di guida. Una persona che si infastidisce da solo bighellonando tutto il giorno, infastidendo i venditori, afferrando opuscoli e svuotando il caffè e i biscotti gratuiti verrà infine respinta.

Ora, tornando a Bob senza la licenza, tutto ciò che deve fare è sopportare una volta la visita al DMV. Successivamente, può visitare il concessionario e acquistare auto ogni volta che lo desidera, a meno che non abbia accidentalmente lasciato il portafoglio a casa o che la sua licenza venga distrutta o revocata in altro modo.

La patente di guida in questo mondo è quasi impossibile da forgiare.

La visita al DMV implica innanzitutto ottenere il modulo di domanda nella coda "Inizia qui". Bob deve portare la domanda completa alla finestra n. 1, dove il primo di molti funzionari scontrosi prenderà la sua domanda, la elaborerà e, se tutto è in ordine, timbrerà la domanda per la finestra e lo manderà alla finestra successiva. E così, Bob passa da una finestra all'altra, aspettando che ogni fase della sua applicazione passi, fino a quando non arriva alla fine e riceve la licenza di Drivere.

Non ha senso cercare di "cortocircuitare" il DMV. Se i moduli non vengono compilati correttamente in triplice copia o se vengono fornite risposte errate in qualsiasi finestra, la domanda viene strappata e il cliente sfortunato viene rinviato all'inizio.

È interessante notare che, non importa quanto sia pieno o vuoto l'ufficio, ci vuole circa la stessa quantità di tempo per ottenere assistenza in ogni finestra successiva. Anche quando sei l'unica persona in fila, sembra che al personale piaccia farti aspettare un minuto dietro la linea gialla prima di pronunciare "Avanti!"

Le cose non sono così terribili al DMV, tuttavia. Mentre tutta l'attesa e l'elaborazione per ottenere la licenza sono in corso, puoi guardare un infomercial molto divertente e informativo per il concessionario auto mentre sei nella hall DMV. In effetti, l'infomerical funziona abbastanza a lungo da coprire il tempo che impieghi a ottenere la tua licenza.

La spiegazione leggermente più tecnica:

Come ho detto all'inizio, diventa necessario avere un po 'di stato sulla relazione client-server che consente di separare gli umani dai robot. Vuoi farlo in un modo che non penalizzi eccessivamente il visitatore umano anonimo (non autenticato).

Questo approccio probabilmente richiede un'elaborazione lato client AJAX-y. A un nuovo visitatore sculacciato da fare il woot viene dato il "Benvenuto nuovo utente!" pagina piena di testo e grafica che (mediante un'appropriata limitazione lato server) impiega alcuni secondi per caricarsi completamente. Mentre ciò accade (e presumibilmente il visitatore è impegnato a leggere le pagine di benvenuto), il suo token identificativo viene lentamente assemblato.

Diciamo, per discussione, il token (noto anche come "patente di guida") è composto da 20 blocchi. Per ottenere ogni blocco successivo, il codice lato client deve inviare una richiesta valida al server. Il server incorpora un ritardo deliberato (diciamo 200 millisecondi), prima di inviare il blocco successivo insieme al 'timbro' necessario per effettuare la richiesta di blocco successivo (ovvero, i francobolli devono passare da una finestra DMV alla successiva). Tutto sommato, devono trascorrere circa 4 secondi per finire il chunk-challenge-response-chunk-challenge-response -...- processo di completamento chunk-challenge-response-completamento.

Al termine di questo processo, il visitatore ha un token che gli consente di accedere alla pagina di descrizione del prodotto e, a sua volta, alla pagina di acquisto. Il token è un ID univoco per ogni visitatore e può essere utilizzato per limitare le sue attività.

Sul lato server, si accettano solo visualizzazioni di pagina da client che dispongono di un token valido. Oppure, se è importante che alla fine tutti possano vedere la pagina, applica una penalità di tempo alle richieste in cui manca un token valido.

Ora, affinché questo sia relativamente benigno al legittimo visitatore umano, fai in modo che il processo di emissione dei token avvenga in modo relativamente non intrusivo in background. Da qui la necessità di una pagina di benvenuto con una copia e una grafica divertenti che vengono deliberatamente rallentate leggermente.

Questo approccio impone una riduzione dei bot per utilizzare un token esistente o impiegare il tempo minimo di configurazione per ottenere un nuovo token. Naturalmente, questo non aiuta tanto contro gli attacchi sofisticati che utilizzano una rete distribuita di visitatori falsi.

Non puoi prevenire totalmente i robot, anche con un captcha. Tuttavia, è difficile scrivere e mantenere un bot e quindi ridurre il numero. Soprattutto costringendoli ad aggiornare i loro bot ogni giorno, causerai la maggior parte degli interessi.

Ecco alcune idee per rendere più difficile la scrittura di robot:

• Richiede l'esecuzione di una funzione JavaScript. Javascript rende molto più difficile scrivere un bot. Forse è necessario un captcha se non eseguono javascript per consentire comunque agli utenti reali non javascript (minimo).

• Tempo i tasti premuti quando si digita nel modulo (di nuovo via javascript). Se non è umano, allora respingilo. È un dolore imitare la tipizzazione umana in un bot.

• Scrivi il tuo codice per aggiornare quotidianamente l'ID del tuo campo con un nuovo valore casuale. Questo li costringerà ad aggiornare quotidianamente il loro bot, il che è una seccatura.

• Scrivi il tuo codice per riordinare i tuoi campi su base giornaliera (ovviamente in qualche modo non è casuale per i tuoi utenti). Se si basano sull'ordine dei campi, questo li farà inciampare e forzerà nuovamente la manutenzione giornaliera sul loro codice bot.

• Potresti andare oltre e utilizzare il contenuto Flash. Flash è totalmente un dolore contro cui scrivere un bot.

Generalmente se inizi a pensare di non prevenirli, ma di renderli più efficaci per loro, probabilmente puoi raggiungere l'obiettivo che stai cercando.

Attendi un ritardo di 5 minuti su tutti gli annunci di prodotti per utenti non registrati. Gli utenti occasionali non se ne accorgeranno davvero e gli utenti non casuali verranno comunque registrati.

Non vedo il grande onere che pretendi dal controllo degli IP in arrivo. Al contrario, ho realizzato un progetto per uno dei miei clienti che analizza i registri di accesso HTTP ogni cinque minuti (avrebbe potuto essere in tempo reale, ma non lo voleva per qualche motivo che non avevo mai compreso appieno) e crea regole firewall per bloccare le connessioni da qualsiasi indirizzo IP che generi un numero eccessivo di richieste a meno che l'indirizzo non possa essere confermato come appartenente a un motore di ricerca legittimo (google, yahoo, ecc.).

Questo client esegue un servizio di web hosting ed esegue questa applicazione su tre server che gestiscono un totale di 800-900 domini. L'attività di picco è nell'intervallo di migliaia di hit al secondo e non c'è mai stato un problema di prestazioni: i firewall sono molto efficienti nel far cadere i pacchetti dagli indirizzi nella lista nera.

E sì, la tecnologia DDOS esiste sicuramente per sconfiggere questo schema, ma non vede che ciò accada nel mondo reale. Al contrario, afferma che ha notevolmente ridotto il carico sui suoi server.

Il mio approccio sarebbe quello di concentrarmi su soluzioni non tecnologiche (altrimenti stai entrando in una corsa agli armamenti che perderai, o almeno spenderai molto tempo e denaro). Mi concentrerei sulle parti di fatturazione / spedizione: puoi trovare i robot trovando più consegne allo stesso indirizzo o con più addebiti in un unico metodo di pagamento. Puoi persino farlo su più articoli per diverse settimane, quindi se un utente ha ricevuto un articolo precedente (rispondendo molto velocemente), questa volta gli potrebbe essere assegnato un tipo di "handicap".

Ciò avrebbe anche un effetto collaterale (utile, penso, ma potrei essere sbagliato dal punto di vista del marketing per il tuo caso) forse allargando la cerchia di persone che sono fortunate e possono acquistare woot.

La maggior parte delle soluzioni puramente tecniche sono già state offerte. Suggerirò quindi un'altra visione del problema.

A quanto ho capito, i robot sono creati da persone che cercano sinceramente di acquistare le borse che vendi. Il problema è -

1. Altre persone, che non gestiscono i robot, meritano la possibilità di acquistare e stai offrendo un numero limitato di borse.
2. Vuoi attirare esseri umani sul tuo sito e semplicemente vendere le borse.

Invece di cercare di evitare i robot, puoi consentire ai potenziali acquirenti di borse di iscriversi a un'e-mail, o anche ad un aggiornamento SMS, per ricevere una notifica quando si svolgerà una vendita. Puoi anche dare loro un minuto o due di vantaggio (un URL speciale in cui inizia la vendita, generato casualmente e inviato con la posta / SMS).

Quando questi acquirenti vanno a comprare sono nel tuo sito, puoi mostrare loro quello che vuoi nei banner laterali o qualunque cosa. Coloro che eseguono i robot preferiranno semplicemente registrarsi al servizio di notifica.

I corridori di robot potrebbero comunque eseguire robot sulla tua notifica per completare l'acquisto più velocemente. Alcune soluzioni possono offrire un acquisto con un clic.

A proposito, hai detto che i tuoi utenti non sono registrati, ma sembra che quelli che acquistano queste borse non siano acquirenti casuali, ma persone che non vedono l'ora di fare queste vendite. Pertanto, potrebbero essere disposti a registrarsi per ottenere un vantaggio nel tentativo di "vincere" una borsa.

In sostanza, ciò che sto suggerendo è cercare di considerare il problema come un problema sociale, piuttosto che tecnico.

Asaf

Agenti utente a tempo che fanno così tante richieste al minuto. Ad esempio, se hai qualcuno che richiede una pagina esattamente ogni 5 secondi per 10 minuti, probabilmente non è un utente ... Ma potrebbe essere complicato farlo bene.

Se attivano un avviso, reindirizza tutte le richieste a una pagina statica con il minor DB-IO possibile con un messaggio che li informa che saranno riaccesi tra X minuti.

È importante aggiungere che probabilmente dovresti applicarlo solo alle richieste di pagine e ignorare tutte le richieste di media (js, immagini, ecc.).

Prevenire DoS avrebbe sconfitto il n. 2 degli obiettivi di @ davebug che ha delineato sopra, "Mantieni il sito a una velocità non rallentata dai robot" ma non sarebbe necessario risolvere il n. 1, "Vendi l'oggetto a umani senza script"

Sono sicuro che uno scripter potrebbe scrivere qualcosa per pattinare appena sotto il limite eccessivo che sarebbe ancora più veloce di quanto un essere umano potrebbe passare attraverso le forme d'ordine.

Va bene, quindi gli spammer sono fuori gente normale in competizione per vincere l'asta "palude di merda"? Perché non fare della prossima asta un letterale "sacco di merda"? Gli spammer pagano buoni soldi per una borsa piena di cagnolini, e tutti ridiamo di loro.

La cosa importante qui è cambiare il sistema per rimuovere il carico dal tuo server, impedire ai robot di vincere il sacco di merda SENZA far sapere ai botlords che stai giocando o che rivedranno la loro strategia. Non credo che ci sia modo di farlo senza qualche elaborazione da parte tua.

Quindi registra i risultati sulla tua home page. Ogni volta che qualcuno accede alla pagina, tale connessione viene confrontata con l'ultima hit e, se è stata troppo rapida, viene inviata una versione della pagina senza l'offerta. Questo può essere fatto da una sorta di meccanismo di bilanciamento del carico che invia bot (gli hit che sono troppo veloci) a un server che serve semplicemente le versioni cache della tua home page; le persone vere vengono inviate al buon server. Ciò toglie il carico dal server principale e fa pensare ai bot che le pagine vengano ancora servite correttamente.

Ancora meglio se l'offerta può essere rifiutata in qualche modo. Quindi puoi ancora fare le offerte sul server falso ma quando il bot compila il modulo dire "Mi dispiace, non sei stato abbastanza veloce" :) Quindi penseranno sicuramente di essere ancora in gioco.

Come fai a sapere che ci sono degli scripter che effettuano ordini?

Il punto cruciale del tuo problema è che non puoi separare gli script dagli utenti legittimi e quindi non puoi bloccarli, quindi come fai a sapere che ci sono script?

Se hai un modo per rispondere a questa domanda, allora hai una serie di caratteristiche che puoi usare per filtrare gli script.

Capovolgiamo il problema: hai robot che comprano cose che vuoi che le persone vere comprino, che ne dici di fare una vera possibilità che i robot comprino cose che non vuoi che le persone vere comprino.

Avere una possibilità casuale per alcuni html non visualizzati che i robot di scraping penseranno che sia la situazione reale, ma le persone reali non vedranno (e non dimenticare che le persone reali includono i non vedenti, quindi considera anche gli screen reader ecc.) E questo passa attraverso l'acquisto di qualcosa di esorbitantemente costoso (o non effettua l'acquisto effettivo, ma ottiene i dettagli di pagamento da inserire in una lista).

Anche se i robot passano a "avvisare l'utente" anziché "effettuare l'acquisto", se riesci a ottenere abbastanza falsi allarmi, potresti essere in grado di renderlo sufficientemente inutile per le persone (forse non tutti, ma una certa riduzione delle truffe è meglio di niente) a non disturbare.