Umgehung des Branch-Schutzes

Was ist Umgehung des Branch-Schutzes?

Ein Standardzweig ohne Schutz akzeptiert alles, was an ihn weitergeleitet wird. Jeder mit Push-Zugriff kann sich direkt auf den Main festlegen oder einen Force-Push über den Verlauf durchführen. Überprüfungen und Statusprüfungen funktionieren nur, wenn durch sie Änderungen erzwungen werden. Sie gehen mit den Anmeldeinformationen eines gefälschten Mitwirkenden direkt zum Hauptserver, überführen dann den Verlauf und beobachten, wie CI übersprungen wird. Sie fügen Zweigschutz hinzu: Erfordern eine Pull-Anfrage, Prüfer, das Bestehen von Prüfungen und keine Force-Pushes mit der Einstellung „include-administrators“, da eine Regel, die privilegierte Konten umgehen können, keine Kontrolle darstellt.

Was Sie lernen in Umgehung des Branch-Schutzes

• Erkennen, was ein ungeschützter Default-Branch zulässt: direkte Pushes und Force Pushes, die die Historie umschreiben und Pull-Request-Review sowie CI-Status-Checks umgehen
• Nachvollziehen, wie ein einziges kompromittiertes Contributor-Konto ungeprüften Code direkt in die Produktion pushen kann, wenn Merges auf den Default-Branch automatisch ausgerollt werden
• Verstehen, warum ein Force Push auf einen gemeinsam genutzten Branch gefährlich ist: Er schreibt Historie um, die andere geprüft haben und auf der sie aufbauen, und kann Commits spurlos löschen
• Branch-Schutzregeln anwenden, die einen Pull Request, verpflichtende Reviewer und erfolgreiche Status-Checks verlangen und Force Pushes auf dem Default-Branch blockieren
• Die Option „Administratoren einbeziehen“ aktivieren, damit privilegierte Konten die Regel nicht umgehen können und die Kontrolle für alle durchsetzbar wird

Umgehung des Branch-Schutzes — Trainingsschritte

1. Ein gestohlener Contributor-Zugang

   Heute nimmt Bob Riftwell ins Visier, ein Unternehmen für Logistiksoftware. Er hat die Anmeldeinformationen eines Mitwirkenden für das Dispatch-API-Repository erbeutet und möchte, dass sein eigener Code in der Produktion ausgeführt wird, ohne dass eine einzige Person ihn zuerst überprüft. Er beginnt damit, das Repository zu öffnen, auf das das gestohlene Konto übertragen werden kann.

2. Nichts bewacht die Hauptsache

   Das Repository-Statusboard teilt Bob alles mit, was er braucht. Der Standard-Branch ist der Haupt-Branch, sein Branch-Schutz liest „Keine“ und jeder Push auf den Haupt-Branch wird direkt in der Produktion bereitgestellt. Da es keine Regeln für den Branch gibt, kann er direkt zu ihm vordringen und seine Geschichte mit Gewalt durchsetzen, und alles, was landet, wird von selbst in die Produktion überführt.

3. Klonen Sie das Repository

   Bob klont das Repository lokal mit dem gestohlenen Konto, sodass er seinen Verlauf neu schreiben und seine Änderung erstellen kann, bevor er es zurück in den Hauptbereich überträgt.

4. Zurückspulen nach dem Audit-Commit

   Der zuletzt überprüfte Commit für die Hauptversion fügte dem Authentifizierungsdienst eine Prüfprotokollierung hinzu, genau den Datensatz, der die Änderung kennzeichnen würde, die Bob vornehmen wird. Also beginnt er damit, seinen lokalen Haupt-Commit zurückzuspulen und den Audit-Logging-Commit vollständig zu löschen. Auf einem geschützten Branch wäre dies unmöglich. Hier ist es ein einzelner Befehl.

5. Mit Gewalt über die Hauptleitung schieben

   Bob schiebt seine zurückgespulte Geschichte direkt in den Hauptteil. Da der Branch keinen Schutz hat, akzeptiert ihn der Server und der überprüfte Audit-Logging-Commit wird aus dem gemeinsam genutzten Branch entfernt, als ob er nie zusammengeführt worden wäre. Alle anderen, die main ziehen, verlieren nun stillschweigend auch dieses Commit. Das ist es, was ein Force-Push auf einen gemeinsam genutzten Branch bewirkt: Es schreibt die Geschichte neu, die andere Leute bereits überprüft und darauf aufgebaut haben.

6. Öffnen Sie die Authentifizierungs-Middleware

   Jetzt fügt Bob seinen eigenen Code hinzu. Er öffnet die Authentifizierungs-Middleware, die Datei, die jede Anfrage an die Dispatch-API durchläuft, und liest sie sauber, bevor er sie berührt.

7. Bepflanzen Sie die Umgehungsstraße

   Bob fügt oben in der Middleware einen kurzen Block hinzu. Es liest sich wie ein Kompatibilitäts-Shim für ein Legacy-Relay, aber jede Anfrage, die einen festen Header-Wert trägt, wird als Administrator durchgewinkt, ohne Token und ohne Signaturprüfung. Eine Hintertür zu jeder Route, die der Dienst schützt, getarnt als harmlose Pipelines.

8. In Sichtweite begraben

   Der hinzugefügte Block befindet sich zwischen gewöhnlicher Middleware und liest sich wie etwas, das ein Backend-Ingenieur schreiben könnte. Nichts davon sieht auf den ersten Blick besorgniserregend aus, und genau aus diesem Grund würde es eine kurze Rezension überstehen, falls es jemals eine Rezension gäbe.

9. Commit auf main

   Bob übergibt die Änderung direkt an main mit einer Meldung über eine Relay-Zeitüberschreitung, nichts, was die Authentifizierung erwähnt. Es gibt keine Branch und keine Pull-Anfrage; Der Commit befindet sich bereits im Standard-Branch seines Klons.

10. Gehen Sie direkt in die Produktion über

    Bob schiebt den Commit direkt nach Main. Es gibt keinen Pull-Request zum Öffnen, keinen Prüfer zum Genehmigen und keine Statusprüfung zum Bestehen. Der Branch akzeptiert es, und da er mit der automatischen Hauptbereitstellung zusammengeführt wird, ist seine Hintertür Sekunden später in der Produktion aktiv.