Webapplikationen sind das häufigste Ziel bei Bug-Bounty-Suchen — deshalb ist ein klares Verständnis der typischen Schwachstellen essenziell. In diesem Teil erkläre ich die Konzepte hinter XSS, SQLi, CSRF, IDOR und weitere häufige Probleme, wie du sie verantwortungsbewusst identifizieren kannst und welche Gegenmaßnahmen Entwickler implementieren sollten. Der Fokus liegt auf Verständnis und verantwortungsvollem Vorgehen, nicht auf ausnutzbaren Details.
Warum diese Schwachstellen so wichtig sind
Web-Apps verarbeiten Benutzereingaben, speichern Daten, kommunizieren über APIs und verwalten Sessions — jede dieser Funktionen ist eine potenzielle Angriffsfläche. Viele erfolgreiche Sicherheitslücken entstehen nicht durch exotische Exploits, sondern durch fehlende Validierung, falsche Authentifizierung oder unsaubere Trennung von Verantwortlichkeiten. Wer die Grundmuster kennt, erkennt Anomalien schneller und liefert wertvollere Reports.
Cross-Site Scripting (XSS) — Grundprinzip
Was es ist: XSS entsteht, wenn eine Anwendung Nutzereingaben in eine Seite einbindet, ohne sie korrekt zu behandeln. Dadurch kann ein Angreifer eigenes Skript in den Browser eines anderen Nutzers einschleusen.
Warum das relevant ist: In der Praxis erlaubt XSS Aktionen wie Session-Diebstahl, UI-Manipulation oder das Einschleusen von Fake-Formularen — alles Dinge, die Benutzer oder Systeme schädigen können.
Wie du prüfen kannst (sicher):
- Analysiere Flows, in denen Nutzereingaben wiedergegeben werden (Kommentare, Profilfelder, Suchergebnisse, Parameter in URLs).
- Beobachte, ob und wie Eingaben im HTML-Kontext, in Attributen oder innerhalb von JavaScript auftauchen.
- Nutze deine lokale Übungsinstanz, um Reflexion/Context-Sensitivity zu verstehen (z. B. wie die App mit Sonderzeichen umgeht).
Gegenmaßnahmen (für Entwickler):
- Kontextbezogenes Escaping (HTML, Attribute, JavaScript).
- Content Security Policy (CSP) ergänzend einsetzen.
- Input-Validierung und Output-Encoding kombinieren.
- HTTP-Only + Secure Cookies, um Cookie-Diebstahl zu erschweren.
SQL Injection (SQLi) — Grundprinzip
Was es ist: SQLi entsteht, wenn untrusted Input direkt in Datenbankabfragen eingefügt wird, ohne Bind-Parameter oder Prepared Statements zu nutzen. Dadurch lässt sich das Verhalten der Abfrage verändern.
Warum das relevant ist: SQLi kann zu Datenverlust, Datenverlust-Änderung oder Eskalation von Rechten führen — oft mit direkten Auswirkungen auf Vertraulichkeit und Integrität.
Wie du prüfen kannst (sicher):
- Fokussiere dich auf Eingabefelder, Filterparameter oder API-Request-Bodies, die mit Datenbankabfragen interagieren.
- Prüfe das Verhalten bei ungewöhnlichen Eingaben in einer kontrollierten, labbasierten Umgebung; dokumentiere Unterschied im Response-Verhalten.
- Keine produktiven Systeme attackieren — nur in Testumgebungen experimentieren.
Gegenmaßnahmen (für Entwickler):
- Prepared Statements / parametrisiertes Query-Design verwenden.
- ORM-Layer korrekt konfigurieren und Input validieren.
- Prinzip der minimalen Rechte für Datenbankkonten (Least Privilege).
- WAF-Ergänzung, Logging und Monitoring für ungewöhnliche Abfragen.
Cross-Site Request Forgery (CSRF)
Was es ist: CSRF ermöglicht es einem Angreifer, einen authentifizierten Benutzer dazu zu bringen, unbeabsichtigte Aktionen auszuführen (z. B. Formular-Submits), indem eine Anfrage im Kontext der bestehenden Session ausgelöst wird.
Warum das relevant ist: Gerade für state-changing Aktionen (Passwort ändern, Geld transferieren) kann CSRF schwerwiegende Folgen haben.
Wie du prüfen kannst (sicher):
- Identifiziere state-changing Endpoints (POST/PUT/DELETE) und prüfe, ob sie gegen unautorisierte Requests abgesichert sind.
- Achte auf das Vorhandensein und die Handhabung von CSRF-Token oder auf sichere SameSite-Cookie-Einstellungen.
Gegenmaßnahmen (für Entwickler):
- CSRF-Token (per Formular oder Header) nutzen und serverseitig validieren.
- Cookies mit
SameSite-Attribut,SecureundHttpOnlysetzen. - Für APIs: OAuth oder andere Token-basierte Authentifizierung statt reinem Cookie-Auth.
Insecure Direct Object Reference (IDOR) / Broken Access Control
Was es ist: IDOR tritt auf, wenn Ressourcen (z. B. IDs in URLs) direkt zugänglich sind und die Anwendung nicht ausreichend prüft, ob der anfragende Benutzer dazu berechtigt ist.
Warum das relevant ist: Durch Änderung einfacher Parameter können Angreifer auf fremde Daten oder Funktionen zugreifen.
Wie du prüfen kannst (sicher):
- Untersuche Endpunkte mit Ressourcen-IDs (z. B.
/profile/12345). - Prüfe, ob eine Änderung der ID ohne Auth-Prüfung zu sichtbaren Änderungen führt — nur in eigener Testumgebung oder mit eindeutiger Genehmigung.
- Dokumentiere, wie die App Authorization prüft (oder eben nicht).
Gegenmaßnahmen (für Entwickler):
- Serverseitige Authorization zwingend prüfen — niemals nur auf Client-Seite vertrauen.
- Use-case-basierte Zugriffskontrollen (RBAC/ABAC) implementieren.
- Minimale Daten in Responses (avoid over-exposing IDs).
Weitere relevante Klassen (kurz)
- Broken Authentication: Schwache Session-Managment, unsichere Passwortrichtlinien; Absicherung durch MFA, Session-Timeouts, sichere Speicherung von Credentials.
- Security Misconfiguration: Fehlende HSTS, offene Directory-Listings, falsche CORS-Settings.
- Sensitive Data Exposure: Unverschlüsselte Datenübertragung/At-Rest; Einsatz von TLS, Verschlüsselung, Masking, Logging-Hygiene.
- Server-Side Request Forgery (SSRF): Server wird veranlasst, interne Ressourcen zu erreichen — kontrollierte Übersichtsarbeit und Netzwerk-Einschränkungen nötig.
Wie ein guter, verantwortungsvoller Testprozess aussieht
- Hypothese formulieren: Welcher Input an welcher Stelle könnte welches Verhalten auslösen?
- Labor-Validierung: Reproduziere das Szenario lokal (Juice Shop, DVWA, Test-API).
- Sanfte Verifikation im Scope: Falls du das Ziel testen darfst, setze sehr zurückhaltende, nicht-zerstörerische Tests ein und protokolliere alles.
- Sauberer Report: Beschreibe: betroffener Endpoint, erwartetes vs. tatsächliches Verhalten, Reproduktionsschritte (abstrakt), Schweregrad-Begründung, vorgeschlagene Fixes.
- Responsible Disclosure: Melde ausschließlich über den vorgesehenen Kanal; überlasse das Patch-Management dem Betreiber.
Beispiel für einen Report-Baustein (Kurzform)
- Titel: Reflected Input führt zu Script-Ausgabe in User-Profilseite
- Endpoint:
/profile/view(query param:name) - Kurzbeschreibung: Eingaben werden im HTML ohne kontextbezogenes Encoding ausgegeben.
- Auswirkung: Potenzielles Session Hijacking / UI-Manipulation.
- Empfehlung: Kontextbezogenes Escaping + CSP; Input-Sanitization.
- Nachweis: (Screenshots/Heuristische Unterschiede in Response; Repro-Steps nur für Triage).
Schreibe einen Kommentar