Come impedire agli utenti di scaricare informazioni dal nostro motore di ricerca?

2

Abbiamo sviluppato un motore di ricerca (semplice ricerca, nessun accesso richiesto) in cui gli utenti possono cercare i dettagli nel database ( Apache Lucene ) inserendo il loro nome (et al.), quindi facendo clic sul pulsante di ricerca. La ricerca richiama una richiesta HTTP GET asincrona (una chiamata AJAX sullo stesso dominio) al server che a sua volta chiama il motore di ricerca. La risposta è un oggetto JSON.

Ho disabilitato la politica "Permetti accesso incrociato" sul server. Sembra che un utente malintenzionato picchi continuamente sul server di ricerca per scaricare i dati. Lo sappiamo perché il numero di accessi sul server di ricerca è molto più grande di quello mostrato da Google Analytics per la pagina indice.

Altri sviluppatori hanno suggerito quanto segue:

  1. Crea una sessione per la ricerca.
  2. Inserisci captcha nella pagina dell'indice e verificalo sul server.
  3. Suggeriscono che qualcuno possa ancora programmare le richieste GET con parametri e quindi eseguire una ricerca, spiegata dall'enorme differenza tra le visite alle pagine e le visite alla pagina dell'indice.

Questo mi confonde:

  1. Se il captcha è veramente necessario per un'applicazione che recupera solo le informazioni, oltre a peggiorare l'usabilità?
  2. Se ho disabilitato "accesso incrociato" , in che modo qualcuno può richiamare programmaticamente le chiamate sul server?

Ci sono modi migliori per approcciare questo (specialmente il captcha)?

    
posta krammer 15.04.2014 - 09:02
fonte

4 risposte

3

Se l'utente invoca più di x quantità di query per x quantità di tempo che sembra impossibile tramite un essere umano, allora ti consigliamo di generare un captcha per impedire i bot.

Se l'utente richiama una quantità insignificante di richieste, basta vietare il suo IP per x quantità di tempo poiché è chiaro che stanno usando una qualche forma di botting.

È possibile generare una chiave ogni volta che l'utente esegue una ricerca (questo impedirà i bot di base ma è by-passabile dai robot complessi poiché leggerà la chiave e la inserirà nei parametri). Se mancano la chiave, viene visualizzato un errore.

Quindi, fingiamo di avere Default.aspx e Search.aspx imposterà il set di chiavi nei dati del modulo come campo nascosto. Quindi, l'impostazione predefinita ti indirizzerà a Search.aspx con una chiave. Se vai direttamente a Search.aspx non avrai la chiave in modo da non poter cercare. Una volta premuto il pulsante "Cerca", lo passerà al server e sarà sufficiente convalidare quella chiave. Quindi disponi di campi nascosti come:

<input id="hifKey" type="hidden" runat="server" value="{getfromserver}" />

Questa chiave è valida solo per una ricerca, dopo aver convalidato e utilizzato genera una nuova chiave.

Ciò impedirebbe i bot di base, ma è chiaro che è ancora bypassabile in quanto tutto ciò che devi fare è creare un'applicazione .NET e utilizzare HttpWebRequest e leggere i dati di HttpWebResponse su Default.aspx, quindi ottenere una chiave e poi cercare su Search.aspx e continua a leggere la prossima chiave da <input id="hifKey" type="hidden" runat="server" value="{getfromserver}" />

    
risposta data 15.04.2014 - 10:20
fonte
2

Come ha detto Paul, l'uso di una chiave impedirà ai bot di base di eseguire la scansione del tuo sito Web, ma gli script più avanzati ignoreranno facilmente la situazione. Si noti inoltre che i robot moderni sono in grado di eseguire Javascript come farebbe un utente reale e che include il codice JS di Google Analytics.

Un ragionevole equilibrio in termini di sicurezza rispetto all'esperienza utente, sarebbe configurare le quote e i limiti delle ricerche, come fa Google, e presentare un CAPTCHA solo se questo limite viene superato.

Tieni presente che alcuni sistemi CAPTCHA possono essere risolti automaticamente mediante script utilizzando Riconoscimento ottico dei caratteri , quindi desideri considerare questo quando si sceglie un'implementazione.

    
risposta data 15.04.2014 - 12:06
fonte
0

La disattivazione di Consenti accesso di origine incrociata impedisce solo le richieste HTTP cross-site eseguite da JavaScript da un altro sito Web sul quale sta navigando un utente arbitrario.
I "veri" robot, che non sono limitati all'interno di un ambiente JavaScript, non sono interessati da questa opzione.

Ora devi distinguere tra le richieste avviate dagli utenti e quelle richieste che sono solo false dai bot. Ci sono diverse opzioni per farlo:

  • meccanismi di accesso utente
    Richiedi ai tuoi utenti di avere account dedicati sul tuo sistema. I problemi si verificano se gli account utente vengono rubati o dirottati.

  • chiavi / token come Paolo ha menzionato fonte
    Questo è molto facile da aggirare dato che i robot devono solo riprodurre ciò che gli utenti normali farebbero.

  • quote di utilizzo limitate
    si limita l'accesso alle richieste x entro un intervallo di tempo impostato per uno specifico indirizzo IP. Sfortunatamente, i robot distribuiti con diversi indirizzi IP possono anche superare il limite. Puoi combinare questa idea con l'approccio del sistema utente per risolvere il problema con i robot distribuiti.

risposta data 15.04.2014 - 14:44
fonte
0

We know this because the number of hits on the search server is much larger than the one shown by Google Analytics for the index page.

La tua premessa è difettosa (potrebbe essere corretta, ma è ancora imperfetta). GA mostra solo chi ha collaborato con GA. Se il javascript di un utente è disabilitato (non sembra applicabile nel tuo caso), GA è bloccato ecc. Ecc. La richiesta non verrà visualizzata nelle tue analisi.

È necessario esaminare i registri per attività di tipo bot: sequenze alfanumeriche, parole chiave che è improbabile che gli umani digitino ecc. e quindi limitano l'intervallo IP. Si noti, tuttavia, che qualsiasi gruppo che utilizza un proxy o un processo NAT può facilmente apparire come un bot se tutto ciò che si esamina è la frequenza. Le grandi aziende e gli ISP più piccoli (come i fornitori di VPN) rientreranno in questa categoria.

Puoi anche essere cattivo: invece di bloccare il bot, puoi creare un tarpit (risposte molto lente) o una bomba risultante (piccoli risultati compressi che si espandono a 50Pb).

    
risposta data 15.04.2014 - 15:41
fonte

Leggi altre domande sui tag