Wie sichert man ein Content Management System? – Videointerview mit David Jardin

Products mentioned
WordPress und die Arbeit des Joomla Security Teams

Wie sichert man ein Content Management System? Welche Sicherheitsvorteile bietet WordPress bzw. Joomla? Gibt es einen Austausch zwischen den Communities von Joomla und WordPress in Sicherheitsfragen? Wir sprachen dazu mit David Jardin. David Jardin ist Webdeveloper, aktives Mitglied der Joomla Community und des CMS-Garden sowie Leiter des Security Teams von Joomla.

GoDaddy: Kommen wir zum Thema Sicherheit. Du bist Leiter des Joomla Security Teams, was macht ihr da genau?

David: Wir haben zwei Hauptrollen. Der eine Teil unserer Arbeit ist, dass wir die Reports, in denen uns Sicherheitslücken gemeldet werden, in einer „Triage“ behandeln. Das heißt: Wir gucken uns an, ob das, was uns da beschrieben wird, überhaupt plausibel ist. Funktioniert dieser Angriff, der da beschrieben wird? Und falls ja, wie kritisch ist er? Und je nachdem, was dabei rauskommt, bestimmen wir dann die weiteren Aktionen. Eine Aktion kann sein: Da muss sofort notfallmäßig ein Patch für geschrieben werden und es muss dafür sofort ein Notfall-Release raus. In einem anderen Fall reicht es, wenn die entsprechende Lücke in allem der nächsten turnusmäßigen Updates gepatcht wird. Oder es kann auch der Fall sein, dass sich die Lücke einfache als keine Lücke erweist. Das ist der eine Teil unserer Arbeit.

Der andere Teil unserer Arbeit ist mehr proaktiv. Wir machen Code-Reviews. Wir schauen uns den Joomla-Core von uns aus an und verlassen uns da nicht nur auf den Input von außen. Das ist eine unglaublich spannende Arbeit. Denn wir räumen ständig den Kram von anderen Leuten auf. Wir bauen die Sicherheitslücken ja nicht selber ein, sondern wir werden dann gerufen, wenn das Kind schon in den Brunnen gefallen ist.

GoDaddy: Werdet ihr tatsächlich aktiv beauftragt oder checkt ihr regelmäßig von euch aus?

David: Wir checken es von uns aus, genau. Diese proaktive Arbeit machen wir dann, wenn größere neue Features in Joomla dazu kommen, wenn zum Beispiel der neue Medienmanager gemerget werden würde. Das wäre der Zeitpunkt, wo wir dann von uns aus darauf schauen, bevor es in den Core einfließt. Eine ganz spannende Arbeit.

GoDaddy: Werdet ihr von den Entwicklern direkt schon in der Entwicklungsphase mit einbezogen? So in der Art: „Hey, wir planer da etwas. Ab dem und dem Zeitpunkt solltet ihr da auch mal draufgucken.“

David: Das wäre der Idealfall. In der Realität passt das allerdings kaum. Wir müssen da schon selber hinterher sein. Diese Arbeit, vor allem der erste Teil, wo es darum geht, dass wir uns gemeldete Lücken anschauen und behandeln, ist eine spontane Arbeit. Das ist nicht planbar.

Deswegen haben wir bei der Zusammenstellung des Teams auch bewusst darauf geschaut, dass wir zumindest einigermaßen geografisch verteilt sind, dass wir in verschiedenen Zeitzonen sitzen, damit quasi immer jemand im Dienst ist. Es muss halt immer jemand auf Abruf bereitstehen, um sich etwas anschauen zu können.

Ja, das ist eine Arbeit, die Spaß macht. Es passiert ganz viel im Verborgenen. Der Joomla-User sieht immer nur den Patch. Was davor passiert ist, interessiert eigentlich keinen. Aber mir macht es großen Spaß. Es ist schön zu wissen, dass man das Web ein Stück weit sicherer machen kann.

GoDaddy: Gerade Joomla und vor allem WordPress sind als die beiden Nummer 1 und 2 der weitverbreitetsten Content Management Systeme weltweit und ein beliebtes Angriffsziel für Hacker und der Malware-Attacken. Gibt es eigentlich einen engen Austausch zwischen den beiden Communities, gerade in puncto Sicherheitsfragen?

David: Das war bis vor einem Jahr noch sehr oberflächlich. Es nimmt aber gerade in diesem Jahr noch einmal Fahrt auf. Es gab im Februar ein internationales Treffen der CMS-Security-Team-Leads, also mit den Kollegen von WordPress, Drupal und Typo3, die in einer ähnlichen Rolle sind wie ich. Wir haben uns in Chicago getroffen, zusammen mit Leuten von Webhostern, mit Leuten von Google, mit Leuten, die Web-Application-Firewalls programmieren …  Dort haben wir uns ausgetauscht – auf verschiedensten Ebenen.

Dadurch, dass zumindest im CMS-Umfeld die zugrundliegende Technologie oft dieselbe ist, PHP und SQL, ergeben sich daraus eigentlich immer sehr ähnliche Angriffsszenarien.

Die Wege sind immer sehr ähnlich. Und deshalb ist es interessant, sich auszutauschen, welche Lösung man für diese identischen Wege findet. Der Austausch, der passiert jetzt.

GoDaddy: Gibt es denn, wenn du jetzt die beiden CMS Joomla und WordPress einmal vergleichst, irgendwelche Sicherheitsvorteile des einen Systems gegenüber dem anderen?

David: Wenn ich mir die aktuellen Versionen anschauen, würde ich sagen, hat WordPress in zwei Bereichen einen relativ charmanten Vorteil.

Das eine ist tatsächlich das Auto-Update. Dazu könnte man jetzt natürlich sagen: „Das ist ja gar kein Sicherheitsfeature.“ Das stimmt insofern auch, da es erfolgreiche Angreifen nicht verhindert. Aber es sorgt dafür, dass Sicherheits-Updates automatisiert eingespielt werden. Und das ist der relevante Part. Wir wissen aus unserer Beobachtung heraus: Wenn größere Angriffe passieren, gibt es nur ein ganz kleines Zeitfenster zwischen der Veröffentlichung des Patches und den ersten Angriffen. Wir reden da so über acht bis zehn Stunden. Das ist das Zeitfenster, das man hat.

GoDaddy:  Sobald die Lücke bekannt ist, kommt auch der Angriff – relativ schnell

David: Durch die Auto-Updates sind im WordPress -Umfeld dann schon sehr viele Seiten geschützt, wenn die ersten Angriffe kommen. Dieses Auto-Update fehlt Joomla derzeit noch in der aktuellen Version.

GoDaddy: Sperrt sich eigentlich die Community dagegen? Es gibt ja auch diese Aversion gegen Auto-Updates und Leute, die sagen: „Nein, ich möchte die Kontrolle behalten. Es kann ja immer was passieren. Das Auto-Update kann ja auch etwas zerschießen.“ Das ist ja das klassische Gegenargument gegen Auto-Updates.

David: Jetzt, das ist das politische Argument. Dem kann man aber natürlich leicht den Wind aus den Segeln nehmen, wenn man sagt: „Das ist ja kein Problem.“ Dann machen war es halt optional. Wer will, kann es ausschalten, so wie es im WordPress-Core auch der Fall ist.

Im Joomla-Umfeld gibt es einen anderen Grund, weshalb wir es bisher nicht gemacht haben, nämlich der: Wenn wir automatische Updates ausrollen wollen, dann wollen wir es auf eine sichere Art und Weise tun. Sichere Art und Weise bedeutet: Eine Joomla-Installation muss in die Lage versetzt werden, zu prüfen, ob das Auto-Update, was da gerade ausgeliefert wird, auch wirklich das Original-Update ist, was die Joomla-Entwickler veröffentlicht haben. Ohne diese Prüfung besteht die Gefahr, dass der Angreifer nur den zentralen Update Server übernehmen muss, und schon kann er automatisch Updates ausrollen, die seine Malware einschleust. Im WordPress-Umfeld hätte ich mit einem Schlag ein Drittel aller Webseiten weltweit gehackt. Das ist ein attraktives Ziel. Und um das zu verhindern, braucht man kryptographische Signaturen. Das ist im PHP-Umfeld nicht so leicht, insbesondere bei älteren PHP-Version. In der aktuellen Joomla Version supporten wir noch runter bis PHP 5.3. In dem Umfeld ist es extrem schwierig. Mit neueren Versionen wird das einfacher. Auch in der WordPress-Community ist man sich dieses Problems bewusst und hat jetzt in der letzten Version angefangen, Signaturen für diese Auto-Updates auszurollen.

Es ist tatsächlich eher ein Sicherheitsproblem, als ein politisches Problem.

Der zweite charmante Vorteil, den WordPress aktuell noch hat, liegt auf der Datenbank-Ebene.  WordPress bietet für Datenbank-Queries eine Simulation der sogenannten Prepared Statements.

Prepared Statements sind ein Weg, um Attacken mittels SQL-Injection zu verhindern. Bei der SQL-Injections ist der Weg folgendermaßen. Ich habe eine Datenbankabfrage und als Angreifer bin ich irgendwie in Lage, in diese Abfrage etwas einzuschleusen, was aus der originalen Anfragen sozusagen ausbricht und meine Abfrage dann mit ausführt.

Bei Prepared Statements wird die eigentliche Anfrage und das, was dann an Werten in dieser Anfrage eingesetzt wird, in verschiedenen Abfragen an die Datenbank geschickt. Deswegen kann die Datenbank dafür sorgen, dass niemand aus dieser Original-Abfrage ausbrechen kann.

Das haben wir in der aktuellen Version von Joomla noch nicht. Es kommt jetzt mit der kommenden Version. Und dann kommt mit Joomla 4 auch noch ein Feature, von dem ich denke, dass Joomla damit einmal die Nase vorn hat. Joomla 4 wir von Haus aus Unterstützung für die sogenannte Content Security Policy (CSP) mitbringen.

Die Content Security Policy ist eine Technik, womit ich einem Webbrowser ganz explizit sagen kann: „Du darfst das folgende JavaScript ausführen. Du darfst eine Schrift von dem folgenden Server nachladen und Styles von … was weiß ich … cdn.google.com …, aber sonst nichts.

Und dieses Blacklisting von allem anderen bzw. das Whitelisting von dem Erlaubten, eliminiert auf sehr weiter Strecke Cross-Site-Scripting-Attacken. Da sind wir – glaube ich – bisher das einzige CMS, das diesen Weg konsequent geht. Da freue ich mich schon drauf.

GoDaddy: Das klingt spannend. Weißt du schon, wann Joomla 4 kommt?

David: Mal munkelt, man munkelt. Es gibt vom 8. bis zum 10. November die Joomla World Konferenz in London. Das große Treffen der Joomla-Community in diesem Jahr. Da würde es sich natürlich anbieten, den Launch rund um diesen Termin zu machen. Da man dann in London eine ordentliche Party drum herum feiern kann. Das ist zumindest der inoffizielle Plan. Ich halte es aber für plausibel.

GoDaddy: Da kann man gespannt sein. Vielen Dank, David, für die sehr interessanten Einblicke in deine Arbeit und die Arbeit des Joomla Security Teams.

Hier findest du weitere Video-Interviews mit WordPress-Experten