OWASP Top 10: Sicherheitslücken im Web

01Was sind OWASP und die Top-10-Liste?

OWASP (Open Worldwide Application Security Project) ist eine offene Community, die kostenlose Ressourcen, Werkzeuge und Leitfäden zur Softwaresicherheit erstellt. Ihr bekanntestes Werk ist die Top 10, die alle paar Jahre aktualisiert wird.

Die Liste ist weder ein Standard noch ein Zertifikat, sondern ein Dokument zur Sensibilisierung. Sie entsteht aus offenen Daten aus der Praxis und Expertenmeinungen und sagt Entwicklern: “Achten Sie zuerst hierauf.” In diesem Beitrag legen wir die Kategorien der weit verbreiteten Ausgabe von 2021 zugrunde.

Die Liste verändert sich mit der Zeit; in neuen Ausgaben rücken Kategorien nach oben oder unten oder werden zusammengelegt. Prüfen Sie die aktuelle Ausgabe daher immer bei der offiziellen Quelle owasp.org.

02Platz 1–2: Zugriffskontrolle und Verschlüsselung

Die ersten beiden Plätze der Liste betreffen die Frage, wem Daten angezeigt werden und wie sie geschützt sind. Beide gehören zu den häufigsten Schwachstellen mit den gravierendsten Folgen, weil sie direkt Kundendaten berühren.

Fehlerhafte Zugriffskontrolle

Ein Fehler in der Zugriffskontrolle liegt vor, wenn ein Benutzer auf Daten oder Aktionen zugreifen kann, für die er keine Berechtigung hat. Klassisches Beispiel: Ein Kunde ändert in der Adresszeile den Wert siparis/1052 in 1053 und sieht die Bestellung eines anderen.

Die Gegenmaßnahme ist einfach, verlangt aber Disziplin: Bei jeder Anfrage muss serverseitig erneut die Frage gestellt werden: “Darf dieser Benutzer diesen Datensatz sehen?” Das Standardverhalten sollte Ablehnen sein; Zugriff wird nur in ausdrücklich erlaubten Fällen gewährt.

Kryptografische Fehler

Hierunter fällt es, wenn sensible Daten unverschlüsselt übertragen oder gespeichert werden. Typische Beispiele sind Passwörter im Klartext oder mit schwachen Verfahren, fehlendes HTTPS und veraltete Verschlüsselungsalgorithmen.

Für Passwörter sollten langsame, dafür ausgelegte Hash-Verfahren wie bcrypt oder Argon2 verwendet werden. Der gesamte Datenverkehr gehört über HTTPS, und Schlüssel dürfen nicht im Code, sondern nur in einer sicheren Umgebung liegen.

03Platz 3: Injection mit SQL-Injection und XSS

Wenn Eingaben von Benutzern als Teil eines Befehls ausgeführt werden, spricht man von einer Injection-Schwachstelle. Die bekanntesten Varianten sind SQL-Injection und XSS. In der Liste von 2021 wird auch XSS unter dieser Kategorie behandelt.

Was ist SQL-Injection?

Bei der SQL-Injection wird eine Datenbankabfrage durch Sonderzeichen verändert, die in ein Formular oder ein Adressfeld eingegeben werden. Angreifer können Daten stehlen, löschen oder sich unbefugt anmelden. Die Lösung: Abfragen nicht per Textverkettung zusammensetzen, sondern mit vorbereiteten Abfragen (Prepared Statements) aufbauen.

// FALSCH: Benutzereingabe wird direkt in die Abfrage eingefügt
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";

// RICHTIG: Prepared Statement
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();

Was ist XSS?

Bei XSS (Cross-Site Scripting) schleust ein Angreifer eigenes JavaScript in die Seite ein. Ein in ein Kommentarfeld eingegebenes Skript kann im Browser jedes Besuchers laufen, der die Seite öffnet. Grundlegende Maßnahmen sind kontextgerechtes Escaping bei der Ausgabe und ein Content-Security-Policy-Header (CSP).

echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');

04Platz 4–5: Unsicheres Design und Konfiguration

Diese beiden Kategorien betreffen weniger den Code selbst als Entscheidungen: wie das System konzipiert und wie der Server eingerichtet ist. Die gute Nachricht: Beides lässt sich weitgehend durch Prozesse und Checklisten verhindern.

Unsicheres Design

Diese Kategorie beschreibt weniger einen Programmierfehler als einen Designfehler. Zum Beispiel, wenn beim Zurücksetzen des Passworts nur auf eine erratbare Sicherheitsfrage gesetzt wird oder ein Aktionscode unbegrenzt oft ausprobiert werden kann. Selbst perfekt geschriebener Code schließt eine Designlücke nicht.

Die Gegenmaßnahme: Sicherheit nicht am Ende, sondern am Anfang der Entwicklung bedenken. Threat Modeling, Missbrauchsszenarien und eine Begrenzung der Versuche (Rate Limiting) gehören in die Designphase.

Fehlkonfiguration der Sicherheit

Hierzu zählen nicht geänderte Standardpasswörter, Fehlermeldungen mit Serverdetails, unnötig geöffnete Dienste oder aktivierte Verzeichnislisten. Diese Lücken lassen sich oft am leichtesten ausnutzen.

Gegenmaßnahmen: eine schriftliche Härtungsliste für Server und Anwendung erstellen, Fehlerdetails im Live-Betrieb abschalten, Sicherheits-Header (etwa HSTS, CSP, X-Content-Type-Options) setzen und die Konfiguration regelmäßig prüfen.

05Platz 6–7: Komponenten und Authentifizierung

Die Risiken auf Platz sechs und sieben betreffen die von außen eingebundenen Bausteine einer Anwendung und die Art, wie die Identität des Benutzers geprüft wird. Beides erfordert laufende Pflege; einmal einrichten und vergessen reicht nicht.

Veraltete und verwundbare Komponenten

Eine moderne Anwendung nutzt Dutzende, teils Hunderte externe Bibliotheken. Wird in einer davon eine Schwachstelle entdeckt, ist Ihre Anwendung gefährdet, selbst wenn Ihnen keine einzige Zeile Code fehlerhaft unterlaufen ist.

Gegenmaßnahmen: eine Liste der eingesetzten Komponenten führen, Sicherheitsmeldungen verfolgen und Updates regelmäßig einspielen. Die Audit-Befehle der Paketmanager erleichtern das. Nicht genutzte Abhängigkeiten zu entfernen ist ebenfalls eine der günstigsten Sicherheitsmaßnahmen.

npm audit
composer audit

Fehler bei der Authentifizierung

In diese Kategorie fallen schwache Passwörter, unbegrenzte Anmeldeversuche, unsicher gespeicherte Sitzungskennungen oder Sitzungen, die beim Abmelden nicht beendet werden.

Gegenmaßnahmen: Versuche begrenzen, eine Zwei-Faktor-Authentifizierung anbieten, gegen Listen geleakter Passwörter prüfen und Sitzungs-Cookies mit den Attributen HttpOnly, Secure und SameSite konfigurieren.

06Platz 8–10: Integrität, Logging und SSRF

Integrität von Software und Daten

Werden Updates, Plug-ins oder die automatische Deployment-Pipeline ohne Prüfung ausgeführt, öffnet das Angreifern die Tür. Signierte Pakete, vertrauenswürdige Quellen und die Kontrolle der Lieferkette bilden die Grundlage der Gegenmaßnahmen.

Fehlendes Logging und Monitoring

Wird ein Angriff nicht bemerkt, wächst der Schaden. Fehlgeschlagene Anmeldungen, Berechtigungsfehler und kritische Aktionen sollten protokolliert werden, bei ungewöhnlichen Vorgängen sollten Warnungen ausgelöst werden. In Logs dürfen keine sensiblen Daten wie Passwörter stehen.

SSRF

Bei SSRF (Server-Side Request Forgery) wird der Server dazu gebracht, eine Anfrage an eine vom Benutzer gelieferte Adresse zu senden. So können Angreifer auf Dienste im internen Netz zugreifen. Die grundlegende Maßnahme ist eine Positivliste (Allowlist) der erreichbaren Adressen.

07Checkliste für sicheres Programmieren

Die meisten Schwachstellen lassen sich durch wenige grundlegende Gewohnheiten verhindern. Die folgende Liste können Sie bei Code-Reviews und Prüfungen vor dem Livegang nutzen. Wie Tests mit Sicherheit zusammenhängen, haben wir in unserem Beitrag Was ist Softwaretest? behandelt.

1. Vertrauen Sie Eingaben niemals: Validieren Sie alle Eingaben serverseitig.
2. Nutzen Sie vorbereitete Abfragen: SQL nicht per Textverkettung bauen.
3. Escapen Sie die Ausgabe: passend zum HTML-, URL- und JavaScript-Kontext.
4. Prüfen Sie Berechtigungen bei jeder Anfrage: Ausblenden in der Oberfläche genügt nicht.
5. Trennen Sie Geheimnisse vom Code: Schlüssel gehören in Umgebungsvariablen oder einen Tresor.
6. Halten Sie Abhängigkeiten aktuell: Führen Sie regelmäßig den Audit-Befehl aus.
7. Protokollieren und überwachen Sie: Erkennen Sie verdächtige Vorgänge.

08Der Beitrag sicherer Sprachen und Werkzeuge

Manche Schwachstellenarten lassen sich auch durch die Wahl von Sprache und Werkzeugen verringern. Speichersichere Sprachen verhindern beispielsweise weitgehend die in C und C++ häufigen Pufferüberläufe; dazu mehr in unserem Beitrag Was ist Rust? Auch WebAssembly, das im Browser in einer sicheren Sandbox läuft, beruht auf einer ähnlichen Isolationslogik.

Dennoch löst keine Sprache einen Fehler bei Zugriffskontrolle oder Design von selbst. Der Großteil der Sicherheit bei Webanwendungen hängt von den Gewohnheiten und Prozessen des Teams ab.

Bei Aurora Yazılım werden diese Grundprinzipien in Branchensoftware-Lösungen, bei der Unternehmenswebsite und beim Shopsystem als Teil des Entwicklungsprozesses umgesetzt.