GreenSmilies

Zähneknirschend muss ich zugeben, dass ich heute Akismet wieder angeschalten habe, lange lief es gut mit dem deaktivierten Akismet, doch heute, heute kam die Trackback-Welle! Nach gefühlten 200 Trackbacks, habe ich Akismet heute Nachmittag wieder angemacht und es hat mich so vor 1.574 weiteren Trackbacks verschont.

Ich lass es mal an, bis ich einen passenden Schutz davor gefunden habe. Hat jemand Tipps?

*Nachtrag*

Von wegen 1.574… ich hatte mich gerade gewundert, dass mir die Akismet-Statisitk einen Wert von 18.030 abgefangenen Spam-Nachrichten anzeigt. Ein Blick in meine log-Files ergab dann, dass es sogar noch mehr sind. Über 22.000 Zugriffe von der IP 92.48.121.50. Eine Abuse-Mail ist bereits raus.

Wie letztens geschrieben, hier mein Weg um die Datenbank auf utf8 umzustellen, falls man beim php/mysql Wechsel versehentlich seine Umlaute & Co geschrottet hat. So wie ich, habe ich doch alle Umlaute doppelt utf8 kodiert (siehe Screenshot am Ende). Voraussetzung ist eine Shell und phpMyAdmin. SQL-Profis brauchen letzteres natürlich nicht, aber die haben auch keine utf8-Problemchen.

1. Backup! Backup! Backup!
   Am besten gleich eine Kopie mit phpMyAdmin anlegen und diese sichern!
2. Ich habe zuerst die Kollation der Datenbank auf utf8_bin umgestellt.
3. Dann habe ich über die Shell einen Dump der Datenbank angelegt, wichtig ist hierbei der default charset latin1 gewesen!:

   mysqldump -uuser -ppasswort datenbankname --default-character-set=latin1 > /tmp/dumpname

4. Mit einem Hex-Viewer wie zum Beispiel xxd sollte man dann mal einen Blick auf den Dump werfen und sich einen kaputten Umlaut suchen. In meinem Fall belegten die doppelt utf8 kodierten Zeichen 3 bis 4 Bytes statt 2 Bytes.
5. Nun editiert man mit vim den Dump und ändert ganz am Anfang des SQL das "SET NAMES latin1" auf "SET NAMES utf8".
6. In phpMyAdmin sollte man nun die alte Datenbank einfach umbenennen (ist gleich ein Backup), eine neue Datenbank mit dem gleichen Namen anlegen und dann auf der Shell den Dump wieder einlesen:

   mysql -uuser -ppasswort datenbankname < /tmp/dumpname

7. Zu guter Letzt habe ich in Handarbeit via phpMyAdmin sämtliche Kollationen auf utf8_general_ci umgestellt, also bei allen Tabellen und allen Felder!
8. Nicht zu vergessen ist der Eintrag DB_CHARSET in eurer wp-config.php, dort gehört "utf8" eingeragen!

Was bei mir nicht klappte, war ein Tipp von David den Dump einfach mit default charset --default-character-set=utf8 einzulesen, ich glaube das funktioniert nur wenn die eigentlichen Daten eh schon utf8 sind, aber noch in einer Datenbank mit falschen Charset liegen. Darum auch der Hinweis, den Dump mal mit xxd zu betrachten.

Nicht empfehlen kann ich das Vorgehen von Perun oder kONZENTRAT.org die Zeichen per Suchen und Ersetzen auszutauschen, da sich die kaputten Zeichen u.U. nicht auf die drei Umlaute und ein scharfes S begrenzen. Ansonsten hat er es wie David mir sagte gemacht und den falschen Charset korrigiert.

Es wird aber trotzdem andere und eventuell auch bessere, einfachere und/oder schnellere Wege geben, was zählt ist aber das Endergebnis! Wie sagt mein Hausarzt immer so schön: "Wer heilt, hat Recht!"

Nicht nur die USA hat ihren “Change” erfolgreich(?) hinter sich gebracht, auch ich habe gerade etwas ausgetauscht. Und zwar das Plugin WP Highslide gegen Highslide Integration von der scrollleiste.

Obwohl Highslide Integration im Moment noch nicht so rund läuft wie ich es will, da ich die passenden Einstellungen nicht kenne, hat es doch ein paar erhebliche Vorteile gegenüber WP Highslide.

Zum einen integriert es sich, wie der Name schon sagt, einfach in den normalen Image-Code mittels eines simplen CSS-Tag und benötigt somit keinen proprietären Code. Das hat den großen Vorteil, sollte man das Plugin irgendwann deaktivieren müssen, funktionieren die Grafiken trotzdem. Bei WP Highslide verschwinden sie einfach.

Zum anderen produzierte WP Highslide zwei Warnungen im HTML-Validator Tidy. Das stört aber wahrscheinlich keinen, außer mir.

Die “noch” fehlende Navigation zwischen mehreren Bildern fehlt noch, aber diese wird nachgerüstet.

Wie auf wp-magazin.ch zu lesen ist, gibt es eine Hintertür in der aktuellen(?) WordPress-Version, über welche es möglich ist, einen falschen Update-Hinweis im Dashboard zu plazieren. wurde ein News-Feed dazu genutzt um eine Falschmeldung über ein vermeintliches WordPress-Update zu verbreiten.

Als ob das alleine nicht schon beunruhigend genug wäre, lädt man beim vermeintlichen Update eine modifizierte Version von WP herunter. Beim Download dieses Updates sollten aber schon die Alarmglocken läuten, da die Quelle wordpresz.org lautet (man beachte das “z” am Ende des Domainnamens!).

In diesem Download wurde die pluggable.php modifiziert, welche die Cookies der angemeldeten Benutzer zur gefakten Website schickte. Besagte Webseite ist aber derzeit offline.

*Nachtrag*

Da im Screenshot eine Version 2.5.1 gezeigt wird, bin ich mir nicht mehr sicher, ob die Dashboard-Lücke nicht nur eine alte Version betrifft.

*Nachtrag*

So wie es aussieht, wurde nicht die Update-Funktion von WP missbraucht, sondern nur ein News-Feed gekapert.

Es gab eine kleine Sicherheitslücke im Feed-Fetcher (das Teil holt die News, die man im Dashboard sieht) von WordPress. Wer schnell updaten will, braucht nicht lange zu warten und muss nur zwei Dateien aktualisieren:

• wp-includes/class-snoopy.php
• wp-includes/version.php

Das wars auch schon.

PS: Da hätten sie auch gleich den Flash-Uploader mit reparieren können.

*Nachtrag*

Und weil es so schön war, hat man im lokalisierten Standard-Theme noch eine XSS-Lücke entdeckt und behoben.