Die OWASP Top 10 wurde als allgemeines Sensibilisierungsdokument für die Sicherheit von Webanwendungen konzipiert. Sie deckt die kritischsten Risiken für alle Webanwendungen ab. Aber Legacy-Anwendungen — Systeme, die vor 2018 auf älteren Frameworks mit angesammelten technischen Schulden erstellt wurden — sind diesen Risiken anders ausgesetzt als moderne Anwendungen.
Einige OWASP-Kategorien sind in Legacy-Systemen katastrophal häufig anzutreffen. Andere sind weniger relevant, weil Legacy-Apps vor den Mustern entstanden sind, die sie verursachen. Dieser Leitfaden priorisiert die Liste speziell für Legacy-Systeme, damit Sie wissen, worauf Sie Ihre begrenzte Sanierungszeit konzentrieren müssen.
Die Prioritätenliste für Legacy-Systeme
Priorität 1: A03 — Injection
Warum es die Nummer 1 bei Legacy-Systemen ist: Moderne Frameworks machen Injections durch parametrisierte Abfragen und ORMs nahezu unmöglich. Legacy-Anwendungen, insbesondere in PHP und klassischem ASP, konstruieren SQL-Abfragen häufig durch String-Verkettung — genau das Muster, das Injections ermöglicht.
Worauf Sie achten sollten:
// Dieses Muster ist eine Injection-Schwachstelle
$query = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";
// Dieses Muster ist sicher
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute([':email' => $_POST['email']]);
Wie man es findet: Statische Analysetools wie PHPStan, Semgrep oder sogar grep nach mysql_query, $_GET, $_POST in der Nähe von SQL-Strings. Bei einem professionellen Audit unterziehen wir jede Datenbankinteraktion einer Taint-Analyse, um sicherzustellen, dass Benutzereingaben niemals ohne Parametrisierung in die SQL-Ausführung gelangen.
Aufwand für die Behebung: Mittel. Jeder Injection-Punkt erfordert das Umschreiben der Abfrage auf Prepared Statements. In großen Codebasen können das Hunderte von Abfragen sein — systematische, mühsame, aber unkomplizierte Arbeit.
Priorität 2: A07 — Fehler in der Identifizierung und Authentifizierung
Warum Legacy-Systeme anfällig sind: Legacy-Anwendungen implementieren die Authentifizierung oft von Grund auf neu, anstatt das Authentifizierungssystem eines Frameworks zu nutzen. Häufige Probleme:
- Passwörter werden in MD5 oder SHA-1 gespeichert — beides ist mit moderner Hardware rechnerisch trivial zu knacken.
- Keine Konto-Sperrung (Account Lockout) — Brute-Force-Angriffe können unbegrenzt laufen.
- Session-Fixation — die Session-ID ändert sich nach dem Login nicht, was Angreifern ermöglicht, sie im Voraus festzulegen.
- Session-Tokens in URLs — die Session-ID leckt über Referrer-Header, den Browserverlauf und Zugriffsprotokolle.
Wie man es behebt:
// Passwort-Hashing: Nicht selbst programmieren
// Alt (unsicher)
$hash = md5($password);
// Neu (sicher, adaptiv, automatisch gesalzen)
$hash = password_hash($password, PASSWORD_ARGON2ID);
$valid = password_verify($input, $hash);
Aufwand für die Behebung: Hoch. Die Authentifizierung berührt jeden Teil der Anwendung. Planen Sie 1–2 Wochen für eine gründliche Überarbeitung ein.
Priorität 3: A06 — Anfällige und veraltete Komponenten
Warum dies für Legacy-Systeme kritisch ist: Eine moderne Anwendung mit Composer, npm oder pip kann audit ausführen und jede bekannte CVE in ihrer Abhängigkeitskette sehen. Bei Legacy-Anwendungen werden Abhängigkeiten oft manuell bereitgestellt — als ZIP-Dateien heruntergeladen, modifiziert und ohne Versionsverfolgung in ein lib/-Verzeichnis abgelegt.
Sie können nichts patchen, was Sie nicht identifizieren können.
Wie man es prüft:
- Inventarisieren Sie jede Drittanbieter-Bibliothek in der Codebase (suchen Sie in
lib/,vendor/,includes/,third_party/). - Identifizieren Sie die Version — suchen Sie nach Versionskonstanten, README-Dateien oder Changelogs.
- Gleichen Sie die Daten mit der National Vulnerability Database oder der Schwachstellen-Datenbank von Snyk ab.
Aufwand für die Behebung: Variabel. Für einige Bibliotheken gibt es modernen Ersatz über Composer oder npm. Für andere muss eine völlig neue Alternative gefunden werden.
Priorität 4: A01 — Fehlerhafte Zugriffskontrolle
Warum Legacy-Systeme hier scheitern: Moderne Frameworks erzwingen Autorisierung durch Middleware, Dekoratoren oder Policy-Klassen. Legacy-Anwendungen prüfen Berechtigungen oft inline — if ($user->role === 'admin'), verstreut über die gesamte Codebase. Dieser Ansatz ist fragil: Übersieht man eine einzige Prüfung, entsteht ein Bug zur Rechteausweitung.
Häufige Muster in Legacy-Code:
- Horizontale Rechteausweitung: Benutzer A kann auf die Daten von Benutzer B zugreifen, indem er eine ID in der URL ändert (
/profile?id=1234). - Vertikale Rechteausweitung: Normale Benutzer können auf Administrator-Endpunkte zugreifen, weil die Autorisierungsprüfung fehlt.
- Unsichere direkte Objektverweise: Datenbank-IDs werden ohne Überprüfung der Besitzverhältnisse in URLs exponiert.
Wie man es behebt: Zentralisieren Sie die Autorisierung in einer Middleware oder einem Service-Layer. Jede Anfrage sollte eine Autorisierungsprüfung durchlaufen, bevor sie die Geschäftslogik erreicht — niemals danach.
Priorität 5: A05 — Sicherheitsfehlkonfigurationen
Warum sie sich in Legacy-Systemen häufen: In Legacy-Anwendungen sammeln sich Konfigurationsabweichungen an. Der Debug-Modus bleibt in der Produktion aktiviert. Standard-Anmeldeinformationen, die nie geändert wurden. Directory Listings auf dem Webserver sind aktiviert. Fehlermeldungen, die Stack-Traces, Dateipfade und Datenbankschemata preisgeben.
Quick Wins:
# php.ini in Produktion
display_errors = Off
expose_php = Off
allow_url_include = Off
# .htaccess oder nginx config
# Directory Listing deaktivieren
Options -Indexes
# Server-Signatur entfernen
ServerSignature Off
Aufwand für die Behebung: Gering. Die Behebung von Sicherheitsfehlkonfigurationen ist oft die Sanierungsarbeit mit dem höchsten ROI — ein paar Stunden Konfigurationsänderungen können eine erhebliche Angriffsfläche schließen.
Priorität 6: A02 — Kryptografische Fehler
Worauf Sie in Legacy-Systemen achten sollten:
- HTTP statt HTTPS — insbesondere bei Login-Formularen und API-Endpunkten.
- Schwache Hashing-Algorithmen — MD5, SHA-1 für Passwörter oder sensible Daten.
- Fest einkodierte Verschlüsselungsschlüssel — im Quellcode anstatt in Umgebungsvariablen oder einem Secrets-Manager.
- Fehlende Verschlüsselung im Ruhezustand (at rest) — sensible Daten werden im Klartext in der Datenbank gespeichert.
Aufwand für die Behebung: Mittel. Der Wechsel zu HTTPS ist operativ unkompliziert. Die Migration von Passwort-Hashes erfordert einen mehrstufigen Ansatz (Neu-Hashing beim nächsten Login).
Geringere Priorität für Legacy-Systeme
Die verbleibenden OWASP-Kategorien — A04: Unsicheres Design, A08: Fehler in der Software- und Datenintegrität, A09: Unzureichendes Sicherheits-Logging und Monitoring, A10: Server-Side Request Forgery (SSRF) — sind wichtig, aber typischerweise in Legacy-Systemen weniger kritisch, da:
- Unsicheres Design betrifft Architekturfehler in neuer Software. Designprobleme von Legacy-Systemen werden besser durch Migration/Refactoring gelöst.
- SSRF tritt häufiger in modernen cloud-nativen Anwendungen auf, die serverseitige HTTP-Anfragen stellen.
- Logging-Fehler sind real, stellen aber keinen direkten Angriffsvektor dar.
Der 80/20-Sanierungsplan
Wenn Sie nur begrenzte Zeit und ein begrenztes Budget haben, priorisieren Sie in dieser Reihenfolge:
- SQL-Injection beheben — jeder einzelne Fall, ohne Ausnahmen. Das ist der Angriffsvektor, der zu Datenschutzverletzungen führt.
- Passwort-Hashing aktualisieren — wechseln Sie von MD5/SHA-1 zu Argon2id oder bcrypt. Tun Sie dies beim nächsten Login für jeden Benutzer.
- Abhängigkeiten überprüfen — identifizieren Sie alles, was Ihre Anwendung importiert, prüfen Sie auf CVEs, aktualisieren Sie, was möglich ist.
- Konfiguration absichern — schalten Sie die Fehleranzeige aus, entfernen Sie Standard-Anmeldedaten, aktivieren Sie Sicherheits-Header.
- Autorisierung zentralisieren — bauen Sie eine Middleware-Schicht auf, die jede Anfrage überprüft, bevor sie die Geschäftslogik erreicht.
Diese Reihenfolge behebt zuerst die Schwachstellen mit dem höchsten Risiko und der höchsten Ausnutzbarkeit. Die ersten vier Punkte können Sie für die meisten Legacy-Anwendungen in unter zwei Wochen erledigen.
Wenn Ihre Anwendung in den letzten 12 Monaten keiner Sicherheitsüberprüfung unterzogen wurde, ist sie überfällig. Ein Projekt zur Sicherheitshärtung arbeitet systematisch Ihre Bedrohungsfläche ab — beginnend mit den OWASP Top 10 und dann tiefergehend in Ihre spezifische Architektur und Compliance-Anforderungen.