Non, il n'y a aucun moyen de le faire. Sans définir de limites de paramètres de connexion, il n'y a même aucun moyen de le rendre 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, alors il peut le script.

Vous pouvez configurer des restrictions User-Agent, la validation des cookies, nombre maximal de connexions et de nombreuses autres techniques, mais aucune n’arrêtera une personne déterminée à 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, n'attribuez un nom d'utilisateur et un mot de passe qu'aux personnes qui signent un NDA (ou similaire) indiquant qu'ils ne vont pas extraire ou copier les informations de votre site.

Une autre astuce consiste à charger tout votre contenu depuis AJAX ... et chargez l'URL des données AJAX à partir des chemins qui changent (tels que ~ / todays-date) et synchronisez-la 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é et déterminé d'obtenir une copie hors ligne, vous pouvez simplement rendre les choses plus difficiles donc ça 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, car c'est ce que ces content scrapers (ou moissonneurs ) 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é à l'utilisateur final, donc le mieux qu'ils puissent faire est de copier sa sortie, que vous pouvez générer dans un tel façon de changer dans le temps ou de s'ajuster en fonction de son destinataire (schémas DRM, filigrane, ...), comme l'a fait remarquer @ makerofthings7 dans sa réponse.

Tant pis à propos de 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 ce scraping de contenu est effectué par des robots d'exploration Web opportunistes et automatisés , et nous constatons des attaques ciblées beaucoup plus rares. Eh bien, au moins en nombre - supportez-moi.

Ces robots d'exploration automatisés peuvent en fait être mis sur liste noire assez efficacement grâce à l'utilisation de divers WAF (certains peuvent même utiliser des pots de miel pour déterminer les menaces de manière heuristique) ) qui tiennent à jour la base de données des domaines sur liste noire (CBL ou Community Ban Lists , DBL ou Domain Block Lists , DNSBL s ou DNS-based Blackhole Lists , ...) d'où ces scrapers de contenu automatisés fonctionnent. Ces WAF refusent ou accordent l'accès à votre application Web de diffusion de contenu selon trois approches principales:

• Liste noire déterministe : il s'agit de détections basées sur les caractéristiques des requêtes Web effectuées par les scrapers de contenu. Certains d'entre eux sont: Demander l'adresse IP d'origine, le nom d'hôte distant résolu par DNS inverse, la recherche DNS inverse confirmée en avant ( voir l'explication dans l'une de mes questions ici), la chaîne de l'agent utilisateur, l'URL de la demande ( votre application Web pourrait par exemple masquer une adresse URL Honeytrap qu'un racleur 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 liste blanche telle que les robots / araignées légitimes des moteurs de recherche) ... et d'autres informations sur les empreintes digitales associées aux requêtes 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'un requête Web unique décrite dans l'approche déterministe (les filtres anti-spam utilisent une approche similaire basée sur le calcul de la probabilité bayésienne), ou en analysant plusieurs requêtes Web, telles que: Taux de requête, ordre de requête, Nombre de demandes illégales, ... qui pourraient aider à déterminer si la demande provient de un utilisateur réel et intentionnel, ou un robot d'exploration automatisé.

• DNSBL / CBL / DBL externes : j'ai déjà mentionné l'utilisation de DNSBL / CBL externes / DBL (par exemple Project Honey Pot, Spamhaus, UCEPROTECT, ...), dont la plupart sont en fait beaucoup plus utiles que le simple suivi des spammeurs et spambot des hôtes infectés et gardez un type d'infraction (par exemple spammeur de forum , abus de taux d'exploration ,) au-dessus des adresses IP, des noms d'hôte, des CIDR plages, ... dans les listes noires qu'ils publient aussi. Certains WAF auront la possibilité de se connecter à ces bases de données, ce qui vous évitera d'être ciblé par le même acteur qui aurait peut-être déjà été mis sur la liste noire pour la même activité détectée sur un autre serveur Web.

Maintenant, une chose doit être dite clairement: aucune de ces méthodes ne peut être considérée comme pare-balles! Ils supprimeront la majorité des requêtes Web offensantes, ce qui est précieux en soi et vous permettra de mieux vous concentrer sur les délinquants les plus difficiles à détecter qui ont en quelque sorte contourné vos protections.

Il y en a bien sûr d'innombrables techniques pour la détection automatisée des crawlers / content scrapers (et leurs propres contre-mesures - techniques d'évitement de la détection) que je ne décrirai pas ici, ni ne listerai tous les WAF possibles et leurs capacités, sans vouloir tester votre patience ou atteindre les limites de l'objectif de ce Q&A . Si vous souhaitez en savoir plus sur les techniques qui peuvent être utilisées pour contrer 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 la FAQ HTTrack Website Copier: Comment limiter les abus de réseau - FAQ sur les abus pour les webmasters, et les raisons pour lesquelles une seule méthode de détection déterministe ne fonctionnera pas (à moins de mettre sur liste noire les adresses IP offensantes après coup ou grâce à l'expérience d'autres honeynets), si l'adversaire est configuré pour obscurcir l'agent utilisateur de spider en le définissant sur l'une des nombreuses chaînes d'agent utilisateur de navigateurs Web réels et légitimes, et le non-respect des directives robots.txt , deviennent plutôt apparents en parcourant le Guide de l'utilisateur HTTrack. Pour vous éviter la peine de le lire, HTTrack inclut 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 grâce à des techniques de détection plus simples.

Tout ce que l'utilisateur humain voit , il peut l'enregistrer. Comme le souligne @Adnan, c'est plutôt facile et peut être automatisé.

Cependant, certains sites ont encore un succès relatif pour dissuader les slurping de masse. Prenons, par exemple, Google Maps. De nombreuses personnes ont parfois essayé de récupérer des cartes haute définition de grandes zones grâce à des scripts. Certains ont réussi, mais la plupart ont été pris 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 modèles d'utilisation qu'un administrateur système astucieux peut remarquer et vérifier.

Des astuces similaires sont effectuées, par exemple, sur 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 est sur un pied d'égalité: il est rusé contre la ruse. Donc, cela coûte cher: cela demande de la réflexion et de la maintenance. Cependant, certains sites le font quand même.

Un moyen générique pour les attaquants de vaincre 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 nuancerais ce que @Adnan dit pour ajouter que s'il n'y a 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 un certain montant des demandes ont été faites. L'ordre dans lequel les URL sont accédées peut être déterministe, comme la profondeur en premier, la largeur en premier, croissant ou décroissant par ordre alphabétique, l'ordre d'apparition dans le DOM, etc. L'intervalle entre les demandes peut être un indice, si l'agent a exécuté avec succès du code javascript (NoScript et similaire mis à 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 lixivier de site Web n'en tienne compte, vous pourriez avoir une chance. La vérification de l'agent utilisateur ne devrait pas être efficace, car un bon lixivier prétendrait être un robot connu.Par conséquent, à moins que vous ne souhaitiez également exclure Google et d'autres moteurs de recherche, la connaissance des adresses IP utilisées par les moteurs de recherche serait utile.

Tout d'abord, le seul moyen d'empêcher la copie de votre site est de ne jamais le rendre public à personne d'autre que vous.

Vous pouvez essayer de persuader les gens de le faire avec les moyens légaux, je ne suis pas un avocat, donc je ne sais pas quelles mesures vous devriez prendre, si votre contenu est original, vous pourriez restreindre le droit d'auteur ou quelque chose de similaire.

Je pense que si vous craignez que votre site ne soit copié, il doit s'agir d'un site Web vraiment vraiment génial.

Réponse courte, non, si l'utilisateur charge une page, alors l'utilisateur peut copier du HTML en affichant la source.

Si le copieur du site Web a 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; ceux-ci sont difficiles à copier à la main de toute façon.

Sinon, je mettrais tout dans un répertoire qui a un accès restreint 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 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 inclus, puis créez 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 sache pas si cela arrêterait le logiciel ou une personne avec un outil d'inspection de code en direct.

Ou vous pouvez mettre une sorte de vérification humaine sur votre site afin qu'un répertoire PHP protégé include ne soit pas appelé à 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 cautionne aucune des choses suivantes.

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) du contenu de différentes 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 assemblez tout cela, et bien plus encore, vous trouverez 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é.

Par exemple, vous pouvez générer un balisage qui a peu ou pas de ressemblance avec la sortie graphique, pour faire de la recherche 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 certains d'entre eux avec des règles CSS complexes et générées, et en en ajoutant plus 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 entraînerait des déchets, voire gros mots! Vous pouvez diviser les lettres en deux ou plusieurs morceaux et utiliser des caractères de combinaison Unicode pour les reconstituer. Vous pouvez faire tout cela avec un générateur dynamique, créant un nouveau chef-d'œuvre aléatoire d'obfuscation 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 requises du puzzle, de sorte que sans le support Javascript et une quantité décente de temps CPU du client, le balisage seul serait inutile. 50 ms de temps processeur moderne ne sont pas remarqués par la plupart et sont suffisants pour exécuter des algorithmes assez méchants.

Des points bonus si vous essayez de gratter votre propre site Web obscurci en utilisant un navigateur sans tête, afin d'avoir un CSS complet et Pile Javascript. Ensuite, essayez de trouver des moyens (ou 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 cas du navigateur sans tête, l'algorithme entre dans une boucle infinie, ou plante le navigateur, ou génère des blasphèmes et des flashs provoquant des crises sur l'écran.

Ce sont des choses qui me viennent à l'esprit, il y a une infinité d'autres façons de baiser avec les ordinateurs des gens.

Maintenant, sois un bon garçon / fille et prends ta pilule bleue: - )

Tout d'abord, comme d'autres l'ont dit - tout ce que vous pouvez voir, vous pouvez le copier, 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 afin que tout le monde sache d'où il vient. Peut-être même un avis poli demandant aux gens de ne pas copier votre site Web ne manquerait pas.

Cependant, pour revenir à votre question initiale et comment empêcher le logiciel de copier le site Web, je pense que CloudFlare a une application Web pare-feu. Je sais certainement qu'Acunetix Web Vulnerability Scanner n'analysera pas un site Web qui utilise CloudFlare. C'est une solution gratuite et elle devrait également vous 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, en fonction de la mesure dans laquelle vous avez besoin / souhaitez protéger votre site Web. Le meilleur conseil cependant, c'est que si vous ne voulez pas qu'il soit copié, ne laissez pas les gens l'avoir.

Même AJAX avec des paramètres de date peut être dupliqué. J'ai gratté des sites avec AJAX lourd en utilisant les paramètres GET / POST. Si j'ai vraiment besoin d'émuler le navigateur, je peux 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. Le captcha est probablement la chose la plus difficile à gérer. Même alors, il y a le sniper Captcha et d'autres modules pour aider dans ces domaines.

Regardez ces liens, vous pouvez obtenir une solution à partir de ceci :)

Comment arrêter HTTrack?

Utilisez le fichier robots.txt pour empêcher site Web d'être déchiré?

OU

Le moyen le plus simple est d'identifier l'identifiant du navigateur qui parcourt 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 ..