Blocca l'accesso degli utenti alle parti interne di un sito utilizzando HTTP_REFERER

Question

Ho il controllo su HttpServer ma non su ApplicationServer o sulle applicazioni Java presenti, ma devo bloccare l'accesso diretto a determinate pagine su tali applicazioni.Precisamente, non voglio che gli utenti automatizzino l'accesso ai moduli emettendo richieste HTTP GET/POST dirette al servlet appropriato.

Quindi, ho deciso di bloccare gli utenti in base al valore di HTTP_REFERER.Dopotutto, se l'utente sta navigando all'interno del sito, avrà un'appropriata HTTP_REFERER.Bene, questo era quello che pensavo.

Ho implementato una regola di riscrittura nel file .htaccess che dice:

RewriteEngine on 

# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteRule (servlet1|servlet2)/.+\?.+ - [F]

Mi aspettavo di vietare l'accesso agli utenti che non navigavano nel sito ma inviavano richieste GET dirette ai servlet "servlet1" o "servlet2" utilizzando querystring.Ma le mie aspettative sono finite bruscamente a causa dell'espressione regolare (servlet1|servlet2)/.+\?.+ non ha funzionato affatto.

Sono rimasto davvero deluso quando ho cambiato quell'espressione in (servlet1|servlet2)/.+ e ha funzionato così bene che i miei utenti sono stati bloccati indipendentemente dal fatto che navigassero o meno nel sito.

Quindi, la mia domanda è:Come posso ottenere questo risultato non consentendo ai "robot" l'accesso diretto a determinate pagine se non ho accesso/privilegi/tempo per modificare l'applicazione?

Answer 1

Non sono sicuro di poter risolvere il problema in una volta sola, ma possiamo andare avanti e indietro se necessario.

Innanzitutto, voglio ripetere quello che penso tu stia dicendo e assicurarmi di essere chiaro.Vuoi non consentire richieste a servlet1 e servlet2 se la richiesta non ha il referer corretto e fa hai una stringa di query?Non sono sicuro di aver capito (servlet1|servlet2)/.+\?.+ perché sembra che tu stia richiedendo un file in servlet1 e 2.Penso che forse stai combinando PATH_INFO (prima del "?") con una stringa di query GET (dopo il "?").Sembra che la parte PATH_INFO funzionerà ma il test della query GET no.Ho effettuato un rapido test sul mio server utilizzando script1.cgi e script2.cgi e le seguenti regole hanno funzionato per ottenere ciò che stai chiedendo.Ovviamente sono leggermente modificati per adattarsi al mio ambiente:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

Quanto sopra ha rilevato tutte le richieste di referer errate a script1.cgi e script2.cgi che hanno tentato di inviare dati utilizzando una stringa di query.Tuttavia, puoi anche inviare dati utilizzando path_info e pubblicando dati.Ho utilizzato questo modulo per proteggermi da uno qualsiasi dei tre metodi utilizzati con referer errato:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

In base all'esempio che stavi cercando di far funzionare, penso che questo sia ciò che desideri:

RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule (servlet1|servlet2)\b - [F]

Spero che questo almeno ti avvicini al tuo obiettivo.Per favore facci sapere come funziona, sono interessato al tuo problema.

(A proposito, sono d'accordo che il blocco dei referer è scarsa sicurezza, ma capisco anche che la realtà impone a volte soluzioni imperfette e parziali, cosa che sembri già riconoscere.)

Answer 2

Non ho una soluzione, ma scommetto che fare affidamento sul referrer non funzionerà mai perché gli user-agent sono liberi di non inviarlo affatto o di falsificarlo a qualcosa che li lascerà entrare.

Answer 3

Non è possibile distinguere gli utenti dagli script dannosi in base alla loro richiesta http.Ma puoi analizzare quali utenti richiedono troppe pagine in un tempo troppo breve e bloccare i loro indirizzi IP.

Answer 4

L'utilizzo di un referrer è molto inaffidabile come metodo di verifica.Come altri hanno già detto, è facilmente falsificabile.La soluzione migliore è modificare l'applicazione (se possibile)

Potresti utilizzare un CAPTCHA o impostare una sorta di cookie o cookie di sessione che tenga traccia dell'ultima pagina visitata dall'utente (una sessione sarebbe più difficile da falsificare) e tenga traccia della cronologia delle visualizzazioni della pagina e consenta solo agli utenti che hanno esplorato il pagine necessarie per raggiungere la pagina che desideri bloccare.

Ciò ovviamente richiede che tu abbia accesso all'applicazione in questione, tuttavia è il modo più infallibile (non del tutto, ma "abbastanza buono" secondo me).

Answer 5

Javascript è un altro strumento utile per prevenire (o almeno ritardare) lo scraping dello schermo.La maggior parte degli strumenti di scraping automatizzati non dispone di un interprete Javascript, quindi puoi fare cose come impostare campi nascosti, ecc.

Modificare:Qualcosa sulla falsariga di questo articolo di Phil Haack.

Answer 6

Immagino che tu stia cercando di evitare lo scraping dello schermo?

A mio parere onesto è difficile da risolvere e provare a risolverlo controllando il valore di HTTP_REFERER è solo un cerotto.Chiunque si prenda la briga di automatizzare gli invii sarà abbastanza esperto da inviare il referer corretto dal proprio "automa".

Potresti provare la limitazione della velocità, ma senza effettivamente modificare l'app per forzare una sorta di convalida è-questo-umano (un CAPTCHA) ad un certo punto, troverai difficile prevenirlo.

Answer 7

Se stai cercando di impedire ai bot dei motori di ricerca di accedere a determinate pagine, assicurati di utilizzare un file formattato correttamente robots.txt file.

L'uso di HTTP_REFERER non è affidabile perché lo è facilmente falsificabile.

Un'altra opzione è controllare la stringa dell'agente utente per i bot conosciuti (questo potrebbe richiedere la modifica del codice).

Answer 8

Per rendere le cose un po' più chiare:

1. Sì, lo so che usare HTTP_REFERER è del tutto inaffidabile e un po' infantile ma sono abbastanza sicuro che le persone che hanno imparato (da me forse?) a fare automazioni con Excel VBA non sapranno come sovvertire un HTTP_REFERER nell'arco di tempo per avere la soluzione finale.

2. Non ho accesso/privilegio per modificare il codice dell'applicazione.Politica.Credi che?Quindi devo aspettare che il titolare dei diritti apporti le modifiche da me richieste.

3. Dalle esperienze precedenti, so che le modifiche richieste richiederanno due mesi per entrare in produzione.No, buttargli in testa i libri sulle Metodologie Agili non ha migliorato nulla.

4. Questa è un'app intranet.Quindi non ci sono molti giovani che cercano di minare il mio prestigio.Ma sono abbastanza giovane da provare a minare il prestigio di "un servizio di consulenza globale molto sofisticato che viene dall'India" ma dove, curiosamente, non c'è un solo indiano che lavora lì.

Finora, la risposta migliore viene da "Michel de Mare":bloccare gli utenti in base ai loro IP.Bene, l'ho fatto ieri.Oggi volevo fare qualcosa di più generico perché ho molti utenti canguro (saltando da un indirizzo Ip all'altro) perché usano VPN o DHCP.

Answer 9

Potresti essere in grado di utilizzare un token anti-CSRF per ottenere ciò che stai cercando.

Questo articolo lo spiega in modo più dettagliato: Falsificazioni di richieste intersito