Bug-Bounty-Automatisierung in Ruby

Stelle eine absichtlich verwundbare API auf deinem eigenen Rechner auf und schreibe dann deinen ersten Ruby-Client, der sich einloggt und ein Profil zurückliest. Keine Ruby-Vorkenntnisse nötig — am Ende hast du ein Ziel zum Jagen und ein Skript, das mit ihm spricht.

Eine Spezifikation sagt dir, was eine API dich sehen lassen will. Wir parsen sie zu einem Inventar und proben dann eine Wortliste, um die ausgelassenen Endpunkte zu finden — und lernen dabei Arrays, Hashes, Iteration und den Unterschied zwischen einem 404 und einem 401.

Unser Token ist für einen normalen Benutzer — was passiert also, wenn wir damit den Datensatz eines anderen anfragen? Wir bauen einen Checker, der Benutzer-IDs abläuft und jede markiert, die wir lesen können, aber nicht sollten, und finden denselben Fehler auf Endpunktebene. Nebenbei: Methoden, die Werte zurückgeben, Ranges und das Sammeln von Ergebnissen.

Teil 3 missbrauchte, was ein Token durfte. Jetzt greifen wir das Token selbst an — und den Login, der es ausgibt. Wir fälschen eine Admin-Sitzung allein aus dem Benutzernamen, holen uns dann eine mit einem Müll-Passwort und lernen, wie ein echtes Token aussehen muss.

Wir hören auf, die Felder zu senden, die die API erwartet, und fangen an, die zu senden, die sie nicht erwartet. Ein Profil-Update-Endpunkt, der alles zusammenführt, was du ihm gibst, wird zum Weg, deine eigene Rolle und deinen Kontostand zu setzen — Mass Assignment. Wir bauen einen kleinen Fuzzer, um ihn zu finden, und lernen dabei Blöcke und yield.

Ein Einmal-Coupon verhält sich perfekt, wenn du ihn zweimal hintereinander einlöst — und fällt auseinander, wenn du ihn zehnmal auf einmal einlöst. Wir feuern nebenläufige Anfragen ab, um eine Belohnung doppelt auszugeben, bevor der Server sie als benutzt markieren kann, und lernen dabei Threads und das Check-then-act-Rennen, von dem Markt-Bots leben und sterben.

Der beste Zeitpunkt, einen Bug zu finden, ist genau dann, wenn er ausgeliefert wird. Wir machen Schnappschüsse der API-Oberfläche auf die Platte und diffen jeden Lauf gegen den letzten, sodass ein neuer Endpunkt, ein neues Feld oder ein geänderter Statuscode von selbst auftaucht — das „Was hat sich geändert“-Signal, mit dem ein Bounty-Bot läuft. Dateien, Sets und Hash-Vergleich.

Das Finale. Acht Skripte, die jedes denselben Client neu bauen, werden zu einer Scanner-Klasse mit einer Kommandozeilen-Schnittstelle, einer Scope-Allowlist, die sie physisch außerstande setzt, etwas anderes als das Labor anzufassen, und einem Bericht zur koordinierten Offenlegung als Ausgabe. Klassen, OptionParser und die Ethik, die in den Code selbst gehört.