Abmahn-Falle Google Fonts

Es scheint wieder eine neue Abmahnwelle anzurollen. Sie ist nicht neu, aber besonders hinterhältig. Der Hintergrund ist, dass Google eine riesige Menge Schriften (Fonts) zur kostenlosen Verwendung anbietet, indem sie einfach in der eigenen Website verlinkt und beim Laden der Seiten online bezogen werden. Dabei werden – so funktioniert eben das Internet! – neben der eigenen IP-Adresse auch einige anonyme Daten des Browsers zu Google übertragen. Das stößt den Anwälten unter den Datenschützern (Stichwort: DSGVO, Datenschutz-Grundverordnung) auf und sie wittern Profit. Denn dieser Datenübertragung stimmt der Nutzer in der Regel nicht bewusst zu. Was für ein Irrsinn! Es werden dann Abmahnungen im niedrigen dreistelligen Bereich verschickt, die meist schnell bezahlt werden, weil sich ein Rechtsstreit deswegen nicht lohnt. Das bei 1000 „Klienten“ ergibt ein hübsches Sümmchen.

Insbesondere bei Websites mit WordPress, bei deren verwendetem Theme die verwendete Schrift (Font) von Google oft fest einprogrammiert ist, ist das unter Umständen schwer zu beheben. Es gibt Plugins, die sowas beheben sollen, was aber aus meiner Erfahrung nicht geht und sogar in einer „weißen Seite“ enden kann.

Ist die Website vorhanden – egal ob konventionell oder z.B. WordPress -, muss man zunächst herausfinden, welche Google-Fonts verwendet und tatsächlich online bezogen werden. Nur um diese geht es in diesem Zusammenhang, alle anderen Techniken werden jetzt nicht betrachtet. Das lässt sich zum Beispiel mit diesem Tool machen:

[1] https://fonts-check.de/

Gibt es „schädliche“ Fonts, werden die aufgelistet. Oft erscheinen dort mehrere Versionen, also Dateiformate – entscheidend ist nur der darinsteckende Name, z.B. „Roboto“. Erscheint nichts, ist alles gut.

Konventionelle Website

Hat man eine konventionelle Website, die man selbst geschrieben hat, stehen die Aufrufe der Google-Fonts im Head-Bereich in einer Form wie

<link href=“https://fonts.googleapis.com/css?family=Roboto’ rel=’stylesheet“>

Diese Zeilen werden auf allen Seiten gelöscht. Stattdessen wird in die normalerweise immer vorhandene zentrale CSS-Datei der Code eingefügt, den man sich mit dem Tool

[2] Google Webfonts Helper (google-webfonts-helper.herokuapp.com/fonts)

(leider nur in Englisch verfügbar!) komfortabel zurechtmachen lassen kann. Dabei kommen solche recht komplexen Styles heraus, die man dann den entsprechenden Selektoren (auch *) zuweisen kann:

* {
    @font-face {
      font-family: 'Roboto';
      font-style: normal;
      font-weight: 400;
           url('../fonts/roboto-v30-latin-regular.woff2') format('woff2'),
           url('../fonts/roboto-v30-latin-regular.woff') format('woff'),
           url('../fonts/roboto-v30-latin-regular.ttf') format('truetype'),
           url('../fonts/roboto-v30-latin-regular.svg#Roboto') format('svg');
    }
}

Die Zeilen für den IE 8/9 habe ich gleich weggelassen, die braucht keiner mehr.

Website mit WordPress

Hier gibt es mehrere Möglichkeiten. Die einfachste ist, dass das verwendete Theme das „Verstecken“ benutzter Google-Fonts gleich selbst mitbringt oder gar keine verwendet.

Etwas aufwändige kann es werden, wenn es welche verwendet, die aber fest im Theme kodiert sind. Dann kann man nur versuchen, das Verstecken mit einem geeigenten Plugin zu bewerkstelligen wie zum Beispiel „OMGF | GDPR/DSVGO Compliant, Faster Google Fonts. Easy.“ (OMGF) oder „Local Google Fonts“. Man kann auch versuchen, die Verwendung ganz abzuschalten, z.B. mit dem Plugin „Disable and Remove Google Fonts“. All das muss nicht funktionieren und kann schlimmstenfalls dazu führen, dass beim Neuladen des Backends oder der Website selbst nichts mehr erscheint außer einer wenig sagenden Fehlermeldung: Dann hilf nur der beherzte Zugriff über FTP auf /wp-content/plugins und das Löschen des Verzeichnisses <plugin-name>, den man sich hoffentlich gemerkt hat… (es empfiehlt sich also ein vorheriger Blick dorthin, um den Namen zu kennen).

Fazit

Auch wenn die Abmahner für diesen unsinnigen Lapsus „nur“ etwa 300 € haben wollen, sollte man die Sache rechtzeitig beheben. Manchmal sind die Fonts überflüssig, weil sie gar keinen Gewinn gegenüber Standardschriften bringen, aber Ladezeit bewirken. Möchte man sie wegen der Ästethik haben, lohnt sich der Aufwand. Übrigens auch dann, wenn ihr Websites für Kunden macht: Man wird das Engagement loben und die 300 € lieber euch geben statt den Anwälten.


Ich bitte um Ergänzungen in euren Kommentaren! Ich werde aber kaum für alle möglichen Fälle wie exotische CMS oder E-Commerce-Sites Empfehlungen zusammentragen, dazu ist das Thema einfach zu vielfältig.

WordPress: Öffentlicher PGP-Schlüssel in Mediathek

Der öffentliche Schlüssel für die Benutzung von PGP zum Beispiel für Emails muss ja öfentlich verteilt werden können. Da es eine ziemlich lange unleserliche ASCII-Textdatei ist, empfiehlt es sich, da in Form einer Datei zum Importieren zu tun.

Wer WordPress für seine Website benutzt, wird das (wie ich hier auf der Seite Sicherheit) auf einer eigenen Seite tun und die Datei beispiel_schluessel.asc als File-Download anbieten. Dazu muss die Datei aber zunächst in die Mediathek aufgenommen werden. Und das gelingt nicht ohne weiteres, weil Textdateien wie .txt oder .asc noch hochgeladen werden können. Das sind angeblich Sicherheitsgründe – bei Texten? Okay…

Ich umgehe das auf folgende Weise. Hat man Zugriff auf das Wurzelverzeichnis seiner WordPress-Installation und damit auf wp-config.php, kann man dort folgende Zeile eintragen:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

Dann lädt man seine Datei hoch und kommentiert anschließend diese Zeile gleich wieder aus.

// define( 'ALLOW_UNFILTERED_UPLOADS', true );

Denn die Einstellung würde es in einem vielleicht vorhandenen Formular erlauben, jede beliebige Datei hochzuladen, was tatsächlich riskant wäre.

Es gibt eine ganze Reihe Plugins, mit denen man die Liste der erlaubten Dateitypen erweitern können soll. Ich habe einige hierfür ausprobiert, es hat nicht geklappt. Und es wäre auch mit Kanonen auf Spatzen geschossen wegen einer einzigen Datei, oder?

WordPress: Benutzer nicht löschen!

Dieser Tage habe ich eine schmerzliche Erfahrung machen müssen. Auf der Website eines Kunden, die ich bisher betreut hatte, waren er und ich als Benutzer eingetragen. Da ich die Website erzeugt hatte, war ich der Besitzer aller Seiten und Beiträge. Das Ziel war, die Website endgültig zu übergeben, also ohne mich als Benutzer. Also löschte ich mich, dachte mir nichts weiter, fuhrr zum Kunden, wollte ihm alles zeigen – und fiel fast vom Stuhl.

Die Website war leer. Keine Seiten, keine Beiträge, nichts. Ausreden fielen mir gerade nicht ein…

Wichtig war jetzt, dass ich einen Zugang zu phpMyAdmin beim Provider hatte oder es eine eigene Installation gab. Ich setze hier mal die Kenntnisse zur Verwendung dieses Werkzeuges voraus.

Nach einer Analyse der Datenbank-Einträge (ich hatte so einen Fall noch nicht gehabt) sah ich, dass die Inhalte zwar noch da waren, aber als mit „trash“ in der Spalte post_status und dem Anhang „__trashed“ (sowas wie blabla__trashed) in der Spalte post_title gekennzeichnet. Das ließ mich hoffen.

Zunächst änderte ich alle Einträge auf den Besitzer, der noch übrig war. In der Tabelle wp_user stehen alle User, hier war es nur noch einer. Weit vorn steht dessen ID, die merkt man sich. Sind es mehrere User, sollte es einer sein, der wenigstens Redakteur ist. Auch wenn das Ergebnis jetzt sachlich falsch wurde, habe ich also alle Posts dem gleichen User zugeordnet: In phpMyAdmin / SQl also mittels „update wp_posts set id = 3“, wenn 3 die ID des gewünschten Users ist.

Jetzt wurde es mühsam. Bei einem Projekt mit Dutzenden Seiten und Beiträgen hätte ich mich Stunden und Tage damit beschäftigen müssen. Denn wenn Seiten und Beiträge tatsächlich mal gelöscht worden wären, hätten sie sich nicht von den verbliebenen unterscheiden. So aber ist die Website ja von mir erstellt und nicht geändert worden, es gab keine gelöschten Teile. Also änderte ich nun alle Kennungen in der Spalte post_status von „trash“ auf „publish“ und entfernte die Markierungen __trashed.

Jetzt waren zumindest die Seiten und Beiträge alle wieder da! Wenn man bedenkt, dass das ja live passiert, sollte alles recht schnell gehen, damit möglichst wenig Chaos öffentlich sichtbar wird.

Die Bilder fehlten allerdings noch – die waren wohl mit gelöscht worden (wobei?). Zum Glück gab es eine Sicherung von content/upload, die Bilder konnte ich damit auch zurückspielen.

Fazit:

Lösche niemals User in einem einigermaßen lebendigen WordPress-System! Man kann User, die mal Beiträge verfasst haben und nicht nicht mehr da sind, herunterstufen auf Abonnent, dann können sie nichts mehr machen, wenn sie sich noch einloggen.

Und vor allem: Immer fleißig Datensicherungen machen! Vor allem von der Datenbank und von wp_content/upload. Ersteres geht schon mit Bordmitteln über Werkzeuge/Export (und rückwärts bei Bedarf Import)..

Abmahngefahr bei Verwendung des AMP-Plugins in WordPress

AMP steht für Accelerated Mobile Pages – eine recht neue Technologie, mit der Websites für die Mobile Anzeige auf minimale Größe (Bytes) getrimmt werden, um auf Mobilgeräte möglichst schnell und mit wenig Datenverbrauch angezeigt werden zu können. Das geht nicht ganz ohne Verluste. So verschwinden Menüs und große Bilder. Dumm nur, wenn in den Menüs die gesetzlich obligatorischen Links zum Impressum und zu den Datenschutz-Bestimmungen enthalten sind und die auch mit verschwinden!

Auf diese Weise entstehen eventuell Websites, die zumindest in der mobilen Ansicht abmahnfähig sind, ohne dass sich der Designer und Besitzer dessen bewusst sind. Ein gefundenes Fressen für die besondere Spezies der Anwälte, die darauf aus sind! Zum Glück kann man mit etwas Programmierkenntnissen abhelfen, sofern es die Struktur der Seiten gestattet.

Auf der Website der RA-Kanzlei Plutte sind der Sachverhalt und die Lösung gut beschrieben – vielen Dank!

Quelle: www.ra-plutte.de/wordpress-abmahngefahr-nutzung-amp-plugin-automattic

Sicherheitsmythos: Anmeldenamen in WordPress verstecken

Ich habe selbst schon einem meiner Beiträge auf eine Website verwiesen, wo diese Sicherheitslösung besprochen wird. Nun bin ich auf diesen Artikel von Torsten Landsiedel gestoßen, der ebenfalls lesenswert ist:

Immer wieder lese ich den folgenden Sicherheits-Hinweis für WordPress: Verstecke den Anmeldenamen! Oder Nutzer beschweren sich über die Nachlässigkeit der Core-Entwickler, dass der Nutzername preisgegeben wird. Dabei ist das kein Sicherheitsproblem. Und warum das Verschleiern viel schwieriger ist, als viele annehmen versuche ich euch hier mal zu zeigen.

Quelle: Sicherheitsmythos: Anmeldenamen in WordPress verstecken

Basisschutz: WordPress absichern

Leider ist es mir selbst in der nahen Vergangenheit zweimal „gelungen“, dass diese meine WordPress-Installation gehackt wurde. Erkannt habe ich das zunächst daran, dass die im Frontend sichtbaren Plugins nicht mehr gingen (z.B. Formular, OSM-Karte) und dann im Backend daran, dass keine Plugins mehr da waren. Diese waren als Verzeichnisse/Files zwar noch vorhanden, aber beim Blick in beliebige PHP-Files zeigte sich, dass vorn dran zusätzliche per Hex-Schreibweise (\xnn) „verschlüsselte“ PHP-Befehle eingefügt worden waren.

Ein dafür mögliches Stichword zum Suchen: „timthumbs“ www.exploit-db.com/exploits/17602.

Nun konnte ich unmöglich in tausenden Files diese Einfügung entfernen. Zum Glück funktionierte das vorletzte Backup – das letzte war ebenso kaputt. Der zitierte Artikel gibt viele Hinweise auf Möglichkeiten, seine WP-Installation zu schützen. Unbedingt lesenswert!

Quelle: Basisschutz | WordPress absichern Teil1 | Kuketz IT-Security Blog

Nachtrag: Ich habe eine Sicherung des Verzeichnisses /admin/ mittels .htaccess und .htpasswd eingeführt und seitdem ist anscheinend Ruhe mit den hackerangriffen. Jedenfalls bekomme ich nichts mehr gemeldet.

Eigene WordPress Loop mit Seitenschaltung

Ein hervorragendes Tutorial zu einem Problem, das ich mit genau dieser meiner Blog-Seite hatte: eine  komfortable Seitenschaltung in einem Template mit einem statischen Teil oben und einem dynamischen Teil mit vielen Beiträgen (eben dem Blog). Es gibt den kompletten erklärte Code, allerdings für die Freunde der englischen Sprache.

In this tutorial, I’m going to show you how to create a custom WordPress loop with pagination. We will use the WP_Query class to instantiate a new query, and display the posts with pagination.

Custom WordPress Loop With Pagination

2013 – 2015

  • ** Website für die Kanzlei Rabe Kirsche & Kollegen, Leipzig
    Verwendung des selbst entwickelten Mikro-CMS zur Bearbeitung einzelner Seiten-Abschnitte mit Hilfe von „Textschnipseln“ und tinyMCE
  • ** Browseranwendung: Dispatcher-Software für die Zusammenarbeit von Autohäusern (VW, Mercedes Benz) mit Abschlepp- und Bergungsdienst Scholz in Leipzig
    – starke Anwendung von jQuery / jQueryUI / JavaScript
    – modulare Bauweise, dadurch schnelle Anpassbarkeit an neue Kundenwünsche

Beginn des verstärkten Einsatzes von responsivem / fluidem Webdesign:

WordPress Wartungsmeldung zurücksetzen

Mancher hat sicher schon einen Schreck bekommen, wenn während eines WordPress-Updates statt der eigenen Website ein lapidares „Briefly unavailable for scheduled maintenance. Check back in a minute.“ erschien. Noch unangenehmer wird das, wenn die Website auch danach nicht wieder erscheint!

Während des Updates mindestens eines Plugins wird eine WordPress-Installation in den Wartungsmodus geschaltet  – beim Aufruf der Website erscheint obige Fehlermeldung, die eigentlich nur der Hinweis ist, doch bitte in ein paar Minuten wiederzukommen. Es kann aber passieren, dass die Wartung hängt und die Website nicht mehr erreichbar bleibt. Dann ist die versteckte Datei /.maintenance zu löschen.

Allerdings verhindert das Entfernen der Datei dauerhaft das Blockieren und die Meldung während der Updates. Ich würde also die Datei lieber nur umbenennen, z.B. in _.maintenance, um sie später wieder aktivieren zu können, wenn sich das als besser herausstellt. Es hat ja schließlich seinen Sinn.

Edit 21.8.15: Dieser Text erschien bis vor der Version 4.3 auch in der deutschen WP-Version in englisch. Jetzt steht dort „Wegen geplanter Wartungsarbeiten vorbergüehend nicht erreichbar. Bitte schau gleich noch einmal vorbei.„. EinbBisschen holprig, aber immerhin verständich :-).

Quelle:
WordPress Fehler: Briefly unavailable for scheduled maintenance. Check back in a minute.