No, non c'è modo di farlo. Senza impostare i limiti dei parametri di connessione, non c'è nemmeno modo di renderlo relativamente difficile. Se un utente legittimo può accedere al tuo sito web, può copiarne il contenuto e, se può farlo normalmente con un browser, può scrivere uno script.

Potresti impostare restrizioni utente-agente, convalida dei cookie, connessioni massime e molte altre tecniche, ma nessuna fermerà qualcuno determinato a copiare il tuo sito web.

Proteggi la parte del sito che desideri proteggere con un nome utente e una password. Quindi assegna un nome utente e una password solo alle persone che firmano un accordo di non divulgazione (o simile) che dice che non estrarranno o copieranno le informazioni dal tuo sito.

Un altro trucco è far caricare tutti i tuoi contenuti da AJAX ... e fai caricare l'URL dei dati AJAX dai percorsi che cambiano (come ~ / todays-date) e sincronizzalo con javascript. Quindi, anche se qualcuno scaricasse i tuoi contenuti, i dati sarebbero obsoleti entro 24 ore.

Anche in questo caso, nulla impedirà a un determinato aggressore esperto di ottenere una copia offline, puoi solo renderlo più difficile quindi non ne vale la pena.

Come ha già sottolineato @Adnan nella sua risposta, non c'è davvero modo di impedire a una persona determinata di copiare istantanee del tuo sito web. Ho usato la parola istantanee qui, perché è ciò che questi scraper di contenuti (o raccoglitori ) stanno davvero copiando. Non hanno (o almeno non dovrebbero) avere accesso al tuo back-end in cui i contenuti del tuo sito web vengono effettivamente generati e visualizzati all'utente finale, quindi il meglio che possono fare è copiare il suo output, uno che puoi generare in tale modo di cambiare nel tempo o adeguarsi in base al destinatario previsto (schemi DRM, watermarking, ...), come ha sottolineato @ makerofthings7 nella sua risposta.

Quindi questo tanto su ciò che è già stato risposto. Ma c'è una cosa su questa minaccia che ritengo non sia stata ancora ben trattata nella risposta menzionata. Vale a dire, la maggior parte di questo tipo di scraping dei contenuti viene eseguita da crawler web opportunistici e automatizzati e vediamo attacchi mirati molto più rari. Beh, almeno in numero - abbi pazienza.

Questi crawler automatici possono effettivamente essere inseriti in una lista nera in modo abbastanza efficace tramite l'uso di vari WAF (alcuni potrebbero persino utilizzare honeypot per determinare le minacce in modi euristici ) che mantengono aggiornato il database dei domini inseriti nella blacklist (CBL o Community Ban Lists , DBL o Domain Block List , DNSBL o Blackhole List basati su DNS , ...) da cui operano tali scraper di contenuti automatizzati. Questi WAF negheranno o concederanno l'accesso alla tua applicazione web per il servizio dei contenuti in base a tre approcci principali:

• Inserimento nella lista nera deterministica : si tratta di rilevamenti basati sulle caratteristiche delle richieste web che gli scraper di contenuti effettueranno. Alcuni di questi sono: Richiedi indirizzo IP di origine, Nome host remoto risolto DNS inverso, Ricerca DNS inversa confermata in avanti ( vedi la spiegazione in una delle mie domande qui), Stringa agente utente, URL richiesta ( la tua applicazione web potrebbe ad esempio nascondere un indirizzo URL honeytrap che un content scraper potrebbe seguire in una delle sue risposte, dopo aver determinato che la richiesta non proveniva da un indirizzo autorizzato come crawler / spider dei motori di ricerca legittimi) ... e altre informazioni sulle impronte digitali associate a richieste web automatizzate.

• Blacklist euristica : questo è un modo per determinare una minaccia ponderando i parametri di un singola richiesta web descritta nell'approccio deterministico (i filtri antispam utilizzano un approccio simile basato sul calcolo della probabilità bayesiana) o analizzando più richieste web, come: Tasso di richiesta, Ordine di richiesta, Numero di richieste illegali, ... che potrebbe aiutare a determinare se la richiesta proviene da un utente reale e previsto, o un crawler automatico.

• DNSBL / CBL / DBL esterni : ho già menzionato il fatto di affidarsi a DNSBL / CBL esterni / DBL (ad es Project Honey Pot, Spamhaus, UCEPROTECT, ...), la maggior parte dei quali sono in realtà molto più utili del semplice tenere traccia degli spammer e spambot host infetti e mantieni un tipo di reato (ad es. spammer del forum , abuso della velocità di scansione ) sopra gli indirizzi IP, i nomi host, CIDR intervalli, ... anche nelle liste nere che pubblicano. Alcuni WAF avranno la possibilità di connettersi a questi database, risparmiandoti la fatica di essere preso di mira dallo stesso attore che potrebbe essere già stato inserito nella lista nera per la stessa attività rilevata su un altro server web.

Ora, una cosa deve essere detta abbastanza chiaramente: nessuno di questi metodi può essere considerato a prova di proiettile! Rimuoveranno la maggior parte delle richieste web offensive, il che è prezioso da solo e ti consentirà di concentrarti meglio su quelle più difficili da rilevare i trasgressori che in qualche modo hanno aggirato le tue protezioni.

Ce ne sono ovviamente innumerevoli tecniche per il rilevamento automatizzato di crawler / content scrapers (e le loro contromisure - tecniche di evitamento del rilevamento) che non descriverò qui, né elencerò tutti i possibili WAF e le loro capacità, non volendo testare la tua pazienza o raggiungere i limiti dello scopo di questo Q&A . Se desideri saperne di più sulle tecniche che possono essere utilizzate per contrastare tali visitatori indesiderati, ti consiglio di leggere la documentazione sui progetti OWASP Stinger e OWASP AppSensor.

Modifica per aggiungere : i suggerimenti degli autori di HTTrack possono essere letti nelle FAQ di HTTrack Website Copier: Come limitare l'abuso di rete - Domande frequenti sugli abusi per i webmaster, e le ragioni per cui un singolo metodo deterministico di rilevamento non funzionerà (a meno di inserire nella lista nera gli indirizzi IP offensivi dopo il fatto o attraverso l'esperienza di altri honeynet), se l'avversario è impostato per offuscare l'agente utente dello spider impostandola su una qualsiasi delle tante stringhe dell'agente utente di browser Web reali e legittimi e la mancanza di rispetto delle direttive robots.txt , diventano piuttosto evidenti dando un'occhiata alla HTTrack Users Guide. Per risparmiarti il ​​fastidio di leggerlo, HTTrack include una semplice configurazione e flag della riga di comando per farlo funzionare in modalità invisibile e apparire altrettanto benigno come qualsiasi altro utente legittimo per tecniche di rilevamento più semplici.

Tutto ciò che l'utente umano vede , può registrarlo. Come sottolinea @Adnan, questo è piuttosto semplice e può essere automatizzato.

Tuttavia, alcuni siti hanno ancora un relativo successo nello scoraggiare lo slurping di massa. Considera, ad esempio, Google Maps. Molte persone hanno tentato, occasionalmente, di recuperare mappe ad alta definizione di ampie aree tramite script. Alcuni ci sono riusciti, ma la maggior parte è stata catturata dalle difese di Google. Accade così che sia difficile realizzare un downloader automatico che agisca, dal punto di vista del server, come se fosse sotto il controllo umano. Gli esseri umani hanno tutti i tipi di latenze e modelli di utilizzo che un astuto amministratore di sistema può notare e controllare.

Trucchi simili vengono eseguiti, ad esempio, su Stack Exchange. Se provi ad automatizzare l'accesso al sito, verrai presto reindirizzato a una pagina con un CAPTCHA.

In definitiva, questo tipo di sicurezza non è molto soddisfacente perché il difensore e l'attaccante è sullo stesso piano: astuzia contro astuzia. Quindi, questo è costoso: richiede riflessione e manutenzione. Tuttavia, alcuni siti lo fanno comunque.

Un modo generico per gli aggressori di sconfiggere le misure di sicurezza anti-automazione è "automatizzare" lo slurping con gli umani reali. In alcuni paesi è possibile assumere lavoratori umani molto economici.

Qualificherei ciò che dice @Adnan aggiungendo che, sebbene in generale non sia possibile impedire la lisciviazione del sito nel tempo , uno strumento specifico può mostrare un comportamento che può essere rilevato con una certa certezza una volta che una certa quantità delle richieste sono state fatte. L'ordine in cui si accede agli URL può essere deterministico, ad esempio prima la profondità, prima la larghezza, crescente o decrescente in ordine alfabetico, l'ordine in cui sono visualizzati nel DOM e così via. L'intervallo tra le richieste può essere un indizio, se l'agente ha eseguito con successo del codice javascript (NoScript e simili a parte), il supporto del client per l'API delle prestazioni del browser, il tempo trascorso tra le richieste in relazione alla complessità della pagina e se esiste o meno un flusso logico tra richieste. A meno che un leacher di siti Web non ne tenga conto, potresti avere una possibilità. Il controllo dell'agente utente non dovrebbe essere efficace in quanto un buon leacher fingerebbe di essere un bot conosciuto, quindi a meno che tu non voglia escludere Google e anche altri motori di ricerca, la conoscenza degli IP utilizzati dai motori di ricerca sarebbe utile.

Prima di tutto, l'unico modo per impedire che il tuo sito venga copiato è in realtà non renderlo mai pubblico a nessuno tranne te.

Un modo in cui potresti provare a persuadere le persone a farlo è con significa legale, non sono un avvocato quindi non so quali passi dovresti fare, se il tuo contenuto è originale potresti limitare il copyright o qualcosa di simile.

Penso che se temi che il tuo sito possa essere copiato, deve essere un sito web davvero davvero fantastico.

Risposta breve, no, se l'utente carica una pagina, l'utente può copiare l'HTML visualizzando la sorgente.

Se il copiatore del sito Web ha un particolare agente utente, è possibile bloccarlo. Vedi Stack Exchange per i dettagli.

Un'altra soluzione potrebbe essere quella di creare una pagina web Flash; quelli sono comunque difficili da copiare a mano.

In caso contrario, metterei tutto in una directory con accesso limitato che solo gli script PHP lato server possono recuperare. Quindi se la pagina è costruita con molti include (uno per una barra di navigazione, uno per l'intestazione, uno per javascript, uno per il piè di pagina, uno per il contenuto del corpo) allora crea un'altra directory di file php che leggono la directory protetta con include, quindi crea un AJAX che carica dinamicamente quei file PHP. Sarebbe difficile per qualsiasi cosa copiarlo senza eseguire il rendering del JavaScript (anche se non so se ciò fermerebbe il software o un individuo con uno strumento di ispezione del codice live.

Oppure puoi inserire un qualche tipo di verifica umana sul tuo sito in modo che una directory PHP protetta non venga chiamata a meno che l'utente non faccia clic specificamente su un oggetto DOM non collegato (come una riga che dice "inserisci qui") che attiva il caricamento del contenuto.

Disclaimer: questa è una risposta malvagia. Non permetto nulla di quanto segue.

I browser moderni sono in grado di eseguire calcoli generici (Turing-complete), tramite Javascript e possibilmente altri mezzi. Anche i loro motori di rendering HTML + CSS di base sono pezzi di software incredibilmente elaborati, in grado di visualizzare (o nascondere) i contenuti in una varietà di modi. Se ciò non bastasse, tutti i browser moderni rendono disponibili primitive grafiche, ad esempio tramite SVG e Canvas, e consentono il download di caratteri personalizzati con cui eseguire il rendering del testo.

Se metti insieme tutto questo e altri ancora, scoprirai che ci sono una serie di livelli di esecuzione tra il codice sorgente del sito ei pixel che compongono le lettere e le parole che l'utente può leggere.

Tutti questi livelli di esecuzione possono essere offuscati e / o sfruttato.

Ad esempio, puoi generare markup che ha poca o nessuna somiglianza con l'output grafico, per fare in modo che guardare il sorgente HTML del tuo sito web sia un esercizio futile. Puoi utilizzare un tag HTML per lettera, riordinandoli con un uso creativo di float: e position: , nascondendone alcuni con regole CSS complesse generate e aggiungendone più che non c'erano, con contenuti generati da CSS.

Puoi creare un font che utilizzi una mappatura personalizzata tra codici di caratteri e glifi, in modo che copiare e incollare i tuoi contenuti produca spazzatura totale, parolacce! Puoi dividere le lettere in due o più parti e utilizzare Unicode combinando i caratteri per rimetterle insieme. Puoi fare tutto questo con un generatore dinamico, creando un nuovo capolavoro casuale di offuscamento per ogni richiesta HTTP.

Puoi scrivere un programma che creerà complessi algoritmi Javascript, che quando eseguito sul client riempirà alcuni pezzi richiesti del puzzle, in modo che senza il supporto Javascript e una discreta quantità di tempo della CPU del client, il markup da solo sarebbe inutili. 50 ms di tempo della CPU moderna non vengono notati dalla maggior parte e sono sufficienti per eseguire alcuni algoritmi piuttosto malvagi.

Punti bonus se provi a raschiare il tuo sito Web offuscato utilizzando un browser headless, al fine di avere un CSS completo e Stack JavaScript. Quindi prova a trovare modi (o euristiche) per distinguere un browser reale da quello senza testa. Quindi inserisci alcune trappole nel codice Javascript generato, in modo che quando cade nel case del browser senza testa, l'algoritmo va in un ciclo infinito, o blocca il browser o genera parolacce e lampi che inducono sequestri sullo schermo.

Questi sono fuori dalla mia testa, ci sono (numerabilmente) infiniti altri modi per scopare con i computer delle persone.

Ora sii un bravo ragazzo / ragazza e prendi la tua pillola blu: - )

Prima di tutto, come altri hanno detto, tutto ciò che puoi vedere puoi copiare, usando vari metodi. Dipende dal motivo per cui vuoi impedire che il tuo sito web venga copiato, ma il metodo più efficace sarebbe probabilmente aggiungere filigrane in modo che tutti sappiano da dove proviene. Forse anche un avviso educato che chiede alle persone di non copiare il tuo sito web non andrebbe perso.

Tuttavia, tornando alla tua domanda originale e come impedire al software di copiare il sito web, credo che CloudFlare abbia un'applicazione web firewall. So certamente che Acunetix Web Vulnerability Scanner non esegue la scansione di un sito Web che utilizza CloudFlare. È una soluzione gratuita e dovrebbe anche aiutare a velocizzare il tuo sito web.

Ora però esiste una soluzione infallibile e tutto può essere aggirato. La cosa migliore che puoi fare è utilizzare una combinazione delle risposte qui, a seconda di quanto hai bisogno / vuoi proteggere il tuo sito web. Il miglior consiglio, però, è che se non vuoi che venga copiato, non lasciarlo alle persone.

Anche AJAX con parametri di data può essere duplicato. Ho raschiato siti con AJAX pesante utilizzando i parametri GET / POST. Se ho davvero bisogno di emulare il browser posso semplicemente usare il selenio o qualcosa del genere. Posso sempre trovare un modo per raschiare un sito se lo volessi davvero. Il captcha è probabilmente la cosa più difficile da affrontare. Anche allora c'è il cecchino Captcha e altri moduli per assistere in queste aree.

Guarda questi link potresti ottenere una soluzione da questo :)

Come fermare HTTrack?

Usa robots.txt per prevenire sito web da essere strappato?

OR

Il modo più semplice è identificare l'ID del browser che sta navigando nella tua pagina, se si tratta di httpstrack bloccalo (devi configurare il tuo server o la tua abilità di programmazione per caricare la pagina diversa di conseguenza)

Grazie ..