Die Versionsnummer wird nicht nur im Meta-Tag angezeigt, sondern taucht an diversen anderen Stellen ebenfalls auf, was durch deine Code-Zeile (ganz abgesehen davon, dass sie nicht in die functions.php eines Parent Theme gehört, dazu später mehr) nicht behoben wird – z.B. im RSS-Feed oder als Parameter der URLs zu eingebundenen JavaScript-Dateien.
Etwas vollständiger wäre dieser Code, den ich aus Bequemlichkeit dem Beitrag aus 2009 (!) auf DigWP entnommen habe:
// remove version from head
remove_action('wp_head', 'wp_generator');
// remove version from rss
add_filter('the_generator', '__return_empty_string');
// remove version from scripts and styles
function shapeSpace_remove_version_scripts_styles($src) {
if (strpos($src, 'ver=')) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);
add_filter('script_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);
Aber wieso wird dieser Code nicht jeder WordPress-Installation als Code-Snippet hinzugefügt? Wieso ist das nicht längst Bestandteil des Core? Weil „Security through Obscurity“ nur eine vermeintliche Sicherheit vorgaukelt.
Jede WordPress-Version unterscheidet sich an diversen Stellen von ihren Vorgängern und wer es darauf anlegt, Sicherheitslücken zu finden, kann in vielen Fällen mit Fingerprinting herausfinden, welche WordPress-Version und welche Themes und Plugins aktuell verwendet werden. (Sinngemäß: „wenn ab Version 4.x ein JavaScript-Framework XY verwendet wurde, müsste ich bei direktem Aufruf der JavaScript-Datei im Browser einen Datei-Header mit folgenden Angaben finden …“) Die Versionsnummer im Meta-Tag nicht anzuzeigen entspricht eher dem Versuch eines Dreijährigen, sich die Augen zuzuhalten und „Du siehst mich nicht!“ zu rufen.
Leider wird in viele All-in-One-Sicherheitslösungen angeboten, das Meta-Tag auszuschalten. Ich glaube allerdings, dass die Entwickler eher versuchen, all die zu beruhigen, die in irgendeinem Blogbeitrag mal von dieser skan-da-lö-sen! Sicherheitslücke gelesen haben und unruhig schlafen würden, wenn sie in „ihrem“ Sicherheitsplugin keine Schaltfläche zum Abschalten hätten. Die Entwickler von WordFence formulieren die Einstellungsoption jedenfalls so:
WordPress by default discloses what its version is. This option will hide it from outsiders. We generally recommend that you do not enable this anymore, since there are other methods of determining the WordPress version (“fingerprinting” of static content, like css and javascript files), and it will be disabled on new installations.
… und haben die Option trotzdem noch nicht entfernt.
Das eigentliche Sicherheitsproblem bei einer Website, die als Generator „WordPress 3.5“ ausgibt, ist die veraltete Software, deren Sicherheitslücke Angreifer „auf gut Glück“ auch ausnutzen könnten, ohne überhaupt eine Versionsnummer herauszufinden. Statt diesen Umstand zu verschleiern, solltest du dringend eine Aktualisierung vornehmen, die (selbst mit dringend zu empfehlendem vorherigen Backup) eigentlich nicht viel länger als eine Viertelstunde dauern kann, aber alle bisher bekannt gewordenen Sicherheitslücken auf einen Schlag schließt.
Zusätzlich könntest du deine Website weiter absichern, um z.B. Brute-Force-Angriffe und Fingerprinting (nicht nur in WordPress) generell zu erschweren – entweder mit einem Sicherheitsplugin wie WordFence oder SecuPress oder noch besser durch schrittweise Entwicklung eines eigenen Sicherheitskonzepts für deine Website, z.B. unter Anwendung der Tipps zur .htaccess, wie du sie im Blog von Torsten findest. Allerdings ist WordPress (entgegen vielen Mythen) nicht grundsätzlich unsicher und es reicht eigentlich schon, deine WordPress-Installation regelmäßig und zeitnah zu aktualisieren und starke Passwörter zu verwenden.
Zuletzt noch eine Anmerkung zum (dem angehängten Emoticon nach wohl ohnehin nicht ernst gemeinten?) „Ohne Plugin bitte ^^“:
Ich habe gestern noch auf einem WordPress Meetup die unreflektierte Aussage aufgeschnappt, zu viele Plugins seien schlecht für die Performance („hab ich irgendwo mal gehört“).
Auch wenn generell jedes Plugin die Performance in irgendeiner Form beeinträchtigt, muss hier auseinandergehalten werden, wie stark die Beeinträchtigung ausfällt. Schwergewichtige Plugins wie WordFence fallen hier sicher mehr ins Gewicht als ein Plugin mit drei Zeilen Code und es ist auch zu unterscheiden, ob das Plugin Funktionen im Frontend oder Backend ausführt, ob dabei Datenbankabfragen vorgenommen oder komplexe Funktionen ausgeführt werden. Wenn du die gleiche Funktion in einem Child Theme ausführst, dürfte es kaum einen Performancegewinn gegenüber einer (übersichtlichere) Einbindung per Plugin geben – gleiche Arbeit, nur andere Stelle. Alle möglichen Funktionen in der functions.php eines Child Themes anzuhängen macht eine Website nicht unbedingt wartungsfreundlicher und übersichtlicher und Plugins sind nicht „grundsätzlich böse“.
