Bloquear el acceso de los usuarios a las partes internas de un sitio usando HTTP_REFERER

Question

Tengo control sobre HttpServer pero no sobre ApplicationServer o las aplicaciones Java que se encuentran allí, pero necesito bloquear el acceso directo a ciertas páginas de esas aplicaciones.Precisamente, no quiero que los usuarios automaticen el acceso a formularios emitiendo solicitudes HTTP GET/POST directas al servlet apropiado.

Entonces, decidí bloquear usuarios según el valor de HTTP_REFERER.Después de todo, si el usuario navega dentro del sitio, tendrá una adecuada HTTP_REFERER.Bueno, eso fue lo que pensé.

Implementé una regla de reescritura en el archivo .htaccess que dice:

RewriteEngine on 

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

Esperaba prohibir el acceso a los usuarios que no navegaron por el sitio pero emitieron solicitudes GET directas a los servlets "servlet1" o "servlet2" utilizando cadenas de consulta.Pero mis expectativas terminaron abruptamente porque la expresión regular (servlet1|servlet2)/.+\?.+ no funcionó en absoluto.

Me decepcioné mucho cuando cambié esa expresión a (servlet1|servlet2)/.+ y funcionó tan bien que mis usuarios fueron bloqueados sin importar si navegaban por el sitio o no.

Entonces, mi pregunta es:¿Cómo puedo lograr esto de no permitir "robots" con acceso directo a ciertas páginas si no tengo acceso/privilegios/tiempo para modificar la aplicación?

Answer 1

No estoy seguro de poder resolver esto de una sola vez, pero podemos avanzar y retroceder según sea necesario.

Primero, quiero repetir lo que creo que estás diciendo y asegurarme de que quede claro.Desea rechazar solicitudes a servlet1 y servlet2 si la solicitud no tiene el referente adecuado y hace ¿Tiene una cadena de consulta?No estoy seguro de entender (servlet1|servlet2)/.+\?.+ porque parece que necesita un archivo en servlet1 y 2.Creo que tal vez esté combinando PATH_INFO (antes de "?") con una cadena de consulta GET (después de "?").Parece que la parte PATH_INFO funcionará pero la prueba de consulta GET no.Hice una prueba rápida en mi servidor usando script1.cgi y script2.cgi y las siguientes reglas funcionaron para lograr lo que me pedías.Obviamente están un poco editados para que coincidan con mi entorno:

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

Lo anterior detectó todas las solicitudes de referencia incorrecta a script1.cgi y script2.cgi que intentaron enviar datos mediante una cadena de consulta.Sin embargo, también puede enviar datos utilizando path_info y publicando datos.Utilicé este formulario para protegerme contra cualquiera de los tres métodos utilizados con un referente incorrecto:

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]

Según el ejemplo que intentabas hacer funcionar, creo que esto es lo que quieres:

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

Esperemos que esto al menos te acerque a tu objetivo.Háganos saber cómo funciona, estoy interesado en su problema.

(Por cierto, estoy de acuerdo en que el bloqueo de referencias es una seguridad deficiente, pero también entiendo que la relaidad obliga a veces a soluciones imperfectas y parciales, lo que parece que usted ya reconoce).

Answer 2

No tengo una solución, pero apuesto a que confiar en el referente nunca funcionará porque los agentes de usuario son libres de no enviarlo en absoluto o falsificarlo en algo que les permita entrar.

Answer 3

No es posible distinguir a los usuarios de los scripts maliciosos por su solicitud http.Pero puedes analizar qué usuarios solicitan demasiadas páginas en muy poco tiempo y bloquear sus direcciones IP.

Answer 4

El uso de un referente es muy poco confiable como método de verificación.Como han mencionado otras personas, es fácil de falsificar.Tu mejor solución es modificar la aplicación (si puedes)

Puede usar un CAPTCHA o configurar algún tipo de cookie o cookie de sesión que realice un seguimiento de la última página que visitó el usuario (una sesión sería más difícil de falsificar) y realice un seguimiento del historial de visitas a la página, y solo permita a los usuarios que hayan navegado por el sitio. páginas necesarias para llegar a la página que desea bloquear.

Obviamente, esto requiere que tengas acceso a la aplicación en cuestión, sin embargo, es la forma más infalible (no completamente, pero "suficientemente buena" en mi opinión).

Answer 5

Javascript es otra herramienta útil para evitar (o al menos retrasar) el screen scraping.La mayoría de las herramientas de scraping automatizadas no tienen un intérprete de Javascript, por lo que puedes hacer cosas como configurar campos ocultos, etc.

Editar:Algo parecido a este artículo de Phil Haack.

Answer 6

¿Supongo que estás intentando evitar el raspado de pantalla?

En mi sincera opinión, es difícil de resolver y tratar de solucionarlo verificando el valor de HTTP_REFERER es solo una tirita.Cualquiera que se tome la molestia de automatizar los envíos será lo suficientemente inteligente como para enviar el referente correcto desde su 'autómata'.

Podrías intentar limitar la velocidad, pero sin modificar realmente la aplicación para forzar algún tipo de validación humana (un CAPTCHA) en algún momento, entonces te resultará difícil evitarlo.

Answer 7

Si está intentando evitar que los robots de los motores de búsqueda accedan a determinadas páginas, asegúrese de utilizar un archivo con el formato adecuado. robots.txt archivo.

Usar HTTP_REFERER no es confiable porque es fácilmente falsificado.

Otra opción es verificar la cadena del agente de usuario en busca de bots conocidos (esto puede requerir una modificación del código).

Answer 8

Para dejar las cosas un poco más claras:

1. Sí, sé que usar HTTP_REFERER es completamente poco confiable y algo infantil, pero estoy bastante seguro de que las personas que aprendieron (¿de mí tal vez?) a realizar automatizaciones con Excel VBA no sabrán cómo subvertir un HTTP_REFERER dentro del lapso de tiempo necesario. la solución definitiva.

2. No tengo acceso/privilegio para modificar el código de la aplicación.Política.¿Crees eso?Entonces, debo esperar hasta que el titular de los derechos realice los cambios que solicité.

3. Por experiencias anteriores, sé que los cambios solicitados tardarán dos meses en entrar en producción.No, tirarles libros de metodologías ágiles en sus cabezas no mejoró nada.

4. Esta es una aplicación de intranet.Así que no tengo muchos jóvenes tratando de socavar mi prestigio.Pero soy lo suficientemente joven como para intentar minar el prestigio de "una consultoría global muy elegante que viene de la India" pero donde, curiosamente, no hay ni un solo indio trabajando allí.

Hasta ahora, la mejor respuesta proviene de "Michel de Mare":bloquear usuarios en función de sus IP.Bueno, eso lo hice ayer.Hoy quería hacer algo más genérico porque tengo muchos usuarios canguro (saltando de una dirección IP a otra) porque usan VPN o DHCP.

Answer 9

Es posible que pueda utilizar un token anti-CSRF para lograr lo que busca.

Este artículo lo explica con más detalle: Falsificaciones de solicitudes entre sitios