In den letzten Weihnachtsferien geschah Erstaunliches in der Schweizer Parteienlandschaft: Auf der Homepage der SVP Stadt Zürich erschienen ungebührliche Fotos sowie der recht schwer verständliche Slogan "26C3: Here be Dragons". Am 5. Januar tauchte sogar ein YouTube-Video auf, in dem ein Nazi-Skinhead nach Art des Ricola-Werbespots tönte: "Wir wollen ein sauberes Stadtbild, deshalb haben wir das Minarettverbot erfunden."
Hatte sich etwa der städtische Ableger der Partei ein neues Selbstbildnis zugelegt? Mitnichten, gemäss des SVP-Sekretärs Bruno Sidler: "Wir wurden über die Festtage von Hackern attackiert", erklärte er damals gegenüber Zürcher Medien. Und da Urlaubszeit herrschte, dauerte es mehrere Tage, bis die Website wieder gesäubert wurde. Obwohl keine Daten geklaut oder zerstört wurden, wollte die SVP Stadt Zürich ihr Internet-Sicherheitskonzept überarbeiten und bis zum Frühling die Scheunentore schliessen.
Daraus scheint aber nicht geworden zu sein, wie der russische Enterprise-2.0- und CRM-Spezialist Bitrix nun herausgefunden hat. Bitrix hat vor kurzem die Probe aufs Exempel machte, und hätte per SQL-Injection weiterhin ganz einfach Zugriff auf die zugrundeliegende Datenbank erhalten. Gehackt wurde jedoch nichts, Bitrix hat lediglich ein einfaches Testprogramm an der Seite ausprobiert. Sogar der Name des Datenbanknutzers wurde dabei angezeigt. Haben Partei und zuständiger Sicherheits-Dienstleister etwa seit Weihnachten immer noch Ferien? Da dies unwahrscheinlich erscheint, sollten sie wohl einfach jemanden fragen, der sich auskennt.
Woran mangelt es denn bei dieser Website? Die Spezialisten des russischen Anbieters vermuten, dass keine Sicherheits-Updates gefahren wurden, so dass die Schwachstellen, die beim Hackerangriff genutzt wurden, immer noch vorhanden sind. Diese Sicherheitslücken gelten zudem als sehr gefährlich und einfach auszunutzen. So lassen sich etwa die Datenbank der Website inklusive Nutzernamen und persönliche Informationen auslesen, die Website verunstalten, die volle Kontrolle über die Website erhalten, unerwünschte Inhalte veröffentlichen oder der Ruf des Seiteninhabers schädigen. Wie das dann aussieht, konnte man im Januar sehen.
Und welche Massnahmen wären dagegen geeignet? Zum Beispiel die Nutzung eines sicheren Website-Management-Systems mit integriertem Schutz vor SQL-Injection, die Installation zusätzlicher Sicherheits-Software wie einer Web Application Firewall sowie klare Vorgaben für die genutzten Datentypen. Dazu gehören die Filterung von Textdaten nach SQL-Symbolen oder die Kontrolle der Datenkettenlänge. Vermutlich enthält die Website noch weitere Schwachstellen, die zusätzliche Massnahmen erfordern.
Um nicht so zu enden wie die SVP Stadt Zürich, sollte jeder Website-Betreiber ein paar Grundregeln beachten:
Zeitnahes Installieren von Updates
Jeden Verdacht gründlich überprüfen, am besten mit einem Security-Profi
Möglichst viele Log-Files aufheben, um die Infektion zu identifizieren
Ständig Daten sichern
Integritäts-Kontrollwerkzeuge nutzen
IDS/IPS (Intrusion Detection/Intrusion Prevention-Systeme) einsetzen
Web Application Firewall und andere Sicherheitsfeatures des CMS (Content Management Systems) einschalten
Verlässliche Web-Applikationen verwenden
Das System regelmässig von Spezialisten überprüfen lassen
Best Practices befolgen wie Einmal-Passwörter und sichere Konfiguration
Jeder Website-Inhaber, unabhängig von seiner politischen Orientierung, sollte sich dabei über eines klar sein: Niemand ist vor Angriffen gefeit, so dass der Sicherheitszustand immer wieder neu überprüft werden muss. Denn Seiten, die gestern noch sicher waren, können heute schon von einer Schwachstelle betroffen sein. Also Vorsicht, sonst winkt vielleicht auch von Ihrer Website einmal ein Skinhead mit dem Baseballschläger.
Günter Unterholzner ist freier Journalist in München
Sicherheitsmassnahmen gegen Cross-Site Scripting (XSS)
Um eine Attacke per XSS zu verhindern, müssen Sie die <, >, & und “ Symbole durch ihre jeweiligen HTML-Codes ersetzen, ehe sie den Benutzern dargestellt werden. Bei der Darstellung von Nutzerdaten innerhalb von Tag-Parametern sollten Sie unbedingt “ verwenden.
Ein Beispiel:
<script> alert(‘hacked’)</script> sollte durch <script>alert(‘hacked’)</script> ersetzt werden.
Wenn ein Wert, der vom Nutzer beeinflusst werden kann, am Beginn eines SRC oder HREF Parameters dargestellt wird, sollten Sie darauf achten, dass der Wert nicht mit javascript:, vbscript: oder data: beginnt. Der Code <a href=“javascript:alert(‘hacked’)“> ist zum Beispiel potentiell gefährlich.
Interne und externe Audits
Externer Audit: Eine Überprüfung Ihrer Website mithilfe von Schwachstellen-Scannern sowie Scannern, die Hacking-Aktivität imitieren und versuchen, mit bekannten Techniken, in Ihre Website einzudringen.
Interner Audit: Interne Audits bestehen aus einer ganzen Reihe von Massnahmen. Enthalten sein sollten: Logfile-Analysen, Analysen von Start-Prozessen, kürzlich geänderter Dateien und offener Ports, Scannen des Website-Inhalts mit Anti-Virus- oder Anti-Rootkit-Software, Traffic-Analyse um ungewöhnliche Aktivitäten festzustellen (wie erhöhten Datentransfer).
