Sicherheits-Bounty-Jäger
Verwenden Sie dies, wenn das Ziel die praktische Schwachstellenentdeckung für verantwortungsvolle Offenlegung oder Bounty-Einreichung ist, nicht eine breite Best-Practices-Überprüfung.
Wann zu verwenden
- Scannen eines Repositorys nach ausbeutbaren Schwachstellen
- Vorbereiten einer Huntr-, HackerOne- oder ähnlichen Bounty-Einreichung
- Triage, bei der die Frage lautet „Bringt das tatsächlich Geld?“ statt „Ist das theoretisch unsicher?“
Wie es funktioniert
Bevorzugen Sie fernreichbare, benutzergesteuerte Angriffspfade und verwerfen Sie Muster, die von Plattformen routinemäßig als informativ oder außerhalb des Scopes abgelehnt werden.
Im Scope befindliche Muster
Dies sind die Arten von Problemen, die durchgängig von Bedeutung sind:
| Muster | CWE | Typische Auswirkung |
|---|---|---|
| SSRF über benutzergesteuerte URLs | CWE-918 | interner Netzwerkzugriff, Cloud-Metadatendiebstahl |
| Authentifizierungsumgehung in Middleware oder API-Guards | CWE-287 | unbefugter Zugriff auf Konten oder Daten |
| Remote-Deserialisierung oder Upload-zu-RCE-Pfade | CWE-502 | Codeausführung |
| SQL-Injection in erreichbaren Endpunkten | CWE-89 | Datenexfiltration, Authentifizierungsumgehung, Datenzerstörung |
| Befehlsinjektion in Request-Handlern | CWE-78 | Codeausführung |
| Path Traversal in dateibedienenden Pfaden | CWE-22 | beliebiges Lesen oder Schreiben von Dateien |
| Automatisch ausgelöstes XSS | CWE-79 | Session-Diebstahl, Kompromittierung des Administrators |
Diese überspringen
Diese sind normalerweise von geringer Signalstärke oder außerhalb des Bounty-Scopes, es sei denn, das Programm sagt etwas anderes:
- Lokales
pickle.loads,torch.loadoder Äquivalent ohne entfernten Pfad eval()oderexec()in CLI-only-Toolingshell=Truebei vollständig hartcodierten Befehlen- Fehlende Sicherheitsheader allein
- Allgemeine Rate-Limiting-Beschwerden ohne Exploit-Auswirkung
- Self-XSS, bei dem das Opfer Code manuell einfügen muss
- CI/CD-Injection, die nicht Teil des Zielprogramm-Scopes ist
- Demo-, Beispiel- oder Testcode
Arbeitsablauf
- Scope zuerst prüfen: Programmrregeln, SECURITY.md, Offenlegungskanal und Ausschlüsse.
- Echte Einstiegspunkte finden: HTTP-Handler, Uploads, Hintergrundjobs, Webhooks, Parser und Integrationsendpunkte.
- Statische Tools nutzen, wo sie helfen, aber nur als Triage-Input behandeln.
- Den tatsächlichen Codepfad Ende-zu-Ende lesen.
- Nachweisen, dass Benutzerkontrolle eine relevante Senke erreicht.
- Ausbeutbarkeit und Auswirkung mit dem kleinstmöglichen sicheren PoC bestätigen.
- Vor dem Verfassen eines Berichts auf Duplikate prüfen.
Beispiel-Triage-Schleife
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Dann manuell filtern:
- Test-, Demo-, Fixture- und mitgelieferten Code entfernen
- Lokale oder nicht erreichbare Pfade entfernen
- Nur Funde mit klarem Netzwerk- oder benutzergesteuertem Pfad behalten
Berichtsstruktur
## Beschreibung
[Was die Schwachstelle ist und warum sie wichtig ist]
## Verwundbarer Code
[Dateipfad, Zeilenbereich und ein kleines Snippet]
## Proof of Concept
[Minimale Arbeitsanfrage oder Skript]
## Auswirkung
[Was der Angreifer erreichen kann]
## Betroffene Version
[Version, Commit oder getestetes Deployment-Ziel]
Qualitätskontrolle
Vor dem Einreichen:
- Der Codepfad ist von einer echten Benutzer- oder Netzwerkgrenze aus erreichbar
- Die Eingabe ist tatsächlich benutzergesteuert
- Die Senke ist bedeutsam und ausbeutbar
- Der PoC funktioniert
- Das Problem wird nicht bereits durch ein Advisory, eine CVE oder ein offenes Ticket abgedeckt
- Das Ziel ist tatsächlich im Scope des Bounty-Programms