Archive: Month 9, Year 2014

Behandlung depublizierter Artikel in WordPress

03.09.2014 yahe administration code legacy wordpress

Vor kurzen wurde ich von einem Auftraggeber vor eine spannende Aufgabe gestellt: Eine Seite musste eine ganze Menge alter Artikel depublizieren. Die Besucher dieser Artikel sollten jedoch nicht einfach von einer 404-Fehlerseite abgefangen werden, sondern ihnen sollte mitgeteilt werden, weshalb der Fehler aufgetreten ist und sie sollten möglichst automatisch auf die Startseite umgelenkt werden.

Dabei gab es mehrere Hindernisse. Zum einen musste eine Datenbasis geschaffen werden, welche URLs nicht mehr verfügbar sind und es musste bei deren Aufruf der entsprechend angepasste Inhalt angezeigt werden. Anstatt jedoch anzufangen, die gesamte Seite abzugrasen, um an die URLs zu gelangen, hatte ich eine bessere Idee. Die Artikeldatenbank selbst würde diese Datenbasis darstellen.

Um die Artikel offline zu nehmen, sollten diese nicht gelöscht, sondern lediglich deren Sichtbarkeit auf "privat" gestellt werden. Damit könnte man eine generalisierte Lösung erstellen, die für alle privaten Artikelseiten funktioniert. Das gute an privaten Artikeln ist, dass sie bei externen Besuchern zur 404-Seite führen, so, als würde sie nicht existieren. Der Inhalt der 404-Seite wird durch die Datei "404.php" des Themes repräsentiert. Dort kann man sich einklinken und vor dem Anzeigen des Fehlers prüfen, ob der Fehler aufgetreten ist, weil die angeforderte Seite privat ist. Je nach Ergebnis der Prüfung kann man dann den einen oder den anderen Inhalt anzeigen.

<?php
  $private_404_args    = wp_parse_args($wp->matched_query);
  $private_404_content = "";
  $private_404_done    = false;
  $private_404_result  = 0;

  if (isset($private_404_args["p"]) || isset($private_404_args["name"])) {
    if ((!$private_404_done) && isset($private_404_args["p"])) {
      $private_404_result = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM $wpdb->posts WHERE id = %d AND LOWER(post_status) = 'private' AND LOWER(post_type) = 'post';"), intval($private_404_args["p"]));

      $private_404_done = (intval($private_404_result) === 1);
    }

    if ((!$private_404_done) && isset($private_404_args["name"])) {
      $private_404_result = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM $wpdb->posts WHERE LOWER(post_name) = LOWER(%s) AND LOWER(post_status) = 'private' AND LOWER(post_type) = 'post';", $private_404_args["name"]));

      $private_404_done = (intval($private_404_result) === 1);
    }
  }

  if ($private_404_done) {
    $private_404_content = $wpdb->get_var("SELECT post_content FROM $wpdb->posts WHERE LOWER(post_title) = '[410]' AND LOWER(post_status) = 'private' AND LOWER(post_type) = 'page';");

    if ($private_404_content != null) {
      print(apply_filters('the_content', $private_404_content));
    }
  } else {
    $private_404_content = $wpdb->get_var("SELECT post_content FROM $wpdb->posts WHERE LOWER(post_title) = '[404]' AND LOWER(post_status) = 'private' AND LOWER(post_type) = 'page';");

    if ($private_404_content != null) {
      print(apply_filters('the_content', $private_404_content));
    }
  }
?>

Die schlussendliche Lösung ist etwas komplizierter geworden. Eigentlich hatte ich vor, einfach per "url_to_postid()" herauszufinden, ob unter der URL, die aufgerufen wurde, ein Artikel existiert. Leider funktioniert die Funktion offenbar nicht bei privaten Artikeln, wenn sie von einem Besucher aufgerufen wurden.

Im Feld "$wp->matched_query" stehen jedoch glücklicherweise die Teile der erfolgreich erkannten URL-Teile, wie sie die Bildungsregeln in der WordPress-Konfiguration vorgeben. In meinen Fall wäre das z.B. "/%year%/%postname%/". Der Inhalt von "matched_query" wäre demnach für den aktuellen Artikel hier "year=2014&name=behandlung-depublizierter-artikel-in-wordpress". Dieser Wert kann mithilfe der Funktion "wp_parse_args()" dann weiter aufgedröselt werden. Anhand des Namens, der in WordPress eindeutig ist, kann wiederum der zugehörige Artikel in der "wp_posts"-Tabelle gefunden werden.

Da ich sowieso gerade dabei war, habe ich auch noch eine weitere Vereinfachung vorgenommen, nämlich die, den angezeigten Inhalt der entsprechenden Fehlerseiten über das WordPress-Backend bestimmen zu können. Dazu müssen zwei Seiten (nicht Artikel!) erstellt werden, deren Sichtbarkeit ebenfalls auf "privat" gesetzt wird. Die Seite, die für generelle 404-Fehlermeldungen genutzt werden soll, muss den Titel "[404]" erhalten (ohne Anführungszeichen). Die Seite, die für depublizierte Fehlermeldungen genutzt werden soll, muss hingegen den Titel "[410]" erhalten (ebenfalls ohne Anführungszeichen).


Monat der WordPress-Sicherheit ist beendet

01.09.2014 yahe legacy security wordpress

In den letzten Wochen habe ich einige Artikel zur Sicherheit ausgewählter WordPress-Plugins geschrieben. Nun wollte ich abschließend noch einmal ein Fazit ziehen.

Begonnen hatte alles damit, dass auf Golem.de im Abstand von wenigen Wochen über zwei weit verbreitete Plugins mit leicht auffindbaren und dennoch schwerwiegenden Fehlern berichtet wurde. Es hatte mich daher interessiert, wie schlecht es wirklich um die Codequalität bei weit verbreiteten Plugins bestellt ist. Also begab ich mich zur Liste der beliebtesten Plugins und begann, mir Plugins anzusehen. Dabei habe ich mich auf halbwegs aktuelle Plugins konzentriert, die mindestens 25.000 Downloads hatten. Außerdem sollte die Analyse schnell gehen. Es ging mir nicht darum, Fehler in der Ablauflogik der Plugins zu finden, sondern ich wollte die groben Schnitzer finden, also die Fehler, die einem sofort ins Auge springen. Glücklicherweise verfügt jedes Plugin über ein eigenes Trac-Repository, sodass man direkt online in den Quelltext gucken kann. Damit entfällt das langwierige downloaden, entpacken und im Editor öffnen. So kann man relativ schnell einzelne Plugins abarbeiten.

Ich habe mir etwa 100 Plugins angesehen, die sich vom Namen oder von der versprochenen Funktionalität spannend anhörten. Dabei sind die 12 unten aufgelisteten Plugins aufgefallen, die solche nennenswerten Löcher enthielten, wobei 2 davon Beifang sind. Hatte ich ein Plugin mit einer Lücke gefunden, habe ich mir auch die anderen Plugins des gleichen Autors angesehen.

Plugin Angriff Anzahl
WP RSS Aggregator XSS 141.960*
WP CSV Information Leakage 31.675*
WP Advanced Importer Unprivileged File Upload 12.041*
WP Ultimate CSV Importer Unprivileged File Upload 112.793*
Simplr Registration Form Plus+ Information Leakage 105.325*
Form Builder Unprivileged File Upload 88.218*
WordPress File Upload XSS 25.060*
WP Modal Login Privilege Escalation 34.763*
Quick Chat SQL Injection 207,488**
Quick Count SQL Injection 14,268**
Login With Ajax Privilege Escalation 273.635**
FormGet Contact Form XSS 159.545**
Total: 1.206.771
(*Stand vom 16.08.2014)
(**Stand vom 26.08.2014)

Bei der Durchsicht der Plugins sind mir mehrere Dinge aufgefallen:

  1. Viele Plugins sind offenbar eher zufällig "sicher" und nicht etwa, weil der Programmierer das geplant hätte. Oft scheitert ein Angriff nur daran, dass vor einem anfälligen Code eine WordPress-eigene Funktion aufgerufen wird, was zu einer Exception führt, weil sie zu dem Zeitpunkt noch nicht definiert ist. Dadurch wird häufig die Programmausführung vorzeitig beendet. Würden solche Aufrufe in eine eigene Funktion gekapselt werden, wären viel mehr Angriffe möglich.
  2. Nur wenige Plugins schützen sich gegen Cross-Site-Request-Forgeries. Sie enthalten derzeit eventuell keine Lücken, sollten diese jedoch durch eine Codeänderung eingeführt werden, ließen sie sich dadurch wesentlich leichter ausnutzen.
  3. Die Punkte 1.) und 2.) rühren oftmals daher, dass die Entwickler sich nicht darum sorgen, ob ihre PHP-Scripte direkt aufgerufen werden dürfen. Vielen Entwicklern ist offenbar nicht bewusst, dass sie ihre Entrypoints und Codepfade kennen und absichern sollten. Dies war die häufigste Fehlerkorrektur, die Plugin-Entwickler umgesetzt haben, wenn sie von mir angeschrieben wurden.
  4. Viele Plugin-Entwickler verlassen sich darauf, dass eingeloggte Nutzer gutartig sind. Während sie den Eingaben von nicht-eingeloggten Besuchern meist gänzlich misstrauen, werden Eingaben von eingeloggten Nutzern häufig weniger oder gar nicht geprüft. Daher sollte man sich beim Einsatz von Plugins gut überlegen, ob man "Subscriber" in seiner WordPress-Installation zulässt.
  5. WordPress bietet Entwicklern viele fertige Funktionen an, mit denen sie ihre Plugins sicherer machen können. Das reicht bis zu fertigen Referer- und Nonce-Prüfungen gegen XSRF-Angriffe. Mir ist jedoch auch aufgefallen, dass WordPress-Nonces relativ lange gültig sind, sich nur an der Zeit orientieren statt an nutzergebundenen Werten und damit potentiell mehrfach und von verschiedenen Nutzern verwendet werden könnten. Das führt dazu, dass ein Angreifer sich regelmäßig einen neuen Nonce holen und diesen für länger laufende Attacken verwenden könnte.

Die Kommunikation mit den einzelnen Plugin-Entwicklern war bisher durchweg positiv. Viele haben sich gefreut, dass sich jemand tiefer mit ihren Plugins auseinandergesetzt und sie über Probleme informiert hat. Die meisten haben in weniger als einer Woche das Problem behoben. Bei anderen Plugins warte ich darauf hingegen immernoch. Dort wurde ein Fix lediglich in Aussicht gestellt. Überrascht hat mich die Reaktion eines Entwicklers, der sein Plugin aufgrund von Zeitmangel aus dem Plugin-Repository entfernt hat. In meinen Augen war das ein mutiger Schritt.

Für Leute und Firmen, die WordPress professionell einsetzen, kann ich aufgrund der Ergebnisse eigentlich nur einen Rat geben. Wenn Fremdplugins eingesetzt werden, empfiehlt es sich, wenigstens kurz in deren Quelltext zu blicken. Guckt euch an, ob sichergestellt wird, dass die PHP-Scripte nicht direkt aufgerufen werden können. Damit ist bereits viel gewonnen, da der Plugin-Entwickler so viel mehr Kontrolle über den Programmablauf hat.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)