Umgehung des Branch-Schutzes

Was ist Umgehung des Branch-Schutzes?

Ein ungeschützter Standard-Branch akzeptiert alle Pushes von Konten mit Schreibrechten. Diese können direkt auf main committen oder dessen Historie per Force-Push überschreiben. Review und Status-Checks wirken nur, wenn Regeln Änderungen verbindlich durch sie führen. Sie pushen mit erbeuteten Contributor-Zugangsdaten direkt auf main, überschreiben die Historie und sehen, wie CI-Prüfungen umgangen werden. Danach aktivieren Sie Branch-Schutz: Pull Requests, Reviews und erfolgreiche Checks werden Pflicht, Force-Pushes gesperrt und Administratoren einbezogen. Schutzregeln, die privilegierte Konten umgehen können, sind keine verlässliche Kontrolle.

Was Sie lernen in Umgehung des Branch-Schutzes

• Erkennen Sie, dass ein ungeschützter Standard-Branch direkte Pushes und Force-Pushes zulässt, die die Historie umschreiben und Pull-Request-Reviews sowie CI-Status-Checks umgehen
• Verfolgen Sie, wie ein kompromittiertes Contributor-Konto ungeprüften Code direkt in Produktion bringen kann, wenn Änderungen am Standard-Branch automatisch bereitgestellt werden
• Erklären Sie, warum Force-Pushes auf einen gemeinsam genutzten Branch gefährlich sind: Sie können geprüfte Historie umschreiben und Commits für alle, die den Branch pullen, aus dem Branch entfernen
• Richten Sie Branch-Schutzregeln ein, die Pull Requests, Reviews und erfolgreiche Status-Checks verlangen und Force-Pushes auf dem Standard-Branch blockieren
• Aktivieren Sie die Option „Administratoren einbeziehen“, damit privilegierte Konten die Branch-Schutzregeln nicht umgehen können

Umgehung des Branch-Schutzes — Trainingsschritte

1. Ein kompromittierter Contributor-Zugang

   Bob nimmt Riftwell ins Visier. Er hat Zugangsdaten für ein Contributor-Konto des Repositorys dispatch-api erbeutet und will eigenen Code ohne vorheriges Review in Produktion ausführen lassen. Zuerst öffnet er das Repository, auf das das kompromittierte Konto pushen darf.

2. main ohne Branch-Schutz

   Die Statusübersicht des Repositorys verrät Bob alles Wichtige: main ist der Standard-Branch, es gelten keine Branch-Schutzregeln, und jeder Push auf main wird automatisch in Produktion bereitgestellt. Ohne Schutzregeln kann Bob direkt auf main pushen und dessen Historie per Force-Push umschreiben. Jede angenommene Änderung gelangt dadurch in Produktion.

3. Repository klonen

   Bob klont das Repository mit dem kompromittierten Konto. Lokal kann er die Historie umschreiben und seinen Code vorbereiten, bevor er alles auf main pusht.

4. Den Audit-Logging-Commit zurücksetzen

   Der letzte überprüfte Commit auf main führte Audit-Logging im Authentifizierungsdienst ein. Diese Protokollierung könnte Bobs nächste Änderung auffällig machen. Deshalb setzt er sein lokales main um einen Commit zurück und entfernt den Audit-Logging-Commit aus seinem Branch. Auf einem geschützten gemeinsamen Branch könnte er diese Änderung nicht per Force-Push durchsetzen. Hier genügt ein Befehl.

5. main per Force-Push überschreiben

   Bob pusht die zurückgesetzte Historie per Force-Push auf main. Da der Branch ungeschützt ist, akzeptiert der Server die Änderung. Der überprüfte Audit-Logging-Commit ist nicht mehr Teil der gemeinsamen Branch-Historie – als wäre er nie gemergt worden. Wer main danach aktualisiert, übernimmt die geänderte Historie. Genau das macht Force-Pushes auf gemeinsam genutzte Branches gefährlich: Sie ersetzen einen Verlauf, den andere bereits geprüft und als Grundlage genutzt haben.

6. Die Authentifizierungs-Middleware öffnen

   Nun fügt Bob eigenen Code hinzu. Er öffnet die Authentifizierungs-Middleware, durch die jede Anfrage an die Dispatch-API läuft, und prüft den bisherigen Inhalt.

7. Eine Hintertür einbauen

   Bob fügt nahe dem Anfang der Middleware einen kurzen Codeblock ein. Er sieht wie eine Kompatibilitätsanpassung für einen älteren Relay-Dienst aus. Tatsächlich wird jede Anfrage mit einem bestimmten Header-Wert ohne Token- oder Signaturprüfung als Administrator zugelassen. So entsteht eine Hintertür zu allen von der Middleware geschützten API-Routen, getarnt als harmlose Anpassung.

8. Offen sichtbar und doch leicht zu übersehen

   Der neue Block steht zwischen gewöhnlichem Middleware-Code und wirkt auf den ersten Blick wie eine normale Backend-Anpassung. Ein oberflächliches Review könnte ihn übersehen – falls es überhaupt eines gäbe.

9. Die Änderung auf main committen

   Bob erstellt den Commit direkt auf seinem lokalen main. Seine Commit-Nachricht erwähnt nur einen Relay-Timeout, nicht die Änderung an der Authentifizierung. Er hat weder einen neuen Branch noch einen Pull Request erstellt.

10. Direkt in die Produktion pushen

    Bob pusht den Commit direkt auf main. Es gibt keinen Pull Request, kein Review und keinen verpflichtenden Status-Check. Der Branch nimmt den Commit an. Weil Änderungen auf main automatisch bereitgestellt werden, ist die Hintertür Sekunden später in Produktion aktiv.