Sicherheitsniveau von Websites: Was 884 Prüfungen von Smart Audit gezeigt haben
Smart Audit hat 884 Unternehmenswebsites passiv geprüft. Die durchschnittliche Sicherheitsbewertung liegt bei 19 von 100, und bei jeder fünften Website sind von außen Dienstdateien offen erreichbar: Benutzerlisten, Git-Verzeichnisse, Dateien mit Passwörtern, sogar Kopien von Datenbanken. Wir erklären die Zahlen ohne Fachjargon: was das für den Inhaber bedeutet und womit man bei der Behebung beginnen sollte.
- Was wir geprüft haben — 884 Unternehmenswebsites mit Smart Audit: passiv, nur öffentliche Seiten, ohne etwas zu verändern. Die durchschnittliche Sicherheitsbewertung liegt bei 19 von 100.
- Was wir gefunden haben — Bei jeder fünften Website (19 %) sind Dienstdateien offen erreichbar: Benutzerlisten, Git-Verzeichnisse, .env-Dateien, sogar Kopien von Datenbanken. 9 von 10 Websites haben keine Content Security Policy (CSP).
- Was zu tun ist — Zuerst die offenen Dienstdateien schließen und das System aktualisieren, danach Header, HTTPS und Formulare. Ihre Website können Sie kostenlos in drei Minuten prüfen.
Eine Website, die sich öffnen lässt, ist noch nicht automatisch geschützt. Der Inhaber sieht die Startseite, das Bestellformular und den Katalog – und schließt daraus, dass alles in Ordnung ist. Doch ein Teil dessen, was mit einer Website passiert, ist nur von außen sichtbar, mit den Augen eines Menschen, der sie prüft.
Wir haben den Dienst Smart Audit gestartet, der fremde Websites genau so betrachtet: passiv und nur anhand der öffentlichen Seiten. Er verändert nichts, probiert keine Passwörter aus und dringt nirgends ein. Zum Zeitpunkt der Vorbereitung dieses Artikels lagen uns Ergebnisse von 884 einzigartigen Unternehmenswebsites vor – berücksichtigt wird jeweils die letzte erfolgreiche Prüfung. Wir haben nicht nach „gelungenen“ oder „misslungenen“ Fällen ausgewählt: In der Stichprobe sind Onlineshops, Unternehmenswebsites, Medien und Websites großer Organisationen. Namen nennen wir nicht – uns interessiert das Gesamtbild, nicht einzelne Adressen.
Im Folgenden: was wir gesehen haben, was das für den Inhaber bedeutet und womit man bei der Behebung beginnen sollte.
Das Gesamtbild: 22 Punkte von 100
Die durchschnittliche Gesamtbewertung über alle 884 Websites liegt bei 22 von 100. Nach Bereichen getrennt: Sicherheit – 19, Geschwindigkeit – 18, Sichtbarkeit in der Suche – 17.
- 480 Websites (54 %) erreichten weniger als 20 von 100 Punkten;
- 286 (32 %) – zwischen 20 und 39;
- 96 (11 %) – zwischen 40 und 59;
- nur 22 Websites (2,5 %) kamen auf 60 und mehr.
Bei der Sicherheitsbewertung allein sieht es so aus: Bei 466 Websites (53 %) liegt sie unter 10 Punkten, bei 652 (74 %) unter 30, und nur 75 Websites (8,5 %) erreichten 60 und mehr.
Gleich ein Vorbehalt, damit die Zahlen nicht falsch gelesen werden. „22 von 100“ bedeutet nicht, dass eine Website zu 22 % geschützt ist, und erst recht nicht, dass sie gehackt wurde. Es ist der Abstand zu einem Grundset an Prüfungen: Aktiviert die Website die Schutzmaßnahmen, die längst als Standard gelten? Die meisten Punkte gehen bei Dingen verloren, die sich schnell und günstig beheben lassen. Genau deshalb lohnt es sich, bei diesen Zahlen genauer hinzusehen.
Die erste Schicht: Türen ohne Riegel
Jede Seite, die der Server an den Browser ausliefert, wird von technischen „Anweisungen“ begleitet: was dieser Seite erlaubt ist und was nicht. Das sind die sogenannten Sicherheits-Header. Sie machen eine Website nicht undurchdringlich, fangen aber den Schlag ab, wenn sich eine andere Lücke findet. Und hier fehlt es fast flächendeckend:
- Die Content Security Policy (CSP) fehlt bei 90 % der Websites. Sie legt fest, welche Skripte der Browser auf der Seite ausführen darf. Ohne sie läuft jeder eingeschleuste Code gleichberechtigt neben dem „eigenen“. So tauchen auf Bestellseiten Skimmer auf – Skripte, die unbemerkt Bankkartendaten kopieren. Für einen Shop (und davon gibt es in der Stichprobe 130) ist das der teuerste fehlende „Riegel“.
- Die Permissions-Policy fehlt bei 93 %. Sie begrenzt, was in die Website eingebettete Widgets vom Besucher anfordern dürfen: Kamera, Mikrofon, Standort.
- Die Referrer-Policy fehlt bei 88 %. Ohne sie gelangen die vollständigen Adressen Ihrer Seiten – samt interner Bestellnummern oder Tokens in den Links – an fremde Zähler und Werbedienste.
- Einen Schutz vor dem Einbetten in fremde Frames gibt es bei 73 % nicht. Ein Angreifer kann Ihre Website in einem durchsichtigen Rahmen auf seiner Seite anzeigen und eine Person dazu bringen, auf einen „Button“ zu klicken, der in Wirklichkeit auf Ihrer Website liegt. Dieser Trick heißt Clickjacking.
- Das Verbot, den Dateityp zu „erraten“, fehlt bei 71 % (nosniff).
- HSTS ist bei 62 % nicht aktiviert. Ohne es kann der erste Besuch einer Person über einen unverschlüsselten Kanal laufen – und in einem öffentlichen Wi-Fi ist das eine Chance, die Seite zu manipulieren.
Ehrlich gesagt: Ein fehlender Header ist keine gehackte Website. Es ist eine fehlende Schutzebene. Sie lässt sich aber mit wenigen Zeilen in den Servereinstellungen schließen, deshalb sagt ihr Fehlen fast immer dasselbe aus: Um die Sicherheitseinstellungen hat sich niemand gekümmert.
Die zweite Schicht: was offen herumliegt
Dieser Abschnitt ist ernster. Bei 172 von 884 Websites (19 %) – also fast jeder fünften – sind von außen Dienstadressen erreichbar, die nie öffentlich sein sollten. Manche Websites haben mehrere solcher Stellen gleichzeitig. Verteilung nach Typ:
- Liste der WordPress-Benutzerkonten – 103 Websites (12 %). Die Standardadresse gibt die Logins der Benutzer preis, darunter die der Administratoren. Die Hälfte der Arbeit des Angreifers ist damit getan: Der Login ist bekannt, es bleibt, das Passwort zu erraten.
- Git-Dienstverzeichnis – 45 Websites (5 %). Daraus lässt sich der Quellcode der Website wiederherstellen, und in der Änderungshistorie finden sich mitunter Passwörter und Schlüssel, die irgendwann „vorübergehend“ in den Code geschrieben wurden.
- phpinfo-Seite – 43 Websites (5 %). Sie zeigt PHP-Versionen, Module, Serverpfade und Umgebungsvariablen. Für einen Angreifer ist das eine fertige Landkarte.
- Dienstseite zum Serverstatus – 34 Websites (4 %). Man sieht, welche Adressen Besucher gerade aufrufen und von welchen IPs.
- Konfigurationsdatei .env – 33 Websites (4 %). In so einer Datei liegen üblicherweise Passwörter für die Datenbank sowie Schlüssel für E-Mail- und Zahlungsdienste.
- Datenbankkopie – 28 Websites (3 %). Eine Datei, die jemand „nur kurz“ im Stammverzeichnis der Website liegen ließ: Kunden, Bestellungen, Telefonnummern, Adressen.
Wichtig zu verstehen: Hier muss nichts gehackt werden. Es genügt, die Adresse im Browser zu öffnen. Smart Audit greift auf den Inhalt dieser Dateien nicht zu: Er stellt lediglich fest, dass unter einer solchen Adresse etwas antwortet; der Inhalt wird weder gelesen noch gespeichert. Doch was wir nicht tun, kann jeder andere tun – und automatische Scanner durchkämmen solche Adressen rund um die Uhr im gesamten Internet.
Die dritte Schicht: veraltete Software
Unter den geprüften Websites läuft die größte Gruppe auf WordPress – 222 (25 %), danach folgt OpenCart – 88 (10 %). Bei den übrigen wurde die Plattform nicht erkannt, oder die Website ist eine Individualentwicklung.
154 Websites (17 %) verraten selbst, welche Version des Systems sie nutzen. Das ist in den technischen Meta-Angaben der Seite zu sehen. Für sich genommen schaden sie nicht – schädlich ist die Kombination mit einer alten Version. Unter denen, die ihre WordPress-Version preisgeben, laufen 22 Websites auf den Zweigen 4 und 5, die vor vielen Jahren erschienen sind. Bei solchen Versionen sollte man nicht darauf zählen, dass jemand neu entdeckte Schwachstellen noch schließt.
Ein eigenes Thema ist die Version des Servers selbst. Bei 247 Websites (28 %) nennen die Antwort-Header die genauen Versionen der Serversoftware. Der Angreifer muss nicht raten: Er sieht die Version und greift sofort zu der dafür bekannten Methode. Wie wesentlich das ist, zeigt das Beispiel der kritischen Schwachstellen in PHP: Dort besteht der einzige Schutz in der rechtzeitigen Aktualisierung. Und die Kehrseite – was passiert, wenn ohne Vorbereitung aktualisiert wird – haben wir in der Analyse der automatischen Plugin-Aktualisierung beschrieben.
Die vierte Schicht: Formulare und Verbindungen – dort, wo Kundendaten in die Website gelangen
Über Formulare übermittelt ein Mensch Ihnen Name, Telefonnummer, Adresse, manchmal auch die Zahlung. Deshalb ist ihr Aufbau besonders wichtig. Das haben wir gefunden:
- 489 Websites (55 %) – Formulare ohne Schutz vor Anfragefälschung (CSRF). Das heißt: Eine fremde Seite kann den Browser Ihres Besuchers oder Ihres Administrators dazu bringen, ein Formular in seinem Namen abzuschicken, ohne ihn zu fragen.
- 543 (61 %) – Formulare, die personenbezogene Daten ohne Einwilligung in die Verarbeitung erfassen. Dabei geht es nicht nur um Sicherheit: Es ist auch eine Frage der Einhaltung der Datenschutzgesetze.
- 532 (60 %) – Formulare ohne Schutz vor Bots. Die Folge kennt jeder, der ein Postfach voller Spam aus „Anfragen“ gesehen hat.
- 76 Websites (9 %) – Formulare übertragen personenbezogene Daten in der Seitenadresse (GET-Methode). Telefonnummer und Name bleiben im Browserverlauf und in den Serverprotokollen und gelangen samt Adresse an fremde Dienste.
- 321 (36 %) – cookie ohne Schutzmerkmale. Sie lassen sich leichter abfangen oder per Skript auslesen.
Und einige Grundlagen, die man längst überall erwarten würde: 35 Websites (4 %) öffnen sich überhaupt ohne Verschlüsselung (der Browser zeigt bei ihnen die Warnung „Nicht sicher“ an), bei 43 läuft das Zertifikat demnächst ab, und bei 36 Websites wird ein Teil des Inhalts einer geschützten Seite über einen ungeschützten Kanal nachgeladen – dadurch wirkt die Verschlüsselung nicht vollständig.
Was das für den Inhaber bedeutet
Lässt man den Fachjargon weg, bleiben für das Geschäft nur wenige Risiken.
- Abfluss von Kundendaten. Eine offene Datenbankkopie oder Konfigurationsdatei ist keine „technische Kleinigkeit“, sondern die Möglichkeit, Ihre Kundenliste mitzunehmen, ohne etwas zu hacken. Danach drohen Reputationsverlust und Haftung für den Schutz personenbezogener Daten.
- Fremder Code auf Ihrer Website. Versäumte Updates plus fehlende CSP – und auf den Seiten erscheint Casino-Werbung, es gibt Weiterleitungen auf fremde Websites, oder auf der Zahlungsseite sitzt ein Skimmer. Sie erfahren es womöglich von einem Kunden und nicht von sich selbst.
- Der Vermerk „unsichere Website“ und der Absturz in der Suche. Browser und Suchmaschinen gehen bei Besuchern kein Risiko ein. Eine gehackte Website kann in den Suchergebnissen um Wochen zurückfallen, und die Rückkehr dauert länger, als der Verlust gedauert hat.
- Ausfallzeit und Wiederherstellungskosten. Die Wiederherstellung nach einem Hack kostet in der Regel um ein Vielfaches mehr als die Vorsorge. Und solange die Website steht, gibt es keine Bestellungen.
- Vertrauensverlust bei Partnern. Immer öfter verlangen große Kunden und Ausschreibungen einen Nachweis, wie es bei Ihnen um die Sicherheit steht. Die Antwort „wissen wir nicht“ bringt keine Punkte.
Womit man beginnen sollte: eine bewährte Reihenfolge
- Offene Dienstdateien schließen. Das sind die teuersten Lücken, und sie lassen sich am schnellsten beheben: Meist genügt eine Stunde Arbeit. Dateien mit Passwörtern aus dem Zugriff nehmen und die Passwörter danach ändern, denn man darf nicht davon ausgehen, dass sie nicht abgeflossen sind.
- System und Plugins aktualisieren und die genauen Versionen aus den Serverantworten entfernen. Aktualisieren Sie an einer Kopie der Website und nicht blind auf der Live-Version.
- Sicherheits-Header ergänzen. Beginnen Sie mit HSTS, dem Schutz vor dem Einbetten, nosniff und Referrer-Policy – sie machen fast nie etwas kaputt. CSP schrittweise einführen, zuerst im Beobachtungsmodus.
- HTTPS in Ordnung bringen: automatische Verlängerung des Zertifikats, Weiterleitung von http, kein ungeschützter Inhalt.
- Formulare prüfen: Token gegen Anfragefälschung, Schutz vor Bots, Übertragung ausschließlich per POST, eine verständliche Einwilligung in die Datenverarbeitung.
- Sicherungen außerhalb der Website und Monitoring einrichten. Eine Kopie, die neben der Website liegt, verschwindet bei einem Hack gemeinsam mit ihr. Und die Erreichbarkeit der Website sollte nicht erst der Kunde prüfen.
Wie wir helfen
Smart Audit beantwortet die Frage „Was genau ist nicht in Ordnung?“ in der Sprache der Prioritäten: Der Bericht trennt die Befunde in solche, die sofort sichtbar sind, und solche, die in der Plattform der Website selbst angelegt sind. Die ersten beheben wir auf Ihrer bestehenden Website. Die zweiten – alte Versionen, Einschränkungen des Systems, die Unmöglichkeit, den Schutz ordentlich einzurichten – lösen sich in der Regel durch den Umzug auf unser System Smart CMS, in dessen Grundlage Sicherheits-Header, Formularschutz und Updates bereits eingebaut sind. Den Umzug führen wir selbst durch: Wir übertragen Seiten und Adressen, bewahren die Einstellungen zur Sichtbarkeit in der Suche und unterstützen Sie in jeder Phase, damit Sie weder Traffic noch Bestellungen verlieren.
Wie auch immer Sie beginnen möchten: Zuerst lohnt es sich, das eigene Bild zu sehen.
Ihre Website können Sie kostenlos, ohne Registrierung und in drei Minuten auf audit.sgt.com.ua prüfen. Und wenn Sie möchten, dass wir uns das Ergebnis gemeinsam mit Ihnen ansehen und offen sagen, was zuerst zu beheben ist – schreiben Sie uns.
