Schlagwort: WordPress

is_admin() ist keine Sicherheitsfunktion

Manche Funktionsbezeichnungen lassen Interpretationsspielraum, wo besser keiner sein sollte. Die WordPress-Funktion „is_admin()“ ist so ein Fall, denn wie die WordPress Code Refernce erklärt

Does not check if the user is an administrator

„is_admin()“ prüft lediglich, ob der Aufruf innerhalb der Administrations-Oberfläche erfolgte. Wer sich für die tatsächlichen Berechtigungen des angemeldeten Benutzers interessiert, sollte „current_user_can()“ verwenden.


Hinweis auf veraltete Beiträge

Problematisch bei Beiträgen zu Technik ist, daß sie meist ein Verfallsdatum haben. Was heute prima funktionert, kann bereits in der nächsten Softwareversion entweder an ganz anderer Stelle versteckt sein oder wurde komplett gestichen. So häufen sich auch hier im Blog die Kommentare von Lesern, die übersehen, daß ein mit „Windows 7“ gekennzeichneter Beitrag unter Windows 10 wohl nur noch durch Zufall so nachvollziehbar sein wird.

Aus diesem Grund wird nach und nach in älteren Beiträgen ein entsprechender Hinweistext eingebaut. Um nicht die Beitragstexte selbst ändern zu müssen, wird dies über ein paar Zeilen Code in der „functions.php“ realisiert:

function outdated_notification($content) {

	global $post;

	if (is_single()) {
		$isOutdated = get_post_meta(get_the_ID(), 'veraltet', true);
		if ($isOutdated) {
			$content = '<p class="outdated_notification">Der Inhalt ist veraltet!</p>' . $content;
		}
	}
	return $content;
}

add_filter('the_content', 'outdated_notification');

Der Code richtet einen WordPress-Filter ein, der jedesmal, wenn der Inhalt eines Beitrags über die Funktion „the_content“ angefragt wird, den Beitragsinhalt vor Verwendung durch die Funktion „outdated_notification“ schickt.

Diese prüft zuerst, ob es sich um eine Einzeldarstellung des Beitrags handelt („is_single()“) und im Erfolgsfall, ob für den Beitrag das Feld „veraltet“ gesetzt wurde. Ist dies der Fall, wird ein HTML-Paragraph mit einem Hinweistext vor den Beginn des eigentlichen Beitragsinhalts gestellt.

Der oben skizzierte Code funktionert allerdings nur, solange der Inhalt über die Funktion „the_content“ angefragt wird. Wird vom gewählten Thema hingegen die Funktion „get_the_content“ verwendet, ist etwas mehr Bastelarbeit notwendig, denn hier sind keine Filter vorgesehen.


WordPress Kommentar-IP-Adresse anonymisieren

Standardmäßig speichert WordPress neben dem eingegebenen Kommentar auch die IP-Adresse, von welcher der Kommentar übermittelt wurde.

Diese Speicherung lässt sich durch Einsatz eines Filters deaktivieren. In der „functions.php“ des Themes die Zeilen

function replace_comment_author_ip($comment_author_ip) {
	return '127.0.0.1';
}

add_filter('pre_comment_user_ip', 'replace_comment_author_ip');

hinzufügen, damit bei allen neuen Kommentaren statt der tatsächlichen IP-Adresse des Autors die Adresse „localhost“ gespeichert wird.

Sofern bereits Kommentare in der WordPress-Datenbank vorhanden sind, werden diese durch das Hinzufügen des Filters nicht geändert. Hier hilft ein SQL-Statement:

UPDATE wp_comments SET comment_author_IP = '127.0.0.1';

Kommentar-Cookie in WordPress deaktivieren

Standardmäßig setzt WordPress beim Absenden eines Kommentars ein Cookie, welches als Komfortfunktion die eingegebenen Daten (i.d.R. Name und E-Mail-Adresse) des Kommentierenden enthält und fügt diese Daten in allen weiteren Kommentarfeldern als Vorbelegung ein.

Dank der Hooks und Actions in WordPress ist die Deaktivierung des Cookies schnell erledigt:

In der „functions.php“ des Themes die Zeile

remove_action('set_comment_cookies', 'wp_set_comment_cookies');

hinzufügen und schon wird beim Kommentieren kein Cookie mehr gesetzt.


WordPress, Joomla! und die Sicherheit

Erinnert sich noch jemand an die „Fairy Ultra“-Werbung mit Villarriba und Villabajo?

Zwei fiktive spanische Dörfer, die jeweils nach einer großen Party ihre Pfannen schrubben. Und während die Bewohner von Villabajo (mit herkömmlichem Spülmittel) noch tapfer vor sich hin putzen, wird in Villarriba (die Fairy Ultra nehmen) schon wieder gefeiert.

Der Vergleich hinkt zwar, aber trotzem spiegelt das die Situation der beiden oben genannten Content Management Systeme irgendwie wider:

Am 12. Mai veröffentlichte das Joomla!-Team eine Sicherheitsankündigung mit dem Hinweis, Joomla!-Installationen mit erscheinen des nächsten Updates am 17.05.2017 um 16 Uhr möglichst direkt zu aktualiseren.

Mit der Veröffentlichung von Joomla! 3.7.1 wird u.a. eine kritische Sicherheitslücke geschlossen. Das Update erscheint voraussichtlich am 17.05.2017 um 16 Uhr.

Das Joomla Sicherheits-Team (JSST) wurde über eine kritische Sicherheitslücke im Joomla! Core informiert. Da dies eine sehr wichtiger Sicherheitspatch ist, bereitet euch bitte darauf vor, eure Joomla Seiten nächsten Mittwoch zu aktualisieren.

Solch ein Hinweis ist richtig und wichtig, doch in einer globalen Welt ist es nicht überall zum gleichen Zeitpunkt 16 Uhr. Und während die einen in der Nachtruhe schlummern, sind andere unterwegs fernab jedes PCs und der Patch – mit dessen Erscheinen auch die kritische Sicherheitslücke selbst bekannt wird – wird nur auf einem Bruchteil der Systeme zeitnah (also innerhalb weniger Minuten) eingespielt werden können. Es beginnt ein Wettrennen – auf der einen Seite finstere Gestalten, die möglichst schnell die Sicherheitslücke auszunutzen wollen und auf der anderen Seite Admins, die versuchen, die von Ihnen betreuten Systeme zeitnah zu aktualisieren.

Ganz anders dagegen in der WordPress-Welt, seit mit Version 3.7 automatische Hintergrund-Updates eingeführt wurden: während der Administrator dieser Seiten in der Nacht vom 16. auf den 17. Mai vor sich hinschlummerte, hat sich WordPress automatisch auf die Version 4.7.5 aktualisiert und anschließend per E-Mail darüber informiert.

Sicherlich sind automatische Updates kein Allheilmittel und bergen die Gefahr, dass eine Aktualisierung nicht reibungslos verläuft und die Funktionalität einer Website beeinträchtigt wird. Vorbehalte gegen solche Automatismen gibt es – besonders bei denjenigen, die sie nicht verwenden – viele und viele Unternehmen haben bei der aktuell durch die Welt schwappenden Erpressungstrojaner-Welle mal wieder gezeigt, wie wenig hilfreich es ist, monatelang auf Systemaktualisierungen zu verzichten.

Betrachtet man die Zahl an Websites von Privatleuten, klein(er)en Unternehmen und Vereinen, deren Komplexität durchaus überschaubar ist und deren Admin meist nach dem „Du machst doch irgendwas mit Computer, kannst Du nicht mal …“ ausgewählt wurde, scheinen automatische Updates eine sinnvolle Möglichkeit, ohne allzu hohes Ausfallrisiko die Sicherheit für den Betreiber und auch Dritte (sowohl Besucher der Website als auch andere Kunden in shared Hosting Umgebungen) deutlich zu erhöhen.

Wer sich für viel Geld eine hochkomplexe Webpräsenz erstellen lässt, der ist seinem dedizierten Admin hoffentlich für eine Rechnung mit Nachtzuschlag dankbar, weil dieser im Bedarfsfall um 2 Uhr Nachts lieber geschrubbt statt gefeiert hat.