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.

Verhindern des Auslesens von Usernamen bei WordPress

Durch das Anhängen von /?author=1, /?autor=2 etc oder auch /?blabla&author=1 etc bekommt ein Angreifer den/die aktiven Benutzernamen in der URL zu sehen – das ist schon die halbe Information für einen Hacker-Angriff. Wie das leicht über die .htaccess-Datei verhindert werden kann, steht hier beschrieben:

RewriteCond %{QUERY_STRING} author=\d
RewriteRule ^ /? [L,R=301]

Can I prevent enumeration of usernames on my wordpress site? I can see users at the moment using the WPScan tool.

Quelle:
Can I Prevent Enumeration of Usernames?