Veröffentlicht am

Zugriff auf eigene Bilder von fremder Domain sperren

Bilderklau ist im Internet leider allzu verbreitet! Wenn aber nicht einmal eine Kopie von dem Bild gemacht wird, sondern das Originalbild direkt im fremden Quelltext eingebunden wird, hat der Seitenbetreiber des Originalbildes nicht nur unnötig höheren Traffik, sondern auch noch eine höhere Serverlast zu bemängeln.

Um diese Art des Bilderklaus zu unterbinden, kann eine kleine RewriteRule z.B. in einer .htaccess Datei eingesetzt werden:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Was passiet hier nun?

Wenn der Referer leer ist, oder nicht die eigene Domain ist, dann wird der Zugriff auf alle Dateien mit der Endung .gif, .jpeg, .jpg oder .png verboten. Wenn leere Referer zugelassen werden sollen, einfach die erste Zeile mit RewriteCond entfernen (nicht jeder Browser sendet den Referer (korrekt) mit).

Weitere Domains zulassen

Um weiteren Domains den Zugriff auf die Dateien zu erlauben, muss diese einfach in einer RewriteCond hinzugefügt werden.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?andere-eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?erlaubte-fremde-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Andere Anwendungen/Dateiendungen

Die Liste der zu sperrenden Dateien, bzw. Dateiendungen kann einfach ergänzt werden (letzte Zeile, RewriteRule), so lassen sich dann z. B. auch PDF/DOC/etc. Dateien sperren.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png|pdf|doc)$ [F,NC]

Nicht sperren, sondern alternativen Inhalt zeigen

Statt den Zugriff zu sperren, kann man auch einen alternativen Inhalt/alternative Datei ausliefern. Dies könnte z.B. ein anderes Bild/Dokument sein, in dem auf den Datenklau hingewiesen wird. Diese Methode spart zwar keinen Traffik oder Serverlast, kann aber auch wirksam sein ;)

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ /do-not-steal.gif [NC]

Veröffentlicht am

neues Zend Framework Rewrite

Seit einiger Zeit findet sich im Quickstart Tutorial (englisch) des Zend Frameworks eine neue verbesserte RewriteRule:

Wird das mod_rewrite Modul unter Apache verwendet, wird empfohlen, eine .htaccess Datei mit folgendem Inhalt im Hauptverzeichnis der Domain (DocumentRoot) abzulegen:

# public/.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

Was passiert hier nun?

Die Umgebungsvariable REQUEST_FILENAME beinhaltet laut Apache-Dokumentation den vollen Pfad zur Datei oder zum Script entsprechend der Anfrage (z.B. /var/www/domain.tld/public/css/style.css).

Die drei Bedingungen (RewriteCond) prüfen nun, ob diese/s Datei/Script eine tatsächlich existierende Datei (s), symbolischer Link (l) oder ein Verzeichnis (d) sind. Wenn ja: leite die Anfrage unverändert durch und beachte keine weiteren Regeln ([L] = Last/Letzte Regel), also kein Rewrite und Ende der Prüfung. Wenn nein: Schreibe die Anfrage zu /index.php um. Das NC bewirkt, dass nicht zwischen Klein- und Großschreibung unterschieden wird (NC = no case-sensitive).

Besonderheit bei Deklaration der Rewrite Bedingungen/Regeln innerhalb eines VirtualHost
Die zuvor aufgezeigten Bedingungen gelten für die Deklaration innerhalb einer .htaccess Datei. Gleichermaßen kann das Rewriting natürlich auch innerhalb einer VirtualHost Definition deklariert werden.

Jedoch ist bei einer Deklaration innerhalb eines VirtualHosts zu beachten, dass die Umgebungsvariable REQUEST_FILENAME hier nicht den vollen, sondern den relativen Pfad vom DomainRoot beinhaltet.

In den Bedingungen muss daher die Umgebungsvariable DOCUMENT_ROOT zusätzlich vorangestellt werden!
Der Rest bleibt erhalten.

# innerhalb VirtualHost Deklaration
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -s [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -l [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

Veröffentlicht am

E-Mail-Adressen vor Spam-Bots schützen (2) …

Aus den weiteren Tests der Artikel-Serie „Effective methods to protect email addresses from spammers“ von Dr. David R. Nadeau ziehe ich für mich folgende Resumées:

  1. E-Mail-Adresse aufteilen (Original-Artikel)
    Die E-Mail-Adresse wird in mehrere Teile geteilt/unterteilt durch Leerstellen ( ic h @ d u . d e) oder Ersetzungen (z.B. ich at du (dot) de), etc. Diese Methoden funktionieren überwiegend gut, wenn es lediglich um die Darstellung geht, und sie können beim Lesen gut verstanden werden. Besonders interessant finde ich das Hinzufügen von HTML-Kommentaren oder -Tags (z. B. ich<!–Don’t Spam –>@<!–Don’t Spam –>du.de), da diese im Browser nicht dargestellt werden und auch von Screen-Readern ignoriert werden sollten.
    Diese Methoden können jedoch nicht für einen „mailto:“ Link (href) eingesetzt werden ;(.
  2. E-Mail-Adresse per Javascript (a) oder CSS (b) einfügen (Original-Artikel)
    Für beide Methoden gilt: Die E-Mail-Adresse muss natürlich in mehrere Teile aufgeeilt werden, sonst wird sie trotzdem gefunden. (a) kann auch bei „mailto:“ Links (href) angewendet werden, (b) nicht! Sehr gute Abwehrmethoden (solange die Bots noch kein Javascript/CSS interpretieren).
    a) Die Variablen mit den E-Mail-Teilen werden per document.write() zusammengesetzt und ausgegeben. Zusätzlich kann sie z.B. durch Unicode-Zeichencodes verschleiert oder über Ver-/Entschlüsselung geschützt werden. Alternative: Die E-Mail-Adresse wird per AJAX nachgeladen.
    Hat der Benutzer Javascript deaktiviert, bekommt er allerdings gar keine E-Mail-Adresse zu sehen.
    b) Die E-Mail-Teile werden auf zwei Klassen verteilt. Die CSS-Eigenschaft „content“ wird für die „Ausgabe“ genutzt. Die meisten (aber lange nicht alle) aktuellen Browser unterstützen diese Eigenschaft, Internet Explorer 7 (natürlich) nicht. Diese Methode ist daher zu nachteilig.
  3. E-Mail-Adressen als Grafik oder Flash einfügen (Original-Artikel)
    Die E-Mail-Adressen (oder Teile davon) werden in einer Grafik oder in einem Flash in die Seite eingebunden (nicht die E-Mail-Adresse in das „title“/“alt“ Attribut oder Dateinamen schreiben!). Sehr gute Abwehrmethoden. Flash-Textinhalte können jedoch zunehmend auch von Suchmaschinen indiziert werden, was wiederum dann auch Spam-Bots können.
    Beide Methoden können jedoch nicht für einen „mailto:“ Link (href) eingesetzt werden ;(. Zudem können sie auch nicht von Screenreadern gelesen werden oder in die Zwischenablage kopiert werden. Die Ladezeit der Seite verringert sich. Bilder können nicht entsprechend der Textgröße dynamisch skaliert werden. Für Flash ist ein Plug-In notwendig.
  4. Seiten mit E-Mail-Adressen verstecken (Original-Artikel)
    Keine (wirklich keine!) Links zu Seiten mit E-Mail-Adressen dürfen existieren, bzw. von Bots lesbar sein. Werder auf den eigenen als auch nicht auf anderen Seiten (z.B. Google)! Dies kann durch Javascript-Links oder Links in Flash gelöst werden. Alle weiteren im Artikel vorgestellten Möglichkeiten waren Null effektiv. Sehr hoher administrativer Aufwand, zudem Nachteile der Verlinkung bei deaktiviertem Javascript oder fehlendem Flash-Plug-In!
  5. Für Spammer Zugriff auf Seiten blockieren (Original-Artikel)
    a) Anhand der IP-Adresse oder des User-Agent wird ein Spam-Bot identifiziert. Beides ist nicht/schwer wartbar: IP-Adressen wechseln ständig und der User-Agent frei verfälscht werden kann.
    b) Seiten werden mit Zugangsdaten geschützt, die dem Besucher mitgeteilt werden. Alle User müssen sich authentifizieren, das ist nicht besonders benutzerfreundlich. Wird das Login kommuniziert, können manche Spam-Bots einen Auto-Login machen.
  6. Online-Kontaktformulare statt E-Mail-Adressen (Original-Artikel)
    Statt der E-Mail-Adressen darzustellen, werden Online-Kontaktformulare angeboten. Kein Spam-Bot kann die Adresse somit sehen (steht je nirgends) aber …
    Inzwischen sind genügend andere Spammer unterwegs, die das Kontakt-Formular nutzen, um dem Betreiber den Spam direkt zu senden – Kontaktformular ausfüllen, absenden, fertig. Dagegen können wiederum so genannte CAPTCHA eingesetzt werden. Zudem gibt es möglicherweise gesetzliche Regelungen, die die Angabe von E-Mail-Adressen z.B. im Impressum vorschreiben.

Gesamtresumee:
Die meisten gängigen Methoden sind gar nicht (mehr) effektiv. Weitere sind wohl nicht mehr lange effektiv, denn Spam-Bots werden nachgerüstet (insbesondere bei den unter 1 vorgestellten Methoden). Andere schränken das Nutzerverhalten/Zugänglichkeit stark ein oder funktionieren nicht in allen Browsern. Javascript scheint eine gute Methode zu sein, der Benutzer darf es aber nicht deaktivieren. CSS könnte zu einer erfolgreichen Methode werden, wenn alle Browser es unterstützen.

„The best way to protect an email address from spammers is to not publish it.“, das gilt für das Verhalten überall im WWW, nicht nur auf der eigenen Site!

Fight against Spam!