Bloquer l’access des utilisateurs aux internes d’un site à l’aide de HTTP_REFERER

Je ne sais pas si je peux résoudre cela en une fois, 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 assurez-vous que je suis clair. Vous voulez interdire les demandes à servlet1 et servlet2 est la demande n’a pas le référant approprié et il a 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 PATH_INFO (avant le “?”) Avec un GET chaîne de requête (après le “?”). Il semble que la partie PATH_INFO fonctionnera, mais pas le test de requête GET. J’ai effectué 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 demandiez. Ils sont évidemment édités un peu pour correspondre à mon environnement:

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

Le ci-dessus a attrapé toutes les demandes de référence erronée à script1.cgi et script2.cgi qui ont essayé de soumettre des données en utilisant une chaîne de requête. Cependant, vous pouvez également soumettre des données en utilisant un chemin d’access et en publiant des données. J’ai utilisé ce formulaire pour me protéger contre l’une des trois méthodes utilisées 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 avez essayé de trouver, 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] 

J’espère que cela vous rapproche au moins de votre objective. S’il vous plaît laissez-nous savoir comment cela fonctionne, je suis intéressé par votre problème.

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

Je n’ai pas de solution, mais je parie que le fait de compter sur le référent ne fonctionnera jamais car les agents utilisateurs sont libres de ne pas l’envoyer du tout ou de l’engager dans quelque chose qui les laissera entrer.

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

L’utilisation d’un référent est très peu fiable en tant que 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 cookie de session qui garde la trace de la dernière visite de l’utilisateur (une session serait plus difficile à falsifier) ​​et conserve l’historique des pages vues et autorise uniquement les utilisateurs pages nécessaires pour accéder à la page que vous souhaitez bloquer.

Cela exige évidemment que vous ayez access à l’application en question, mais c’est la manière la plus infaillible (pas complètement, mais “assez bonne” à mon avis).

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

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

Je suppose que vous essayez d’empêcher le grattage de l’écran?

À mon avis, c’est difficile à résoudre et essayer de corriger en vérifiant la valeur de HTTP_REFERER n’est qu’un plâtre. Toute personne se rendant compte de l’automatisation des soumissions sera suffisamment avisée pour envoyer le bon référent depuis son «automate».

Vous pourriez essayer de limiter le taux, mais sans modifier l’application pour forcer une sorte de validation is-this-a-human (un CAPTCHA) à un moment donné, vous allez trouver cela difficile à prévenir.

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

Utiliser HTTP_REFERER n’est pas fiable car il est facilement falsifié .

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).

Pour rendre les choses un peu plus claires:

1. Oui, je sais que l’utilisation de HTTP_REFERER est complètement peu fiable et assez enfantine, mais je suis sûr que les personnes qui ont appris (de moi peut-être?) Avec Excel VBA ne sauront pas renverser un HTTP_REFERER dans le temps imparti. la solution finale.

2. Je n’ai pas access / privilège pour modifier le code de l’application. Politique. Croyez-vous cela? Je dois donc attendre que le titulaire des droits apporte les modifications demandées.

3. D’après les expériences précédentes, je sais que les changements demandés prendront deux mois pour entrer en production. Non, les lancer des méthodologies agiles Les livres dans leurs têtes n’amélioraient rien.

4. Ceci est une application intranet. Donc, je n’ai pas beaucoup de jeunes qui essaient 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 de l’Inde», mais où curieusement, il n’y a pas un seul indien qui y travaille.

Jusqu’à présent, la meilleure réponse vient de “Michel de Mare”: bloquer les utilisateurs en fonction de leurs adresses IP. Eh bien, c’est ce que j’ai fait hier. Aujourd’hui, je voulais faire quelque chose de plus générique car j’ai beaucoup d’utilisateurs de kangourou (en passant d’une adresse IP à une autre) car ils utilisent un VPN ou un DHCP.

Vous pouvez utiliser un jeton anti-CSRF pour réaliser ce que vous recherchez.

Cet article l’explique plus en détail: Forgeries de requêtes intersites