Security-Bounty-Hunter

Security Bounty Hunter

Verwenden Sie dies, wenn das Ziel die praktische Schwachstellensuche für verantwortungsvolle Offenlegung oder Bounty-Einreichung ist, nicht eine umfassende Best-Practices-Überprüfung.

Wann zu verwenden

• Scannen eines Repositorys auf ausbeutbare Schwachstellen
• Vorbereitung einer Huntr-, HackerOne- oder ähnlichen Bounty-Einreichung
• Triage, wenn die Frage lautet „Zahlt das tatsächlich?“ und nicht „Ist das theoretisch unsicher?“

Funktionsweise

Bevorzugt werden remote erreichbare, benutzergesteuerte Angriffspfade, und Muster werden verworfen, die Plattformen routinemäßig als informativ oder außerhalb des Scopes ablehnen.

Im Scope befindliche Muster

Dies sind die Arten von Problemen, die durchgängig relevant sind:

Muster	CWE	Typische Auswirkung
SSRF über benutzergesteuerte URLs	CWE-918	interner Netzwerkzugriff, Cloud-Metadatendiebstahl
Auth-Bypass in Middleware oder API-Guards	CWE-287	unbefugter Konto- oder Datenzugriff
Remote-Deserialisierung oder Upload-zu-RCE-Pfade	CWE-502	Codeausführung
SQL-Injection in erreichbaren Endpunkten	CWE-89	Datenerxtraktion, Auth-Bypass, Datenzerstörung
Command-Injection in Request-Handlern	CWE-78	Codeausführung
Path Traversal in Dateibereitstellungspfaden	CWE-22	willkürliches Lesen oder Schreiben von Dateien
Automatisch ausgelöstes XSS	CWE-79	Session-Diebstahl, Admin-Kompromittierung

Diese überspringen

Diese sind in der Regel schwache Signale oder außerhalb des Bounty-Scopes, sofern das Programm nichts anderes angibt:

• Lokale pickle.loads, torch.load oder Äquivalente ohne Remote-Pfad
• eval() oder exec() in CLI-only-Tooling
• shell=True bei vollständig hartcodierten Befehlen
• Fehlende Sicherheitsheader für sich allein genommen
• Allgemeine Rate-Limiting-Beschwerden ohne Auswirkungsnachweis
• Self-XSS, bei dem das Opfer manuell Code einfügen muss
• CI/CD-Injection, die nicht Teil des Zielprogrammscopes ist
• Demo-, Beispiel- oder Test-only-Code

Arbeitsablauf

1. Zuerst den Scope prüfen: Programmregeln, SECURITY.md, Offenlegungskanal und Ausschlüsse.
2. Echte Einstiegspunkte finden: HTTP-Handler, Uploads, Hintergrundjobs, Webhooks, Parser und Integrationsendpunkte.
3. Statische Tools einsetzen, wo hilfreich, aber nur als Triage-Eingabe behandeln.
4. Den tatsächlichen Codepfad von Anfang bis Ende lesen.
5. Nachweisen, dass die Benutzerkontrolle eine bedeutungsvolle Senke erreicht.
6. Ausbeutbarkeit und Auswirkung mit dem kleinstmöglichen sicheren PoC bestätigen.
7. Vor der Erstellung eines Reports auf Duplikate prüfen.

Beispiel-Triage-Schleife

semgrep --config=auto --severity=ERROR --severity=WARNING --json

Dann manuell filtern:

• Tests, Demos, Fixtures, vendored Code entfernen
• Lokal-only oder nicht erreichbare Pfade entfernen
• Nur Funde mit klarem Netzwerk- oder benutzergesteuerten Pfad behalten

Report-Struktur

## Beschreibung
[Was die Schwachstelle ist und warum sie wichtig ist]

## Verwundbarer Code
[Dateipfad, Zeilenbereich und ein kleiner Ausschnitt]

## Proof-of-Concept
[Minimale funktionierende Anfrage oder Skript]

## Auswirkung
[Was der Angreifer erreichen kann]

## Betroffene Version
[Version, Commit oder bereitgestelltes Ziel, das getestet wurde]

Qualitätskontrolle

Vor der Einreichung:

• Der Codepfad ist von einer echten Benutzer- oder Netzwerkgrenze aus erreichbar
• Die Eingabe ist tatsächlich benutzergesteuert
• Die Senke ist bedeutungsvoll und ausbeutbar
• Der PoC funktioniert
• Das Problem wird nicht bereits durch einen Advisory, CVE oder offenen Ticket abgedeckt
• Das Ziel ist tatsächlich im Scope des Bounty-Programms