Frage:
Verhindern Sie, dass meine Website kopiert wird
h4ck3r
2013-07-05 14:51:16 UTC
view on stackexchange narkive permalink

Ist es möglich, meine Website vor HTTrack Website Copier oder einem ähnlichen Programm zu schützen?
Ohne eine maximale Anzahl von HTTP-Anforderungen von Benutzern festzulegen.

Einfache Lösung: Nehmen Sie einfach die Website herunter.
Die Webanwendungs-Firewall von imperva behauptet, solche Aktivitäten auf verschiedene Weise erkennen und blockieren zu können.
HT Track berücksichtigt Ausschlüsse in robots.txt, "ähnliche Programme" jedoch möglicherweise nicht.
Aber warte, greifst du nicht nach den Websites anderer Leute? http://stackoverflow.com/questions/17440236/getting-java-to-save-a-html-file
@ROFLwTIME nein, ich habe nur mit Java gespielt, aber dieses Programm hat diese Frage ausgelöst. Ich habe dieses Programm in der Hoffnung geschrieben, es zu verhindern. Das Programm wurde mit Erfolg erstellt, aber die Prävention ist fehlgeschlagen. lol
Diese Art von Frage ist so häufig und doch so absurd. Wenn Sie eine Website online stellen und die Benutzer sie "anzeigen" und auf ihren Computer herunterladen, geben Sie sie im Wesentlichen an sie weiter. Dann lautet die Frage "Ich habe meine Website jemandem gegeben, wie kann ich sie nicht geben?".
aber warum brauchst du das? seine bedeutungslose Anforderung? Wenn Ihr Posteingang öffentlich angezeigt wird, können Sie dies verhindern, aber hier dient die Website nur zur Angabe von Informationen, und nach dem Erstellen der Website möchten Sie diese nicht weitergeben? Wie lautet dann das Motto Ihrer Website?
Es war nicht als Voraussetzung gedacht, ich wollte nur wirklich wissen, ob es möglich ist. Nur meine Neugier.
Sie erstellen die gesamte Site aus einer Form von serverseitigem Code (auf diese Weise kann der Benutzer nur das herunterladen, was an ihn gesendet wird).
Dies wäre nur für die einfachsten Websites wirklich nützlich
Elf antworten:
Adi
2013-07-05 14:56:36 UTC
view on stackexchange narkive permalink

Nein, dazu gibt es keine Möglichkeit. Ohne das Festlegen von Grenzwerten für Verbindungsparameter gibt es keine Möglichkeit, dies relativ schwierig zu machen. Wenn ein legitimer Benutzer auf Ihre Website zugreifen kann, kann er deren Inhalt kopieren, und wenn er dies normal mit einem Browser tun kann, kann er ein Skript erstellen.

Sie können User-Agent-Einschränkungen, Cookie-Validierung usw. einrichten. Maximale Verbindungen und viele andere Techniken, aber keine wird jemanden davon abhalten, Ihre Website zu kopieren.

Sie können auch alle Ihre Bilder mit einem Wasserzeichen versehen, um später zu beweisen, dass sie ursprünglich Ihnen gehören. Dies verhindert jedoch nicht das Kopieren, sondern hilft erst nachträglich.
Und vergessen Sie nicht zu erwähnen, dass eine solche Maßnahme legitime Besucher eher stört, als jemanden daran zu hindern, sie aktiv zu umgehen.
Wie schafft Themeforest das dann?
@Four_0h_Three Wasserzeichen sind weitgehend sinnlos. Jedes vernünftige Wasserzeichen kann in PhotoShop innerhalb von 30 Sekunden (oder weniger) entfernt werden. Wenn Ihr Wasserzeichen nicht so einfach entfernt werden kann, befindet es sich wahrscheinlich an einem unangenehmen Ort und ruiniert die Freude, die Ihre Benutzer an den Inhalten gehabt hätten. Fakt ist: Es gibt keine Möglichkeit, sichtbare gehostete Inhalte von jemandem rippen zu lassen, der sie wirklich will. Akzeptiere diese Tatsache und fahre mit deinem Leben fort.
Wenn es einen Weg gibt, dies zu verhindern, gibt es im Grunde einen Weg, dies zu umgehen.
goodguys_activate
2013-07-05 16:13:00 UTC
view on stackexchange narkive permalink

Schützen Sie den Teil der Site, den Sie schützen möchten, mit einem Benutzernamen und einem Passwort. Weisen Sie dann nur Personen einen Benutzernamen und ein Kennwort zu, die eine NDA (oder eine ähnliche) unterschreiben, die besagt, dass sie keine Informationen von Ihrer Website extrahieren oder kopieren.

Ein weiterer Trick besteht darin, alle Ihre Inhalte von AJAX zu laden ... und die AJAX-Daten-URL aus sich ändernden Pfaden (z. B. ~ / todays-date) laden und mit Javascript synchronisieren. Selbst wenn jemand Ihre Inhalte herunterladen würde, wären die Daten innerhalb von 24 Stunden veraltet.

Selbst dann hindert nichts einen entschlossenen erfahrenen Angreifer daran, eine Offline-Kopie zu erhalten. Sie können es nur schwieriger machen es lohnt sich also nicht.

Um fair zu sein, muss es nicht AJAX sein. Alle dynamisch generierten Inhalte, unabhängig von der zugrunde liegenden Technologie, funktionieren auf die gleiche Weise. Der Angreifer kann problemlos nur eine Momentaufnahme seiner Ausgabe kopieren, während auf das Backend (Anwendung, Datenbank, ...), das an der Generierung dieser Inhalte beteiligt ist, nicht zugegriffen werden soll an einen nicht autorisierten Schauspieler auf andere Weise.
"NDA (oder ähnliches), das besagt, dass keine Informationen von Ihrer Website extrahiert oder kopiert werden." - Das ist lächerlich. Wie werden Sie einen solchen Vertrag durchsetzen? Werden Ihre Benutzer dies tolerieren?
@Freiheit Das OP sagt nicht, ob er eine öffentliche Site oder eine kleine B2B-Site für Profis hat. Wenn das Publikum klein ist, kann er es mit Identifikation usw. ansprechen. Wie setzen Sie es durch? Es gibt kostenpflichtige Dienste, die auf anderen Websites nach Urheberrechtsdiebstahl suchen. Steganographie kann auch verwendet werden, um Verstöße auf der Basis von Benutzernamen oder IP zu verfolgen.
TildalWave
2013-07-05 19:15:45 UTC
view on stackexchange narkive permalink

Wie @Adnan bereits in seiner Antwort ausgeführt hat, gibt es wirklich keine Möglichkeit, eine entschlossene Person daran zu hindern, Schnappschüsse Ihrer Website zu kopieren. Ich habe hier das Wort Schnappschüsse verwendet, weil solche Inhaltsschaber (oder Erntemaschinen ) wirklich kopieren. Sie haben keinen Zugriff auf Ihr Backend (oder sollten es zumindest nicht), in dem die Inhalte Ihrer Website tatsächlich generiert und dem Endbenutzer angezeigt werden. Das Beste, was sie tun können, ist, die Ausgabe zu kopieren, die Sie in einem solchen generieren können Möglichkeit, die Zeit zu ändern oder sich an den beabsichtigten Empfänger anzupassen (DRM-Schemata, Wasserzeichen, ...), wie @ makerofthings7 in seiner Antwort ausgeführt hat.

So viel darüber, was bereits beantwortet wurde. Aber es gibt eine Sache an dieser Bedrohung, die meiner Meinung nach in der genannten Antwort noch nicht gut behandelt wurde. Das meiste derartige Scraping von Inhalten wird nämlich von opportunistischen und automatisierten Webcrawlern durchgeführt , und wir sehen gezielte Angriffe viel seltener. Na ja, zumindest in Zahlen - ertrage es mit mir.

Diese automatisierten Crawler können mithilfe verschiedener WAFs recht effektiv auf die schwarze Liste gesetzt werden (einige verwenden möglicherweise sogar Honeypots, um die Bedrohungen auf heuristische Weise zu ermitteln ), die die Datenbank der auf der schwarzen Liste stehenden Domains (CBLs oder Community Ban Lists , DBLs oder Domain Block Lists , DNSBL oder DNS-basierte Blackhole-Listen auf dem neuesten Stand halten , ...) wo solche automatisierten Inhaltsschaber arbeiten. Diese WAFs verweigern oder gewähren den Zugriff auf Ihre Inhalte, die Webanwendungen bereitstellen, basierend auf drei Hauptansätzen:

  • Deterministisches Blacklisting : Hierbei handelt es sich um Erkennungen, die auf den Merkmalen von Webanforderungen basieren, die Content Scraper stellen. Einige davon sind: Ursprungs-IP-Adresse anfordern, Reverse DNS-aufgelöster Remote-Hostname, Weiterleitungsbestätigte Reverse DNS-Suche ( siehe Erläuterung in einer meiner Fragen hier), Benutzeragentenzeichenfolge, Anforderungs-URL ( Ihre Webanwendung könnte beispielsweise eine Honeytrap-URL-Adresse ausblenden, der ein Inhaltsschaber in einer seiner Antworten folgen könnte, nachdem festgestellt wurde, dass die Anforderung nicht von einer Adresse auf der Whitelist stammt, z. B. von legitimen Suchmaschinen-Crawlern / Spinnen.) und andere Fingerabdruckinformationen im Zusammenhang mit automatisierten Webanfragen.

  • Heuristische Blacklisting : Auf diese Weise können Sie eine Bedrohung entweder durch Gewichtung der Parameter von a ermitteln einzelne Webanforderung, die im deterministischen Ansatz beschrieben wird (Anti-Spam-Filter verwenden einen ähnlichen Ansatz basierend auf der Berechnung der Bayes'schen Wahrscheinlichkeit) oder durch Analyse mehrerer Webanforderungen, z. B.: Anforderungsrate, Anforderungsreihenfolge, Anzahl der illegalen Anfragen, ... , mit deren Hilfe festgestellt werden kann, ob die Anfrage von stammt ein realer und beabsichtigter Benutzer oder ein automatisierter Crawler.

  • Externe DNSBL / CBL / DBLs : Ich habe bereits erwähnt, dass Sie sich auf externe DNSBL / CBL verlassen / DBLs (z Project Honey Pot, Spamhaus, UCEPROTECT, ...), von denen die meisten tatsächlich viel nützlicher sind, als nur Spammer und Spammer im Auge zu behalten Spambot infizierte Hosts und halten eine Art von Straftat (z. B. Forum-Spammer , Missbrauch der Crawling-Rate ) über IP-Adressen, Hostnamen und CIDR Bereiche, ... in Blacklists veröffentlichen sie auch. Einige WAFs bieten die Möglichkeit, eine Verbindung zu diesen Datenbanken herzustellen, sodass Sie nicht mehr von demselben Akteur angegriffen werden müssen, der möglicherweise bereits für dieselbe erkannte Aktivität auf einem anderen Webserver auf die schwarze Liste gesetzt wurde.

Nun muss eines ganz klar gesagt werden - keine dieser Methoden kann als kugelsicher angesehen werden! Sie entfernen die meisten beleidigenden Webanfragen, was für sich genommen wertvoll ist, und ermöglichen es Ihnen, sich besser auf diejenigen zu konzentrieren, die schwerer zu erkennende Straftäter sind, die Ihren Schutz irgendwie umgangen haben.

Es gibt natürlich unzählige Techniken für die automatische Erkennung von Crawlern / Content Scrapern (und ihre eigenen Gegenmaßnahmen - Techniken zur Vermeidung von Erkennung), die ich hier nicht beschreibe, noch alle möglichen WAFs und ihre Fähigkeiten auflisten, ohne Ihre Geduld zu testen oder die Grenzen des Zwecks dieser Q&A zu erreichen . Wenn Sie mehr darüber erfahren möchten, welche Techniken eingesetzt werden können, um solche unerwünschten Besucher abzuwehren, empfehlen wir Ihnen, die Dokumentation zu den Projekten OWASP Stinger und OWASP AppSensor durchzulesen


Zum Hinzufügen bearbeiten : Vorschläge von HTTrack-Autoren können in den häufig gestellten Fragen zum HTTrack-Website-Kopierer gelesen werden: So begrenzen Sie Netzwerkmissbrauch - Missbrauchs-FAQ für Webmaster Dokument und die Gründe, warum eine einzelne deterministische Erkennungsmethode nicht funktioniert (abgesehen davon, dass beleidigende IP-Adressen nachträglich oder aufgrund der Erfahrung anderer Honeynets auf die schwarze Liste gesetzt werden), wenn der Gegner den -Benutzeragenten der Spinne verschleiern soll -String, indem Sie ihn auf einen der vielen User-Agent-Strings realer und legitimer Webbrowser setzen und robots.txt -Anweisungen nicht respektieren, wird durch einen Blick in das HTTrack-Benutzerhandbuch deutlich. Um Ihnen das Lesen zu ersparen, enthält HTTrack einfache Konfigurations- und Befehlszeilenflags, damit es im Stealth-Modus funktioniert und für einfachere Erkennungstechniken genauso harmlos wie jeder andere legitime Benutzer erscheint.

Wenn eine schwarze Liste wirklich so nützlich wäre, würde Google sie verwenden, anstatt einfach den Zugriff auf ihre google.maps zu beschränken. Unabhängig davon, wie gut Sie Ihre schwarze Liste erstellen, werden Sie letztendlich legitime Benutzer erschweren und sogar entfremden. Übrigens: Geld zu verdienen war nicht das Hauptziel von Google (nicht, dass sie kein Geld mögen), sondern die Begrenzung des Missbrauchs (automatisierte Datenerfassung). Und selbst Nutzungsbeschränkungen lassen sich leicht umgehen - verschiedene Benutzer-IPs einmal. So steht @CodesInChaos Kommentar.
@Jeffz - YMMV und ist natürlich anwendungsspezifisch. Trotzdem sehe ich die Relevanz Ihres Kommentars nicht. Ich (und viele andere) haben bereits Ratenbegrenzungen oder andere zeit- / kundenbasierte Quoten als mögliche Möglichkeit zur Abwehr von Inhaltsdiebstahl erwähnt. Und natürlich kann die Empfindlichkeit der schwarzen Liste dynamisch sein, und Einträge können basierend auf den von mir beschriebenen Ansätzen automatisiert werden. Ich bin anderer Meinung - Blacklisting ist nützlich, aber natürlich in begrenztem Umfang. Bitte lesen Sie zumindest die fett gedruckten Teile meiner Antwort. Sie werden vielleicht bemerken, dass ich bereits erwähnt habe, dass sie kaum als kugelsicher angesehen wird. Aber es wird helfen! ;)
Tom Leek
2013-07-05 19:00:33 UTC
view on stackexchange narkive permalink

Alles, was der menschliche Benutzer sieht , kann er aufzeichnen. Wie @Adnan hervorhebt, ist dies ziemlich einfach und kann automatisiert werden.

Einige Websites haben jedoch noch einen relativen Erfolg bei der Verhinderung von Massenschlürfen. Betrachten Sie beispielsweise Google Maps. Viele Menschen haben gelegentlich versucht, hochauflösende Karten großer Gebiete durch Skripterstellung wiederherzustellen. Einige haben es geschafft, aber die meisten wurden von Googles Verteidigung gefangen. Es kommt daher vor, dass es schwierig ist, einen automatischen Downloader zu erstellen, der sich aus Sicht des Servers so verhält, als ob er unter menschlicher Kontrolle wäre. Menschen haben alle Arten von Latenzen und Nutzungsmustern, die ein kluger Systemadministrator bemerken und überprüfen kann.

Ähnliche Tricks werden beispielsweise bei Stack Exchange ausgeführt. Wenn Sie versuchen, den Zugriff auf die Website zu automatisieren, werden Sie bald auf eine Seite mit einem CAPTCHA weitergeleitet.

Letztendlich ist diese Art der Sicherheit nicht sehr zufriedenstellend, da der Verteidiger und Die Angreifer sind aus gleichen Gründen: Es ist List gegen List. Das ist also teuer: Es erfordert Denken und Wartung. Einige Websites tun dies jedoch trotzdem.

Eine generische Möglichkeit für Angreifer, Sicherheitsmaßnahmen gegen die Automatisierung zu umgehen, besteht darin, das Schlürfen mit tatsächlichen Menschen zu "automatisieren". In einigen Ländern können sehr billige menschliche Arbeitskräfte eingestellt werden.

Oder stellen Sie Leute ein, um die CAPTCHAs zu lösen
FWIW, wir setzen auch beleidigende IPs auf die schwarze Liste (bei Stack Exchange).
@Sklivvz Was für ein Idiot versucht SE zu kratzen, wenn er nur den ohnehin zur Verfügung gestellten Dump herunterladen könnte?
@TobiasKienzler die Art von Idiot, die es einfacher findet, einfach eine Kopie der Site neu zu gestalten, anstatt die gesamte Präsentationsebene zu schreiben ... :-)
Nick
2013-07-05 18:32:05 UTC
view on stackexchange narkive permalink

Ich würde das, was @Adnan sagt, qualifizieren, um hinzuzufügen, dass es zwar im Allgemeinen keine Möglichkeit gibt, das Auswaschen von Websites im Laufe der Zeit zu verhindern, ein bestimmtes Tool jedoch möglicherweise ein Verhalten aufweist, das mit einiger Sicherheit mit einer gewissen Menge erkannt werden kann von Anfragen wurden gestellt. Die Reihenfolge, in der auf URLs zugegriffen wird, kann deterministisch sein, z. B. Tiefe zuerst, Breite zuerst, aufsteigend oder absteigend in alphabetischer Reihenfolge, Reihenfolge, in der sie im DOM angezeigt wurden, und so weiter. Das Intervall zwischen Anforderungen kann ein Hinweis darauf sein, ob der Agent einen Javascript-Code (außer NoScript und ähnlichem) erfolgreich ausgeführt hat, die Clientunterstützung für die Browser-Leistungs-API, die Zeit zwischen Anforderungen im Verhältnis zur Seitenkomplexität und ob ein logischer Fluss zwischen Anforderungen besteht oder nicht Anfragen. Wenn ein Website-Leacher dies nicht berücksichtigt, haben Sie möglicherweise eine Chance. Die Überprüfung von Benutzeragenten sollte nicht effektiv sein, da ein guter Leacher vorgibt, ein bekannter Bot zu sein. Wenn Sie also nicht auch Google und andere Suchmaschinen ausschließen möchten, ist die Kenntnis der von Suchmaschinen verwendeten IPs hilfreich.

jsedano
2013-07-05 19:56:16 UTC
view on stackexchange narkive permalink

Erstens können Sie nur verhindern, dass Ihre Website kopiert wird, indem Sie sie nur für Sie öffentlich machen.

Sie können versuchen, die Leute davon zu überzeugen, dies zu tun Rechtlich bedeutet, ich bin kein Anwalt, daher weiß ich nicht, welche Schritte Sie unternehmen sollten. Wenn Ihr Inhalt original ist, können Sie das Urheberrecht oder ähnliches einschränken.

Ich denke, wenn Sie befürchten, dass Ihre Website kopiert wird, muss es sich um eine wirklich, wirklich, wirklich großartige Website handeln.

A L
2013-07-06 05:42:31 UTC
view on stackexchange narkive permalink

Kurze Antwort, nein, wenn der Benutzer eine Seite lädt, kann der Benutzer HTML durch Anzeigen der Quelle kopieren.

Wenn der Website-Kopierer über einen bestimmten Benutzeragenten verfügt, können Sie diesen blockieren. Weitere Informationen finden Sie unter Stapelaustausch.

Eine andere Lösung könnte darin bestehen, eine Flash-Webseite zu erstellen. Diese sind sowieso schwer von Hand zu kopieren.

Andernfalls würde ich alles in ein Verzeichnis mit eingeschränktem Zugriff stellen, das nur serverseitige PHP-Skripte abrufen können. Wenn die Seite dann mit vielen Includes erstellt wurde (eines für eine Navigationsleiste, eines für Header, eines für Javascript, eines für Footer, eines für Body Content), erstellen Sie ein anderes Verzeichnis von PHP-Dateien, die das geschützte Verzeichnis mit Includes lesen, und machen Sie dann eine AJAX, die diese PHP-Dateien dynamisch lädt. Es würde es für alles schwierig machen, es zu kopieren, ohne das JavaScript zu rendern (obwohl ich nicht weiß, ob dies die Software oder eine Person mit einem Live-Code-Inspektionstool stoppen würde.

Oder Sie können eine Art hinzufügen von der Überprüfung durch den Menschen auf Ihrer Site, sodass ein geschütztes PHP-Verzeichnis nicht aufgerufen wird, es sei denn, der Benutzer klickt ausdrücklich auf ein DOM-Objekt ohne Link (wie eine Zeile mit der Aufschrift "Hier eingeben"), das das Laden des Inhalts auslöst.

Tobia
2013-07-06 06:17:38 UTC
view on stackexchange narkive permalink

Haftungsausschluss: Dies ist eine böse Antwort. Ich kann keines der folgenden Dinge gutheißen.


Moderne Browser können generische (Turing-vollständige) Berechnungen mit Javascript und möglicherweise auf andere Weise durchführen. Selbst die grundlegenden HTML + CSS-Rendering-Engines sind unglaublich ausgefeilte Software, mit der Inhalte auf verschiedene Weise angezeigt (oder ausgeblendet) werden können. Wenn dies nicht ausreicht, stellen alle modernen Browser grafische Grundelemente zur Verfügung, z. B. über SVG und Canvas, und ermöglichen das Herunterladen benutzerdefinierter Schriftarten zum Rendern von Text.

Wenn Sie all dies zusammenfügen, und einige weitere, Sie werden feststellen, dass zwischen dem Quellcode der Site und den Pixeln, aus denen die Buchstaben und Wörter bestehen, die der Benutzer lesen kann, mehrere Ausführungsebenen bestehen.

Alle diese Ausführungsebenen können verschleiert und / oder verschleiert werden ausgenutzt.

Sie können beispielsweise Markups generieren, die wenig oder gar keine Ähnlichkeit mit der Grafikausgabe haben, um das Betrachten der HTML-Quelle Ihrer Website zu einer sinnlosen Übung zu machen. Sie können ein HTML-Tag pro Buchstabe verwenden und diese mit der kreativen Verwendung von float: und position: neu anordnen, einige davon mit komplexen, generierten CSS-Regeln ausblenden und einige hinzufügen Weitere, die nicht vorhanden waren, mit CSS-generierten Inhalten.

Sie können eine Schriftart erstellen, die eine benutzerdefinierte Zuordnung zwischen Zeichencodes und Glyphen verwendet, sodass das Kopieren und Einfügen Ihrer Inhalte zu völligem Müll oder sogar zu Müll führt Schimpfwörter! Sie können Buchstaben in zwei oder mehr Teile teilen und Unicode-Kombinationszeichen verwenden, um sie wieder zusammenzusetzen. Sie können dies alles mit einem dynamischen Generator tun und für jede HTTP-Anforderung ein neues zufälliges Meisterwerk der Verschleierung erstellen.

Sie können ein Programm schreiben, das komplexe Javascript-Algorithmen erstellt, die beim Ausführen auf dem Client einige erforderliche Teile des Puzzles ausfüllen, sodass ohne Javascript-Unterstützung und eine angemessene Menge an Client-CPU-Zeit allein das Markup wäre nutzlos. 50 ms moderne CPU-Zeit werden von den meisten nicht bemerkt und reichen aus, um einige ziemlich böse Algorithmen auszuführen.

Bonuspunkte, wenn Sie versuchen, Ihre eigene verschleierte Website mit einem kopflosen Browser zu kratzen, um ein vollständiges CSS und zu haben Javascript-Stapel. Versuchen Sie dann, Wege (oder Heuristiken) zu finden, um einen echten Browser vom kopflosen zu unterscheiden. Fügen Sie dann einige Fallen in den generierten Javascript-Code ein, sodass der Algorithmus, wenn er in den Fall eines kopflosen Browsers fällt, in eine Endlosschleife gerät oder den Browser zum Absturz bringt oder Schimpfwörter und Anfälle auf dem Bildschirm erzeugt

Diese sind mir auf den Kopf gestellt, es gibt (zählbar) unendlich viele andere Möglichkeiten, mit den Computern der Leute zu ficken.

Jetzt sei ein guter Junge / Mädchen und nimm deine blaue Pille: - )

Was habe ich gerade gelesen? Tatsächlich hat die Verschleierung, Verwendung von JavaScript und anderen _wicked algo_ kaum einen Vorteil darin, die Ausgabe, die Website-Harvester interpretieren können, zu verbergen und / oder auf andere Weise zu verfälschen. Diese sind heutzutage unglaublich fortschrittlich und nicht weniger kompetent als die besten Browser da draußen. Nehmen wir zum Beispiel das Chromium-Projekt, eine umfassende Browserkomponente, die so kompetent ist wie Chrome selbst (was es tatsächlich ist, abzüglich der Augenweide) und die problemlos in jede Web-Scraping-Anwendung integriert werden kann. Also wird der Schnappschuss auf _DOM ready_ gemacht, kein Problem.
Sie können sich David Madores Buch der Unendlichkeit ansehen, ein kleines CGI-Programm, das unendlich viele Seiten generiert, um Massen-Downloader zu bestrafen, die robots.txt nicht respektieren
@loreb - Ich verstehe es ehrlich gesagt nicht. Ihre Website wird also von einem in der Cloud gehosteten Crawler abgekratzt, der Ihre "robots.txt" nicht respektiert, und Sie führen als Strafe für diesen Crawler eine selbstverschuldete DDoS auf Ihrer Website durch? Wie wird das funktionieren? Sie erkennen, dass Sie die Serverlast nur unnötig erhöhen und ihre Ressourcen (CPU, Speicher, Bandbreite, ...) erschöpfen würden, wenn der Crawler verteilt ist, scheinbar unbegrenzte Bandbreite hat und sich nicht um seine Crawling-Rate kümmert? Sie sollten die Anforderungen so schnell wie möglich löschen und nicht mehr arbeiten.
@TidalWave sicher, das Buch der Unendlichkeit ist ein Scherzprogramm, sowohl in der Einstellung (Bestehen darauf, dasselbe bedeutungslose "Buch" zu reproduzieren, und nicht nur in zufälligen Inhalten) als auch in der Praxis, genau wie Sie es beschrieben haben. Abgesehen davon, wenn ich meinen Vorschlag ernst nehmen würde, würde ich ihn verteidigen, indem ich feststelle, dass (1) das OP HTTrack so erwähnte, dass einzelne Benutzer eine Website anstelle eines verteilten Crawlers massenweise herunterladen und dass (2) Man könnte das Buch der Unendlichkeit verwenden, um ein Tarpit zu generieren, ähnlich wie bei OpenBSDs Spam.
Andy
2013-07-06 18:26:07 UTC
view on stackexchange narkive permalink

Zunächst einmal, wie andere gesagt haben - alles, was Sie sehen können, können Sie mit verschiedenen Methoden kopieren. Es hängt davon ab, warum Sie verhindern möchten, dass Ihre Website kopiert wird. Die effektivste Methode ist jedoch wahrscheinlich das Hinzufügen von Wasserzeichen, damit jeder weiß, woher sie stammt. Vielleicht würde sogar eine höfliche Mitteilung, in der die Leute gebeten werden, Ihre Website nicht zu kopieren, nicht fehlen.

Wenn Sie jedoch zu Ihrer ursprünglichen Frage zurückkehren und verhindern, dass Software die Website kopiert, glaube ich, dass CloudFlare über eine Webanwendung verfügt Firewall. Ich weiß mit Sicherheit, dass der Acunetix Web Vulnerability Scanner keine Website scannt, die CloudFlare verwendet. Es ist eine kostenlose Lösung und sollte auch dazu beitragen, Ihre Website zu beschleunigen.

Es gibt jetzt jedoch eine narrensichere Lösung, und alles kann umgangen werden. Das Beste, was Sie tun können, ist, eine Kombination der Antworten hier zu verwenden, je nachdem, wie dringend Sie Ihre Website schützen müssen / möchten. Der beste Rat ist jedoch, wenn Sie nicht möchten, dass es kopiert wird, lassen Sie es nicht zu.

PythonIsGreat
2013-07-05 18:26:52 UTC
view on stackexchange narkive permalink

Auch AJAX mit Datumsparametern kann dupliziert werden. Ich habe Websites mit starkem AJAX mithilfe von GET / POST-Parametern abgekratzt. Wenn ich den Browser wirklich emulieren muss, kann ich einfach Selen oder ähnliches verwenden. Ich kann immer einen Weg finden, eine Site zu kratzen, wenn ich es wirklich wollte. Captcha ist wahrscheinlich das Schwierigste. Selbst dann gibt es den Captcha-Scharfschützen und andere Module, die in diesen Bereichen helfen.

Java D
2013-07-06 14:19:50 UTC
view on stackexchange narkive permalink

Sehen Sie sich diese Links an, um eine Lösung zu erhalten :)

Wie stoppe ich HTTrack?

Verwenden Sie robots.txt, um dies zu verhindern Website vor dem Rippen?

ODER

Der einfachste Weg besteht darin, die Browser-ID zu identifizieren, die Ihre Seite durchsucht, wenn es sich um eine htttrack-Blockierung handelt (Sie müssen Ihren Server konfigurieren oder verwenden Ihre Programmierkenntnisse, um die verschiedenen Seiten entsprechend zu laden)

Danke ..

HTTrack ist eine Open Source-Anwendung. Sie können die Quelle leicht ändern und jeden Mechanismus überschreiben, der "robots.txt" berücksichtigt.
Es gibt keine einzige deterministische Methode, mit der HTTrack-Clients identifiziert werden können, wenn sie ihre Signatur verschleiern und die Anweisungen "robots.txt" nicht respektieren. Nicht ohne auf viel fortgeschrittenere Nachweismethoden zurückzugreifen. Wenn wir [HTTrack-Benutzerhandbuch] (http://www.httrack.com/html/fcguide.html) zitieren, erhalten wir diese beiden Gründe, warum Ihr Vorschlag nicht funktioniert: _ "Das Feld" Benutzeragent "kann so eingestellt werden, dass es angibt, was auch immer wird an den Server "_ für Ihren Vorschlag zur Verwendung von UA ​​und _" `sN` nach` robots.txt` und Meta-Robots-Tags gewünscht (`0` = nie,` 1` = manchmal, * `2` = immer) "_ zum Blockieren in` robots.txt`.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...