Bloquer l'accès des utilisateurs aux éléments internes d'un site à l'aide de HTTP_REFERER

Question

J'ai le contrôle sur le HttpServer mais pas sur l'ApplicationServer ou les applications Java qui s'y trouvent, mais je dois bloquer l'accès direct à certaines pages de ces applications.Plus précisément, je ne souhaite pas que les utilisateurs automatisent l'accès aux formulaires envoyant des requêtes HTTP GET/POST directes au servlet approprié.

J'ai donc décidé de bloquer les utilisateurs en fonction de la valeur de HTTP_REFERER.Après tout, si l'utilisateur navigue à l'intérieur du site, il disposera d'un HTTP_REFERER.Eh bien, c'est ce que je pensais.

J'ai implémenté une règle de réécriture dans le fichier .htaccess qui dit :

RewriteEngine on 

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

Je m'attendais à interdire l'accès aux utilisateurs qui ne naviguaient pas sur le site mais qui émettaient des requêtes GET directes aux servlets "servlet1" ou "servlet2" à l'aide de chaînes de requête.Mais mes attentes se sont terminées brusquement car l'expression régulière (servlet1|servlet2)/.+\?.+ n'a pas fonctionné du tout.

J'ai été vraiment déçu quand j'ai changé cette expression en (servlet1|servlet2)/.+ et cela a si bien fonctionné que mes utilisateurs ont été bloqués, qu'ils naviguent ou non sur le site.

Donc, ma question est :Comment puis-je accomplir cette tâche consistant à ne pas autoriser les « robots » avec un accès direct à certaines pages si je n'ai pas d'accès/privilèges/temps pour modifier l'application ?

Answer 1

Je ne suis pas sûr de pouvoir résoudre ce problème d'un seul coup, mais nous pouvons faire des allers-retours si nécessaire.

Tout d’abord, je veux répéter ce que je pense que vous dites et m’assurer d’être clair.Vous souhaitez interdire les requêtes vers servlet1 et servlet2 si la requête n'a pas le bon référent et qu'elle fait avez-vous une chaîne de requête ?Je ne suis pas sûr de comprendre (servlet1|servlet2)/.+\?.+ car il semble que vous ayez besoin d'un fichier sous servlet1 et 2.Je pense que vous combinez peut-être PATH_INFO (avant le "?") avec une chaîne de requête GET (après le "?").Il semble que la partie PATH_INFO fonctionnera mais pas le test de requête GET.J'ai fait un test rapide sur mon serveur en utilisant script1.cgi et script2.cgi et les règles suivantes ont fonctionné pour accomplir ce que vous demandez.Ils sont évidemment un peu édités pour correspondre à mon environnement :

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

Ce qui précède a détecté toutes les requêtes de mauvais référent adressées à script1.cgi et script2.cgi qui tentaient de soumettre des données à l'aide d'une chaîne de requête.Cependant, vous pouvez également soumettre des données à l'aide d'un path_info et en publiant des données.J'ai utilisé ce formulaire pour me protéger contre l'utilisation de l'une des trois méthodes avec un référent incorrect :

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]

Sur la base de l'exemple que vous essayiez de faire fonctionner, je pense que c'est ce que vous voulez :

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

Espérons que cela vous rapproche au moins de votre objectif.S'il vous plaît laissez-nous savoir comment cela fonctionne, votre problème m'intéresse.

(BTW, je suis d'accord que le blocage des référents est une mauvaise sécurité, mais je comprends aussi que la réalité impose parfois des solutions imparfaites et partielles, ce que vous semblez déjà reconnaître.)

Answer 2

Je n'ai pas de solution, mais je parie que s'appuyer sur le référent ne fonctionnera jamais car les agents utilisateurs sont libres de ne pas l'envoyer du tout ou de l'usurper à quelque chose qui les laissera entrer.

Answer 3

Vous ne pouvez pas distinguer les utilisateurs des scripts malveillants par leur requête http.Mais vous pouvez analyser quels utilisateurs demandent trop de pages en trop peu de temps et bloquer leurs adresses IP.

Answer 4

L’utilisation d’un référent est très peu fiable comme méthode de vérification.Comme d'autres personnes l'ont mentionné, il est facilement usurpé.Votre meilleure solution est de modifier l'application (si vous le pouvez)

Vous pouvez utiliser un CAPTCHA, ou définir une sorte de cookie ou de session qui garde une trace de la dernière page visitée par l'utilisateur (une session serait plus difficile à usurper) et garde une trace de l'historique des pages consultées, et autorise uniquement les utilisateurs qui ont parcouru le pages requises pour accéder à la page que vous souhaitez bloquer.

Cela nécessite évidemment d'avoir accès à l'application en question, cependant c'est le moyen le plus infaillible (pas complètement, mais "assez bien" à mon avis.)

Answer 5

Javascript est un autre outil utile pour empêcher (ou au moins retarder) le grattage d'écran.La plupart des outils de scraping automatisés n'ont pas d'interpréteur Javascript, vous pouvez donc faire des choses comme définir des champs cachés, etc.

Modifier:Quelque chose dans le sens de cet article de Phil Haack.

Answer 6

Je suppose que vous essayez d'empêcher le grattage d'écran ?

À mon avis honnête, c'est un problème difficile à résoudre et essayer de le résoudre en vérifiant la valeur de HTTP_REFERER n'est qu'un pansement.Quiconque prend la peine d'automatiser les soumissions sera suffisamment avisé pour envoyer le bon référent depuis son « automate ».

Vous pouvez essayer de limiter le débit, mais sans réellement modifier l'application pour forcer une sorte de validation est-ce-un-humain (un CAPTCHA) à un moment donné, vous aurez du mal à empêcher cela.

Answer 7

Si vous essayez d'empêcher les robots des moteurs de recherche d'accéder à certaines pages, assurez-vous d'utiliser un fichier correctement formaté. robots.txt déposer.

L'utilisation de HTTP_REFERER n'est pas fiable car elle est facilement truqué.

Une autre option consiste à vérifier la chaîne de l'agent utilisateur pour les robots connus (cela peut nécessiter une modification du code).

Answer 8

Pour rendre les choses un peu plus claires :

1. Oui, je sais qu'utiliser HTTP_REFERER est complètement peu fiable et quelque peu enfantin mais je suis presque sûr que les personnes qui ont appris (de moi peut-être ?) à faire des automatisations avec Excel VBA ne sauront pas comment renverser un HTTP_REFERER dans le laps de temps nécessaire pour avoir la solution finale.

2. Je n'ai pas d'accès/privilège pour modifier le code de l'application.Politique.Le croyez-vous ?Je dois donc attendre que le titulaire des droits apporte les modifications que j'ai demandées.

3. D'après mes expériences précédentes, je sais que les modifications demandées prendront deux mois pour entrer en production.Non, leur jeter des livres de méthodologies agiles dans leur tête n'a rien amélioré.

4. Ceci est une application intranet.Je n'ai donc pas beaucoup de jeunes qui tentent de miner mon prestige.Mais je suis assez jeune pour tenter de saper le prestige d'un « service de conseil mondial très sophistiqué qui vient d'Inde » mais où, curieusement, aucun Indien n'y travaille.

Jusqu’à présent, la meilleure réponse vient de « Michel de Mare » :bloquer les utilisateurs en fonction de leur adresse IP.Eh bien, c'est ce que j'ai fait hier.Aujourd'hui, j'ai voulu faire quelque chose de plus générique car j'ai beaucoup d'utilisateurs kangourous (sautant d'une adresse IP à une autre) car ils utilisent VPN ou DHCP.

Answer 9

Vous pourrez peut-être utiliser un jeton anti-CSRF pour réaliser ce que vous recherchez.

Cet article l'explique plus en détail : Contrefaçons de demandes intersites