Empêcher la copie de mon site
Est-il possible de protéger mon site contre HTTrack Website Copier ou tout autre programme similaire?
Sans définir un nombre maximum de requêtes HTTP des utilisateurs.
Non, il n'y a aucun moyen de le faire. Sans définir les limites des paramètres de connexion, il n'y a même aucun moyen de rendre la tâche relativement difficile. Si un utilisateur légitime peut accéder à votre site Web, il peut copier son contenu, et s'il peut le faire normalement avec un navigateur, il peut alors l'écrire.
Vous pouvez configurer des restrictions User-Agent, la validation des cookies, des connexions maximales et de nombreuses autres techniques, mais aucune n'arrêtera quelqu'un déterminé à copier votre site Web.
Protégez la partie du site que vous souhaitez protéger avec un nom d'utilisateur et un mot de passe. Ensuite, attribuez uniquement un nom d'utilisateur et un mot de passe aux personnes qui signent un NDA (ou similaire) qui disent qu'elles n'extraireont ni ne copieront les informations de votre site.
Une autre astuce consiste à charger tout votre contenu à partir d'AJAX ... et à effectuer le AJAX chargement de l'URL de données à partir de chemins qui changent (tels que ~/todays-date) et le synchroniser avec javascript. Ensuite même si quelqu'un devait télécharger votre contenu, les données seraient obsolètes dans les 24 heures.
Même dans ce cas, rien n'empêchera un attaquant qualifié déterminé d'obtenir une copie hors ligne, vous pouvez simplement la rendre plus difficile, donc cela ne vaut pas la peine.
Comme @Adnan l'a déjà souligné dans sa réponse , il n'y a vraiment aucun moyen d'empêcher une personne déterminée de copier des instantanés de votre site Web. J'ai utilisé le mot instantanés ici, parce que c'est ce que tel grattoirs de conten (ou moissonneuses ) copient vraiment. Ils n'ont pas (ou du moins ne devraient pas) avoir accès à votre backend où le contenu de votre site Web est réellement généré et affiché pour l'utilisateur final, donc le mieux qu'il puisse faire est de copier sa sortie, celle que vous pouvez générer dans un tel manière de changer dans le temps ou de s'adapter en fonction de son destinataire (schémas DRM, filigrane, ...), comme l'a souligné @ makerofthings7 dans sa réponse .
Voilà donc ce qui a déjà été répondu. Mais il y a une chose à propos de cette menace qui, à mon avis, n'a pas encore été bien couverte dans la réponse mentionnée. À savoir la plupart de ces grattages de contenu sont effectués par des robots d'exploration Web opportunistes et automatisés , et nous constatons que les attaques ciblées sont beaucoup plus rares. Eh bien, au moins en nombre - soyez indulgent avec moi.
Ces robots d'exploration automatisés peuvent en fait être mis sur liste noire assez efficacement grâce à l'utilisation de divers WAF s (certains pourraient même utiliser honeypots pour déterminer les menaces de manière heuristique) qui tiennent à jour la base de données des domaines sur liste noire (CBL ou Listes d'interdiction de communauté, DBL ou Listes de blocage de domaine, DNSBL s ou listes Blackhole basées sur DNS, ...) d'où ces grattoirs de contenu automatisés fonctionnent. Ces WAF refusent ou accordent l'accès à votre application Web de diffusion de contenu en fonction de trois approches principales:
Liste noire déterministe : il s'agit de détections basées sur les caractéristiques des requêtes Web que les gratteurs de contenu effectueront. Certains d'entre eux sont: Demander l'adresse IP d'origine, le nom d'hôte distant résolu DNS inversé, la recherche DNS inversée confirmée vers l'avant ( voir l'explication dans l'une de mes questions ici ), Chaîne d'agent utilisateur, URL de demande (votre application Web pourrait par exemple masquer une adresse URL Honeytrap qu'un grattoir de contenu pourrait suivre dans l'une de ses réponses, après avoir déterminé que la demande ne provenait pas d'une adresse sur la liste blanche telle que les robots/robots de recherche légitimes) ... et d'autres informations sur les empreintes digitales associées aux demandes Web automatisées.
Liste noire heuristique : il s'agit d'un moyen de déterminer une menace soit en pondérant les paramètres d'une seule demande Web décrite dans l'approche déterministe (les filtres anti-spam utilisent un approche similaire basée sur le calcul probabilité bayésienne ), ou en analysant plusieurs requêtes Web, telles que: Taux de demande, Ordre des demandes, Nombre de demandes illégales, ... qui peut aider à déterminer si la demande provient d'un utilisateur réel et prévu ou d'un robot d'indexation automatisé.
DNSBL/CBL/DBLs externes : J'ai déjà mentionné l'utilisation de DNSBL/CBL/DBL externes (par exemple Project Honey pot , Spamhaus , UCEPROTECT , ...), dont la plupart sont en réalité beaucoup plus utiles que de simplement suivre les spammeurs et spambot hôtes infectés, et conservez un type d'infraction (par exemple spammeur de forum, abus de taux d'exploration,) en plus des adresses IP , noms d'hôtes, gammes CIDR, ... dans les listes noires qu'ils publient également. Certains WAF auront la possibilité de se connecter à ces bases de données, vous évitant ainsi d'être ciblé par le même acteur qui aurait déjà été mis sur liste noire pour la même activité détectée sur un autre serveur Web.
Maintenant, une chose doit être dite très clairement - aucune de ces méthodes ne peut être considérée comme à l'épreuve des balles! Ils supprimeront la majorité des demandes Web incriminées, ce qui est précieux en soi et vous permettra de mieux vous concentrer sur ceux qui sont plus difficiles à détecter les délinquants qui ont en quelque sorte contourné vos protections.
Il y a bien sûr d'innombrables techniques pour la détection automatisée des robots/grattoirs de contenu (et leurs propres contre-mesures - techniques d'évitement de détection) que je ne décrirai pas ici, ni énumérer tous les WAF possibles et leurs capacités, ne voulant pas tester votre patience ou atteindre les limites de l'objectif de cette Q&R. Si vous souhaitez en savoir plus sur les techniques pouvant être utilisées pour contrecarrer ces visiteurs indésirables, je vous recommande de lire la documentation sur les projets OWASP Stinger et OWASP AppSensor .
Modifier pour ajouter : Les suggestions des auteurs de HTTrack peuvent être lues dans le FAQ du copieur de site Web HTTrack: Comment limiter les abus de réseau - Abus FAQ pour les webmasters document, et les raisons pour lesquelles une seule méthode déterministe de détection ne fonctionnera pas (à moins de mettre sur liste noire les adresses IP incriminées après coup ou grâce à l'expérience d'autres honeynets), si l'adversaire est prêt à obscurcir l'araignée user agent chaîne en le définissant sur l'une des nombreuses chaînes d'agent utilisateur des navigateurs Web réels et légitimes, et manque de respect robots.txt directives, deviennent assez apparentes en apercevant le HTTrack Users Guide . Pour vous éviter d'avoir à le lire, HTTrack comprend une configuration simple et des indicateurs de ligne de commande pour le faire fonctionner en mode furtif et apparaître aussi bénin que tout autre utilisateur légitime pour des techniques de détection plus simples.
Tout ce que l'utilisateur humain voit , il peut l'enregistrer. Comme le souligne @Adnan, cela est plutôt simple et peut être automatisé.
Cependant, certains sites réussissent encore relativement bien à dissuader le slurping de masse. Considérez, par exemple, Google Maps . De nombreuses personnes ont, à l'occasion, tenté de récupérer des cartes haute définition de vastes zones grâce à des scripts. Certains ont réussi, mais la plupart ont été capturés par les défenses de Google. Il se trouve qu'il est difficile de faire un téléchargeur automatique qui agit, du point de vue du serveur, comme s'il était sous contrôle humain. Les humains ont toutes sortes de latences et de schémas d'utilisation qu'un administrateur système avisé peut remarquer et vérifier.
Des astuces similaires sont effectuées sur, par exemple, Stack Exchange . Si vous essayez d'automatiser l'accès au site, vous serez bientôt redirigé vers une page avec un CAPTCHA .
Au final, ce type de sécurité n'est pas très satisfaisant car le défenseur et l'attaquant sont sur un pied d'égalité: c'est de la ruse contre la ruse. Donc, c'est cher: cela demande réflexion et maintenance. Cependant, certains sites le font néanmoins.
Un moyen générique pour les attaquants de contourner les mesures de sécurité anti-automatisation consiste à "automatiser" le slurping avec de vrais humains. Des travailleurs humains très bon marché peuvent être embauchés dans certains pays.
Je qualifierais ce que @Adnan dit d'ajouter que bien qu'il n'y ait aucun moyen en général d'empêcher la lixiviation du site au fil du temps, un outil spécifique peut présenter un comportement qui peut être détecté avec une certaine certitude une fois qu'un certain nombre de demandes ont a été fait. L'ordre dans lequel les URL sont consultées peut être déterministe, comme la profondeur en premier, la largeur en premier, l'ordre croissant ou décroissant par ordre alphabétique, l'ordre d'apparition dans le DOM et ainsi de suite. L'intervalle entre les demandes peut être un indice, si l'agent a réussi à exécuter du code javascript (NoScript et similaire à part), la prise en charge du client pour l'API de performance du navigateur, le temps passé entre les demandes par rapport à la complexité de la page, et s'il existe ou non un flux logique entre demandes. À moins qu'un leacher de site Web n'en tienne compte, vous pourriez avoir une chance. La vérification des agents utilisateurs ne devrait pas être efficace, car un bon lixiviant prétendrait être un bot connu, donc à moins que vous ne souhaitiez exclure Google et d'autres moteurs de recherche, il serait utile de connaître les IP que les moteurs de recherche utilisent.
Tout d'abord, la seule façon d'empêcher la copie de votre site est de ne jamais le rendre public à personne d'autre qu'à vous.
Vous pouvez essayer de persuader les gens de le faire par des moyens légaux, je ne suis pas avocat, donc je ne sais pas quelles mesures vous devez prendre.Si votre contenu est original, vous pouvez restreindre le droit d'auteur ou quelque chose de similaire.
Je pense que si vous craignez que votre site puisse être copié, il doit s'agir d'un site Web vraiment vraiment très bien.
Réponse courte, non, si l'utilisateur charge une page, il peut copier du code HTML en affichant la source.
Si le copieur du site Web possède un agent utilisateur particulier, vous pouvez le bloquer. Voir Stack Exchange pour plus de détails.
Une autre solution pourrait être de créer une page Web Flash; ils sont de toute façon difficiles à copier à la main.
Sinon, je mettrais tout dans un répertoire dont l'accès est restreint et que seuls les scripts PHP côté serveur peuvent récupérer. Ensuite, si la page est construite avec de nombreux inclus (un pour une barre de navigation, un pour l'en-tête, un pour le javascript, un pour le pied de page, un pour le contenu du corps), créez un autre répertoire de fichiers php qui lisent le répertoire protégé avec des inclus, puis faites un AJAX qui charge dynamiquement ces fichiers PHP. Il serait difficile pour quoi que ce soit de le copier sans rendre le JavaScript (bien que je ne sais pas si cela arrêterait le logiciel ou un individu avec un outil d'inspection de code en direct.
Ou vous pouvez mettre une sorte de vérification humaine sur votre site afin qu'une inclusion de répertoire PHP protégé ne soit pas appelée à moins que l'utilisateur ne clique spécifiquement sur un objet DOM sans lien (comme une ligne qui dit "entrez ici" ) qui déclenche le chargement du contenu.
Avertissement: c'est une mauvaise réponse. Je ne tolère aucun des éléments suivants.
Les navigateurs modernes sont capables de calcul générique (Turing-complet), via Javascript et éventuellement d'autres moyens. Même leurs moteurs de rendu HTML + CSS de base sont des logiciels incroyablement élaborés, capables d'afficher (ou de masquer) le contenu de diverses manières. Si cela ne suffisait pas, tous les navigateurs modernes proposent des primitives graphiques, par exemple via SVG et Canvas, et permettent de télécharger des polices personnalisées pour rendre le texte avec.
Si vous mettez tout cela ensemble, et plus encore, vous constaterez qu'il existe un certain nombre de couches d'exécution entre le code source du site et les pixels qui composent les lettres et les mots que l'utilisateur peut lire.
Toutes ces couches d'exécution peuvent être obscurcies et/ou exploitées.
Par exemple, vous pouvez générer un balisage qui a peu ou pas de ressemblance avec la sortie graphique, pour faire de la consultation de la source HTML de votre site Web un exercice futile. Vous pouvez utiliser une balise HTML par lettre, en les réorganisant avec une utilisation créative de float: et position:, en masquant certaines d'entre elles avec des règles CSS complexes et générées, et en ajoutant d'autres qui n'existaient pas, avec du contenu généré par CSS.
Vous pouvez créer une police qui utilise un mappage personnalisé entre les codes de caractères et les glyphes, de sorte que copier et coller votre contenu produirait des ordures, voire des jurons! Vous pouvez diviser les lettres en deux ou plusieurs morceaux et utiliser la combinaison de caractères Unicode pour les recomposer. Vous pouvez faire tout cela avec un générateur dynamique, créant un nouveau chef-d'œuvre aléatoire d'obscurcissement pour chaque requête HTTP.
Vous pouvez écrire un programme qui créera des algorithmes Javascript complexes qui, lorsqu'ils sont exécutés sur le client, rempliront certaines pièces du puzzle, de sorte que sans le support de Javascript et une quantité décente de temps processeur client, le balisage seul serait inutile. 50 ms de temps CPU moderne sont inaperçus par la plupart et suffisent pour exécuter des algorithmes assez méchants.
Points bonus si vous essayez de gratter votre propre site Web obscurci à l'aide d'un navigateur sans tête, afin d'avoir une pile CSS et Javascript complète. Ensuite, essayez de trouver des moyens (ou des heuristiques) pour distinguer un vrai navigateur de celui sans tête. Ensuite, placez des pièges dans le code Javascript généré, de sorte que lorsqu'il tombe dans le boîtier du navigateur sans tête, l'algorithme passe dans une boucle infinie, ou bloque le navigateur, ou génère des éclairs de blasphèmes et de crises à l'écran.
Ce sont sur le dessus de ma tête, il existe (sans aucun doute) d'innombrables autres façons de f *** avec les ordinateurs des gens.
Maintenant, soyez un bon garçon/fille et prenez votre pilule bleue :-)
Tout d'abord, comme d'autres l'ont dit - tout ce que vous pouvez voir peut être copié, en utilisant différentes méthodes. Cela dépend de la raison pour laquelle vous souhaitez empêcher la copie de votre site Web, mais la méthode la plus efficace serait probablement d'ajouter des filigranes pour que tout le monde sache d'où il provient. Peut-être même un avis poli demandant aux gens de ne pas copier votre site Web ne serait pas raté.
Cependant, pour en revenir à votre question initiale et savoir comment empêcher les logiciels de copier le site Web, je crois que CloudFlare a un pare-feu d'application Web. Je sais certainement que Acunetix Web Vulnerability Scanner ne scannera pas un site Web qui utilise CloudFlare. C'est une solution gratuite et elle devrait également aider à accélérer votre site Web.
Il existe maintenant une solution infaillible et tout peut être contourné. La meilleure chose que vous puissiez faire est d'utiliser une combinaison des réponses ici, selon la façon dont vous avez besoin/souhaitez protéger votre site Web. Le meilleur conseil cependant, c'est que si vous ne voulez pas le copier, ne laissez pas les gens l'avoir.
Même AJAX avec les paramètres de date peuvent être dupliqués. J'ai gratté des sites avec de lourds AJAX en utilisant les paramètres GET/POST. Si j'ai vraiment besoin d'émuler le navigateur, je peut simplement utiliser du sélénium ou quelque chose de ce genre. Je peux toujours trouver un moyen de gratter un site si je le voulais vraiment. Captcha est probablement la chose la plus difficile à gérer. Même alors, il y a le sniper Captcha et d'autres modules pour les aider domaines.
Regardez ces liens, vous pouvez obtenir une solution de cela :)
tilisez robots.txt pour éviter que le site Web ne soit arraché?
OR
Le moyen le plus simple consiste à identifier l'ID du navigateur qui navigue sur votre page, s'il s'agit de htttrack, bloquez-le (vous devez configurer votre serveur ou utiliser votre compétence de programmation pour charger la page différente en conséquence)
Merci..