Ein grünes Schloss in der Adressleiste garantiert nicht viel. Kostenlose SSL-Zertifikate kann jede Website erhalten, einschließlich Phishing-Seiten. Die Sicherheit einer Website zu überprüfen, erfordert mehr als nur diesen einfachen visuellen Indikator, indem man Schichten untersucht, die weder der Browser noch der durchschnittliche Benutzer sieht.
API-Sicherheit: Der blinde Fleck eines Website-Audits
Sie besuchen eine Webseite, sehen Text, Bilder, ein Formular. Im Hintergrund fragt diese Seite oft mehrere APIs ab, um Daten abzurufen oder zu senden. Diese Programmierschnittstellen sind zu einem bevorzugten Ziel für Angreifer geworden.
Die Berichte von 2024 bestätigen, dass Angriffe auf APIs einen wachsenden Anteil der Vorfälle bei Webanwendungen ausmachen. Das Problem: Die meisten klassischen Überprüfungen beschränken sich auf die sichtbaren Seiten. Die API-Endpunkte bleiben im Schatten.
Ein effektives Audit beginnt mit einer vollständigen Bestandsaufnahme dieser Endpunkte. Einige wurden für einen einmaligen Bedarf erstellt und dann vergessen. Andere sind unvollständig dokumentiert. Gerade diese stellen ein Problem dar, weil niemand daran denkt, ihre Authentifizierung oder Berechtigungen zu überprüfen.
Konkrett muss jeder API-Eingang individuell getestet werden. Es wird überprüft, ob die Authentifizierung objektweise funktioniert (Benutzer A darf nicht auf die Daten von Benutzer B zugreifen), ob Ratenlimits vorhanden sind und ob veraltete APIs tatsächlich entfernt wurden. Mehrere Tools ermöglichen es, einen Teil dieser Sicherheitsüberprüfung von Websites zu automatisieren, aber die manuelle Überprüfung bleibt für die Berechtigungsprüfungen notwendig.
Schwachstellen priorisieren: Warum der CVSS-Score nicht ausreicht
Wenn ein Scanner eine Liste von Schwachstellen zurückgibt, wird jede von einem Schweregrad-Score (CVSS) begleitet. Die Versuchung besteht darin, zuerst die höchsten Scores zu behandeln. Dieser Ansatz scheint logisch, übersieht jedoch eine entscheidende Tatsache: Angreifer nutzen vor allem bekannte und dokumentierte Schwachstellen aus, nicht unbedingt die ausgeklügeltsten.
Die CISA führt ein Katalog namens Known Exploited Vulnerabilities (KEV). Dieser listet Schwachstellen auf, die aktiv in der Natur ausgenutzt werden. Eine Schwachstelle mit einem durchschnittlichen CVSS-Score, die in diesem Katalog aufgeführt ist, verdient sofortige Behebung. Umgekehrt kann eine theoretische Schwachstelle mit einem sehr hohen Score, die nie ausgenutzt wurde, warten.
Für eine wirklich nützliche Überprüfung sollten drei Kriterien kombiniert werden:
- Die technische Schwere, die durch den CVSS-Score angegeben wird, der das Schadenspotenzial der Schwachstelle misst.
- Die Präsenz im KEV-Katalog der CISA, die angibt, ob die Schwachstelle aktiv von Angreifern ausgenutzt wird.
- Die tatsächliche Exposition der betroffenen Komponente: Ein über das Internet zugänglicher Dienst ist dringlicher als ein internes Tool hinter einem VPN.
Die Kombination von technischer Schwere, aktiver Ausnutzung und tatsächlicher Exposition verändert radikal die Prioritäten für die Behebung. Ohne diese Sortierung kann ein Unternehmen Wochen mit einer theoretischen Schwachstelle verbringen, während eine ausgenutzte Lücke offen bleibt.
Open-Source-Komponenten und KI-Modelle in der Sicherheitsanalyse
Die Mehrheit der modernen Websites basiert auf Open-Source-Bibliotheken. Ein CMS, ein JavaScript-Framework, ein Zahlungsmodul: Jedes enthält Drittanbieter-Code mit eigenen potenziellen Schwachstellen.
Die Überprüfung dieser Komponenten erfordert eine präzise Bestandsaufnahme, oft als Software Bill of Materials (SBOM) bezeichnet. Dieses Dokument listet jede Abhängigkeit, ihre Version und ihren Wartungsstatus auf. Eine von ihren Betreuern aufgegebene Komponente ist ein stilles Risiko: Es wird kein Update kommen, um nach der Aufgabe entdeckte Schwachstellen zu beheben.
Funktionen, die Künstliche Intelligenz integrieren, stellen ein zusätzliches Problem dar. Ein KI-Modell, das über eine API exponiert wird, kann durch Anfragen manipuliert werden, die darauf ausgelegt sind, Trainingsdaten zu extrahieren oder Filter zu umgehen. Diese Angriffsvektoren sind von klassischen Scannern noch schlecht abgedeckt.
Serverkonfiguration und HTTP-Header überprüfen
Bevor überhaupt nach Schwachstellen im Code gesucht wird, offenbart die Serverkonfiguration oft einfache Probleme, die leicht zu beheben sind. Die HTTP-Header beispielsweise steuern, wie der Browser mit der Website interagiert.
Ein gut konfigurierter Content-Security-Policy-Header blockiert die Mehrheit der XSS-Angriffe. Im Gegensatz dazu sind einige früher empfohlene Header mittlerweile veraltet. X-XSS-Protection ist beispielsweise laut der MDN-Dokumentation in modernen Browsern nicht mehr nützlich. Das Kopieren einer Konfiguration, die in einem Forum von 2018 gefunden wurde, kann ein falsches Sicherheitsgefühl vermitteln.
Die Punkte, die auf der Serverseite überprüft werden sollten:
- Das HTTPS-Protokoll ist aktiv mit einem gültigen Zertifikat, und die HTTP-Weiterleitungen zu HTTPS funktionieren ohne Schleifen.
- Empfindliche Dateien (Backups, Konfigurationsdateien, .git-Verzeichnisse) sind nicht öffentlich zugänglich.
- Die Sicherheitsheader sind aktuell und an den Kontext der Website angepasst, nicht einfach von einer generischen Vorlage kopiert.
- Die Fehlermeldungen des Servers geben keine technischen Informationen preis (Softwareversionen, Dateipfade).
Überprüfung nach der Behebung: Der Schritt, den die meisten Unternehmen auslassen
Eine Schwachstelle zu erkennen, sie zu beheben und zur nächsten überzugehen. Dieser Zyklus scheint vollständig, aber es fehlt ein formeller Schritt: bestätigen, dass die Behebung tatsächlich funktioniert.
Die Daten von 2024 zeigen, dass bekannte Schwachstellen über längere Zeiträume offen bleiben, selbst in Unternehmen, die mit Scannern ausgestattet sind. Der Patch wurde in einer Testumgebung bereitgestellt, aber nicht in der Produktion. Oder das Update wurde angewendet, aber eine verwundbare Version der Komponente läuft noch auf einem anderen Server.
Die Überprüfung nach der Behebung sollte einen neuen Scan umfassen, der auf die behandelte Schwachstelle abzielt, eine manuelle Überprüfung, dass der Patch keine Regression (eine defekte Funktion, ein Formular, das Eingaben nicht mehr validiert) verursacht hat, und eine Kontrolle, dass die verwundbaren Versionen aus allen exponierten Umgebungen entfernt wurden.
Dieser Schritt verwandelt einen Auditbericht in eine messbare Verbesserung. Ohne ihn bleibt der Bericht ein PDF-Dokument, das in einem Ordner abgelegt wird, und die Schwachstelle bleibt ausnutzbar.
