Häufige Bugs finden

Einige wenige Schwachstellenklassen bringen den größten Teil der Bug-Bounty-Prämien ein, weil sie häufig auftreten und große Auswirkungen haben. Beherrschen Sie zunächst diese drei:

• IDOR — Zugriff auf die Daten anderer Benutzer über vorhersehbare IDs
• XSS — Einschleusen von Skripten in eine Seite
• SSRF — Den Server dazu bringen, vom Angreifer ausgewählte URLs abzurufen

In dieser Lektion erfahren Sie, wie Sie jede davon systematisch suchen.

Insecure Direct Object Reference (IDOR) tritt auf, wenn eine Anwendung eine vom Benutzer bereitgestellte Kennung verwendet, um ein Objekt abzurufen, ohne zu prüfen, ob der Benutzer dazu berechtigt ist.

Ändern Sie die ID und greifen Sie auf die Daten einer anderen Person zu. Das ist eine Schwachstelle bei der Zugriffskontrolle, keine Injection.

Um IDOR zu finden, erstellen Sie zwei Konten und vergleichen Sie sie. Alles, was über eine ID auf ein Objekt verweist, ist ein möglicher Kandidat.

• Fangen Sie eine Anfrage von Konto A ab, die Daten von A abruft
• Wiederholen Sie sie mit der Sitzung von Konto B, aber der Objekt-ID von A
• Wenn B die Daten von A sieht, handelt es sich um IDOR

Achten Sie auf IDs in URLs, JSON-Bodies, Headern und sogar in Base64- oder UUID-Form.

Cross-Site Scripting (XSS) bezeichnet das Einschleusen von JavaScript, das im Browser eines anderen Benutzers ausgeführt wird. Es gibt drei Haupttypen:

• Reflected — Die Payload wird in der unmittelbaren Antwort zurückgegeben
• Stored — Die Payload wird gespeichert und an andere Benutzer ausgeliefert (größte Auswirkung)
• DOM-based — Clientseitiges JS schreibt Angreifereingaben unsicher in das DOM

Schleusen Sie zunächst einen eindeutigen Marker ein, um zu sehen, wo und wie Ihre Eingabe reflektiert wird. Erstellen Sie anschließend eine Payload, die in den jeweiligen Kontext passt (HTML-Body, Attribut oder Skript).

Der Kontext bestimmt, welche Payload aus dem Kontext ausbrechen und ausgeführt werden kann.

Ein einfaches alert(1) weist die Ausführung nach, aber Reviewer erwarten einen Nachweis der Auswirkungen. Zeigen Sie, was ein Angreifer tatsächlich stehlen oder tun könnte.

• Lesen Sie ein CSRF-Token oder Sitzungsinformationen aus, auf die JS zugreifen kann
• Zeigen Sie document.domain, um den Ursprung nachzuweisen
• Zeigen Sie bei Stored XSS, dass die Payload in einem Opferkonto ausgelöst wird

Stehlen Sie niemals tatsächlich die Sitzungen realer Benutzer, sondern demonstrieren Sie nur die Möglichkeit.

SSRF im Kontext eines Bug-Bounty-Programms bedeutet, eine Funktion zu finden, die eine von Ihnen kontrollierte URL abruft. Wahrscheinliche Kandidaten sind:

• Webhook-URLs und Callback-URLs
• Bild- oder PDF-Generatoren, die entfernte Ressourcen abrufen
• Funktionen zur URL-Vorschau oder zum Auflösen von Links
• Funktionen zum Importieren aus einer URL

Verweisen Sie diese auf interne oder Metadata-Endpunkte, um die Auswirkungen nachzuweisen.

Wenn die Antwort den abgerufenen Inhalt nicht anzeigt, verwenden Sie einen Out-of-Band-Server, um zu bestätigen, dass das Ziel eine Anfrage gesendet hat. Ein Interaktions-Callback weist blindes SSRF nach.

Tools wie Burp Collaborator oder interactsh geben Ihnen eine eindeutige URL, die Zugriffe protokolliert.

Alle drei Schwachstellenklassen lassen sich finden, indem Sie Anfragen abfangen und manipulieren. Ein Intercepting Proxy ist dabei das zentrale Tool.

• Burp Suite oder OWASP ZAP, um Datenverkehr abzufangen und zu verändern
• Repeater, um einzelne Anfragen zu wiederholen und anzupassen
• Intruder/Fuzzer, um viele IDs oder Payloads zu testen

Wenn Sie Ihren Proxy gründlich beherrschen, bringt Ihnen das mehr als jede einzelne Technik.

Die höchsten Prämien entstehen durch das Kombinieren von Schwachstellen. Eine mittelschwere Schwachstelle kann zusammen mit einer weiteren kritisch werden.

• SSRF mit Zugriff auf Cloud-Metadaten führt zum Diebstahl von Zugangsdaten und zur Kontoübernahme
• IDOR, durch das Tokens offengelegt werden, führt zur vollständigen Kompromittierung eines Kontos
• Stored XSS in einem Admin-Panel führt zur Übernahme des Administratorkontos

Fragen Sie sich immer: Womit lässt sich diese Schwachstelle kombinieren?

Diese Schwachstellen betreffen echte Daten und echte Benutzer. Handeln Sie ethisch:

• Verwenden Sie Ihre eigenen Testkonten und sehen Sie über den Nachweis hinaus keine Daten realer Benutzer ein
• Vermeiden Sie Stored-XSS-Payloads, die bei realen Benutzern ausgelöst werden könnten, und beschränken Sie sie auf sich selbst
• Springen Sie bei SSRF nicht tief in interne Systeme weiter; weisen Sie die grundlegende Funktion nach und hören Sie dann auf

Ein verantwortungsvoller Nachweis der Auswirkungen hält Sie innerhalb des Safe Harbor.

Sie melden sich als Benutzer B an und wiederholen eine Anfrage mit der Sitzung von B, verwenden darin aber die Objekt-ID von Benutzer A. Daraufhin erhalten Sie die privaten Daten von A. Um welche Schwachstelle handelt es sich?

Sie haben gelernt, die drei wertvollsten Schwachstellenklassen zu suchen.

• IDOR: zwei Konten vergleichen, Objekt-IDs manipulieren und die Durchsetzung der Besitzprüfung kontrollieren
• XSS: Reflexionen prüfen, die Payload an den Kontext anpassen und die tatsächlichen Auswirkungen nachweisen
• SSRF: Funktionen zum Abrufen von URLs finden und blinde Fälle Out-of-Band bestätigen
• Schwachstellen für kritische Auswirkungen kombinieren (z. B. SSRF mit Cloud-Metadaten)
• Einen Intercepting Proxy verwenden und innerhalb des Scopes bleiben

Als Nächstes: Wie Sie aus Ihren Funden Berichte erstellen, für die Sie bezahlt werden.