Siwecos: Überprüfung der Website-Sicherheit

Es gibt unglaublich viele Tools und Services im WordPress-Umfeld. Und jeder hat da so seine Favoriten. Immer mal wieder gebe ich gerne Einblicke in die Tools, die wir einsetzen. Der heutige Blog-Artikel soll sich um Siwecos drehen, ein Tool, mit dem man seine Website von außen auf bestimmte Schwachstellen testen lassen kann.

Was ist Siwecos?

Da zitiere ich mal den einleitenden Satz der Seite „Über das Projekt“ auf der Siwecos-Website:

SIWECOS steht für „Sichere Webseiten und Content Management Systeme“ und hilft kleinen und mittelständischen Unternehmen (KMU) Sicherheitslücken auf ihren Webseiten zu erkennen und zu beheben.

Gefördert vom Bundeswirtschaftsministerium, ist es ein Projekt des eco-Verbands und der Ruhr-Uni Bochum mit tatkräftiger Unterstützung des CMS Garden.

Im Prinzip geht es darum, ein Set von sicherheitsrelevanten Kriterien an Website und Server zu prüfen und daraus einen Wert (Score) zu berechnen, der zwischen 0 und 100 liegt, je höher, desto sicherer die Seite (auf Basis dieses Tests). Dies geschieht „von außen“, also ohne direkten Zugriff auf den Server und kann damit natürlich nur oberflächlich sein. Allerdings sind es die Daten, die getestet werden, die auch ein Angreifer ermitteln oder nutzen kann.

Trotzdem noch ein Hinweis: ein gutes Ergebnis im Siwecos-Test bedeutet nicht automatisch, dass die Website auch super-sicher ist. Das ist (wie immer) nur eine von vielen Elementen, die zur Sicherheit der Website im Gesamten beitragen. Auf den Test und Scan von Siwecos alleine sollte man sich nie verlassen.

Was wird getestet?

Getestet werden die Konfiguration bezüglich des SSL-Zertifikats und der HTTP-Header auf dem Server, offene Ports, diverse Tests rund um das genutzte Content Management System (z.B. die verwendete Version), diverse Tests rund um DOM-XSS-Angriffe und einiges mehr.

Es werden auch einige Dinge getestet, die aus meiner Sicht nicht relevant sind, zum Beispiel, dass die Verwendung von WordPress-Plugins im öffentlich einsehbaren HTML-Quellcode erkennbar ist. Häufig wird dies als Problem angesehen, wenn man durch Anschauen des HTML-Quellcodes auf die genutzten Plugins schließen kann. Die Idee dahinter ist, dass man dadurch entsprechend Schwachstellen dieser Plugins auf der besagten Website ausnutzen kann. Die Erfahrung zeigt aber, dass den Angreifern ziemlich egal ist, welches Plugin installiert ist. Sie feuern alle möglichen Angriffs-Versuche auf die Website ab, teils sogar unabhängig vom genutzten CMS.

Auch die Tests zu „Information Leaks“ wie zum Beispiel auffindbare Mail-Adressen oder Telefonnummern auf der Website sind für mich eher nicht relevant. Das ist für mich eher normal und ein Verschleiern (durch Grafiken oder JavaScript) erachte ich als kontraproduktiv im Sinne der Barrierefreiheit oder der User Expierence.

Das soll aber nicht darüber hinweg täuschen, dass ich das Angebot im Großen und Ganzen für sehr wertvoll erachte und meine Seiten sowie die Kundenseiten gerne damit teste. Insbesondere auch der Testblock zu den HTTP-Headern ist immer sehr hilfreich.

Ich habe mir zur Aufgabe gemacht, alle Kundenseiten zu einem Siwecos-Score über 80 zu bringen.

„Nur 80? Ich erwarte schon 95, besser 100!“

Stimmt, ist aber nicht immer so einfach möglich. Denn auf einige Dinge hat man leider keinen Einfluss. Gerade im Testblock DOMXSS schlägt der Scanner gerne an, je nachdem, welche externen Bibliotheken, Themes und Plugins man verwendet. Das muss nicht immer eine konkrete Bedrohung darstellen, lohnt sich aber trotzdem zu untersuchen. Die Informationen des Scanners sind aber gerne dürftig, weswegen es manchmal gar nicht so einfach ist festzustellen, welches Element der Seite dort nun zu einem Anschlagen des Scanners geführt hat.

Andererseits sind manche Themen nur vom Hoster zu beeinflussen, so dass einem (außer einem Wechsel des Hosters) manchmal nichts übrig bleibt, als die eine oder andere Abwertung zu akzeptieren.

Ein Wert über 80 geht aus meiner Erfahrung mit einer ordentlichen Absicherung einher, aber auch Werte über 90 sind je nach Ausgangslage möglich. Eine „100“ habe ich bei einer echten Live-Seite aber noch nie gesehen.

Wie oben bereits erwähnt, ist der Scanner nicht bei allen Tests eindeutig in Bezug auf sein Testergebnis. Immer mal wieder wird man im Dunkeln gelassen, was genau denn jetzt das Problem ist. Allerdings gibt es im Siwecos-Wiki viele allgemeine Erläuterungen und Erklärungen zu den einzelnen möglichen Problemen. In vielen Bereichen kann man darüber oder über ein beherztes Googlen sich den Grund für die Abwertung erschließen.

Am wenigsten gelingt das beim DOM-XSS-Scanner. Für eine Seite habe ich dazu mal nach und nach Plugins deaktiviert und immer wieder neu getestet, um herauszufinden, dass die Emoji-Fallback-Integration von WordPress angemeckert wird. Auch Tracking-Codes (Analytics, Matomo) werden beanstandet, genauso wie ein Einsatz von WPRocket, dessen JS-Optimierung offensichtlich dazu führt, dass der Scanner Gefahrenpotenzial erkennt.

Wie funktionierts?

Die Funktionsweise ist sehr einfach: ohne Registrierung kann man nur einen sehr einfachen Test machen. Das ist auch gut so, denn es wäre schon sehr blöd, wenn man ohne Identifizierung beliebige Websites auf Schwachstellen testen könnte und dann diese in einem detaillierten Bericht auch noch auf dem Silbertablett serviert bekäme.

Deswegen ist eine Anmeldung erforderlich, nach der man dann Websites (bzw. Domains) zum eigenen Konto hinzufügen kann. Wie auch bei der Google Search Console muss man dann die Inhaberschaft bestätigen. Dies geschieht über einen Meta-Tag oder das Hinzufügen einer Datei ins DocRoot-Verzeichnis.

Übrigens noch ein „lustiges“ Detail (nein, eigentlich gar nicht zum Lachen): das Siwecos-Wiki empfiehlt zum Hinzufügen des Meta-Tags in WordPress die direkte Bearbeitung der Header-Datei des Themes über den Code-Editor im WordPress-Backend. Das widerspricht in vielfacher Hinsicht so allem, was man im WordPress-Umfeld unter Sicherheit versteht (Nicht mit den Code-Editor im Backend arbeiten sondern via FTP! Keine Theme-Dateien direkt bearbeiten, sondern entweder über ein Child-Theme arbeiten oder ein Plugin für das Einfügen von Header-Codes nutzen!)

Fazit

Obwohl dieser Beitrag zwischenzeitlich sehr kritisch erscheint, bin ich grundsätzlich von Siwecos überzeugt. Es gibt kleinere Themen, die nicht optimal sind, aber das Hauptanliegen ist richtig und wichtig.

Deswegen werden alle unsere Wartungskunden regelmäßig mit dem Siwecos-Scanner getestet und wir stellen sicher, dass eine Basispunktzahl von 80 Punkten immer erreicht wird.

Leider hat Siwecos die Anzahl der täglichen Scans auf 25 Domains limitiert (das war früher noch anders, scheinbar sind unsere 200 Tests pro Tag aufgefallen 😉 ). Dadurch sind uns mittlerweile keine täglichen Scans aller Kundenwebsites mehr möglich. Aber vielleicht tut sich ja auch in diesem Bereich noch etwas. Ich hätte auch kein Problem damit, für meinen Mehrbedarf an Domain-Scans zu bezahlen.

Ich ermutige also jeden, sich das Projekt gerne mal anzuschauen und die eigene Website testen zu lassen. Da der Scanner und alle anderen Entwicklungsteile auf Github liegen, kann man sich an der Weiterentwicklung bei Interesse auch selbst beteiligen.

Übrigens: es scheint so, als würde das Projekt häufig unter dem Radar fliegen, obwohl es schon länger auf der Bildfläche ist. Bereits auf den WordCamps in Köln 2017 und 2018 gab es Vorträge von Markus Wortmann bzw. David Jardin dazu: