Teil 8 – Responsible Disclosure & Report Writing

Ein Fund ist nur so gut wie sein Bericht. Gute Reports machen es dem Triage-Team leicht, das Problem zu verstehen, zu reproduzieren und zu priorisieren — das erhöht die Chance auf Anerkennung und Auszahlung. In diesem Teil zeige ich dir, wie ein professioneller Report aufgebaut ist, welche Informationen unerlässlich sind, wie du Schweregrade einschätzt, welche Kommunikationsregeln gelten und wie du mit Follow-ups, Duplicate-Fällen und Verhandlungen umgehst.

Prinzipien vorab

• Klarheit schlägt Drama. Ein sauberes, strukturiertes Rapport ist besser als ein emotioneller „Look what I broke“-Stil.
• Beweise, nicht Geschichten. Reproduzierbare Schritte, Logs und Screenshots sind Gold.
• Sicherheit & Legalität. Keine Exfiltration von Daten, keine öffentliche Disclosure ohne Freigabe.
• Empathie. Triage-Teams haben enge SLAs und interne Prozesse — kommuniziere kooperativ.

Aufbau eines exzellenten Reports (Template)

1. Titel (kurz + präzise)
   Beispiel: IDOR in /api/v1/orders/{id} ermöglicht Zugriff auf fremde Bestellungen
2. Kurz-Zusammenfassung (1–2 Sätze)
   Was passiert, warum ist es problematisch, kurze Impact-Einschätzung.
3. Betroffene Ressourcen / Scope
   Genaue Ziel-URLs, App-Versionen, Endpoints, betroffene Parameter, Hostnames, IPs. (z. B. https://api.example.com/v1/orders/{id} — v2025.06 build 1234)
4. Schweregrad-Einschätzung (Begründet)
   Z.B. High — ermöglicht Zugriff auf personenbezogene Daten von Kunden; potenziell finanzielle Auswirkungen. Begründe kurz, warum (CVE-like Einschätzung hilft).
5. Schritte zur Reproduktion (Repro-Steps)
   Nummerierte, exakt ausführbare Schritte. Verwende vollständige Requests (Headers, Methode, Body) oder curl-Beispiele. Keine zerstörerischen Schritte.
6. Proof-of-Concept (PoC)
   Screenshots, Request/Response-Auszüge, Logs, Timestamps. Wenn möglich, minimaler nicht-destruktiver PoC-Request, der den Fehler belegt.
7. Technische Analyse / Root-Cause
   Kurz: Warum passiert es? (z. B. fehlende serverseitige Authorization-Check auf Objekt-Ebene)
8. Impact / Business-Context
   Welche Daten/Prozesse könnten betroffen sein? Wer ist betroffen (Nutzer, Admins)? Mögliche Folgen (Datendiebstahl, Privilegien-Escalation, finanzielle Schäden).
9. Mitigation & Fix-Vorschläge
   Konkrete, umsetzbare Empfehlungen: Beispiel: „Serverseitige ID-Prüfung: stelle sicher, dass owner_id des angefragten Objekts gleich requester_id ist; füge Unit-Tests für Authorization-Flow hinzu.“
10. Anhang / Raw Data
    Vollständige Request/Response-Payloads (Redact private Daten!), Logs, Hashes. Optional PGP-Key für vertrauliche Kommunikation.
11. Kontaktinformationen & Disclosure-Präferenzen
    Wie kann das Team dich erreichen? Bevorzugst du vertrauliche Kommunikation? Bietest du PGP an?

Beispiel: Repro-Step (konkret und knapp)

1. Login als Testuser A (usera@example.com) → erhalte Authorization: Bearer <tokenA>.
2. Erstelle Bestellung mit POST https://api.example.com/v1/orders (Body minimal) → erhältst order_id = 1234.
3. Logout, Login als Testuser B (userb@example.com) → erhalte tokenB.
4. GET https://api.example.com/v1/orders/1234 mit Header Authorization: Bearer <tokenB> → 200 OK (Payload enthält PII von user A).
5. Erwartung: 403/404 oder Ownership-Check. Tatsächliches Verhalten: fehlende serverseitige Owner-Check.

Füge Curl-Beispiel + relevanten Response-Ausschnitt (redacted).

Wie du Schweregrade einschätzt (praktisch)

Nutze drei Dimensionen: Auswirkung, Exploitability, Exposure.

• Auswirkung (Impact): Welche Daten/Assets kann der Fehler beeinflussen? (hoch = vollständiger Account- oder Datenzugriff, niedrig = nur ästhetische Fehler)
• Exploitability: Wie leicht lässt sich das Problem ausnutzen? (öffentliche Trigger, Auth-Needed, Timing, Race)
• Exposure: Wie breit ist die Angriffsfläche? (nur interne Hosts vs. öffentlich zugänglich für alle Nutzer)

Kombiniere diese Faktoren (z. B. hoher Impact + einfache Exploitability + breite Exposure → Critical/High). Begründe die Einstufung kurz im Report.

Kommunikation mit dem Triage-Team

• Eröffne freundlich: Kurz, sachlich, mit Referenz auf Programm/Scope.
• PGP & sichere Kanäle: Wenn sensibel, biete PGP an. Viele Programme unterstützen verschlüsselte Kommunikation.
• Sei erreichbar, aber nicht aufdringlich: Antworte zeitnah auf Rückfragen. Dokumentiere Antworten für den Audit-Trail.
• Status-Updates: Wenn du eine neue Erkenntnis hast (z. B. weitere betroffene Endpoints), update den bestehenden Report statt einen neuen zu eröffnen.

Umgang mit Duplicates & „No Reward“ Entscheidungen

• Duplicate-Fund: Nicht schlimm — viele Reports kommen parallel rein. Wenn dein Fund als Duplicate gewertet wird, prüfe, ob dein PoC zusätzlichen Wert bringt (z. B. bessere Repro, weitere betroffene Endpoints). Kommuniziere professionell.
• No Reward / Low Reward: Frag nach konstruktivem Feedback. Frage, was gefehlt oder wie Severity bewertet wurde. Nutze Feedback, um deine Reports besser zu machen. Reagiere sachlich, nicht emotional.

Zeitliche Erwartungen & Disclosure-Timeline

• Viele Programme haben SLA-ähnliche Zeiten (Acknowledgement innerhalb X Tagen, Fix/Resolution zeitlich variabel). In deinem ersten Report kannst du höflich um Acknowledgement bitten und angeben, ob du eine Frist für vertrauliche Disclosure präferierst (üblich: 90 Tage, kann je nach Programm variieren). Niemals öffentlich ohne Freigabe.

Verhandlung um Belohnungen (Bounties)

• Fokus zuerst auf Qualität des Reports. Gute Reports → bessere Bewertungen.
• Wenn nötig, belege Impact. Zahlen, Business-Use-Cases, klare Risiko-Beschreibung erhöhen Chance auf höhere Bewertung.
• Sei vorbereitet zu diskutieren, aber bleibe professionell. Verlange nicht automatisch Höheres; argumentiere mit Fakten.

Sicherheit & Privacy beim Reporting

• Nie echte Nutzerdaten zeigen. Wenn ein PoC echte Daten enthüllt, redigiere / maskiere sie im Report.
• Logs und Dumps nur wenn unbedingt nötig, und dann verschlüsselt übermittelt.
• PGP-Key: Stelle einen Schlüssel bereit, wenn du sensiblen Austausch erwartest.

Checkliste vor dem Submit

• ✅ Repro-Steps funktionieren reproduzierbar.
• ✅ PoC minimal, nicht-destruktiv, keine echten Daten exfiltriert.
• ✅ Ziel & Version exakt angegeben.
• ✅ Schweregrad begründet.
• ✅ Fix-Vorschläge konkret.
• ✅ Kontaktmöglichkeit & PGP (falls nötig) angegeben.
• ✅ Keine öffentliche Disclosure ohne Freigabe angekündigt.

Nach dem Fix / Aftercare

• Wenn das Unternehmen bestätigt, dass der Bug behoben ist, bitte um (falls verfügbar) CVE, Hall-of-Fame-Eintrag oder öffentliche Anerkennung — falls du das wünschst.
• Falls du an einem Fix beteiligt warst (z. B. Debugging-Hilfe), dokumentiere deine Beiträge und frage nach Anerkennung im Report.
• Lerne aus dem Feedback: Verbessere deine Report-Vorlage, passe Schweregrad-Einschätzungen an und aktualisiere deine PoC-Methoden.