Bösartige Pull Requests

Was ist Bösartige Pull Requests?

Eine böswillige Pull-Anfrage greift die Rezension an, nicht den Code. Die Änderung ist gering, die Beschreibung ist hilfreich und eine Änderung befindet sich in einer Datei, die in der Beschreibung nie erwähnt wird. Sie werden selbst eines einreichen: einen echten Flaky-Test-Fix sowie eine versteckte Zeile in einem Bereitstellungsskript, das jede CI-Variable an einen von Ihnen kontrollierten Server sendet. Sie überprüfen es als Betreuer und lesen jede geänderte Datei, anstatt der Zusammenfassung zu vertrauen. Anschließend gestalten Sie den Catch strukturell mit CODEOWNERS, der erforderlichen Überprüfung durch den Codeeigentümer und den Beschränkungen, welche Fork-Pull-Anfragen ausgeführt werden können.

Was Sie lernen in Bösartige Pull Requests

• Das Warnsignal eines bösartigen Pull Requests erkennen: eine Änderung an einer Datei, die mit dem angekündigten Zweck nichts zu tun hat und zwischen legitimen Diff-Hunks versteckt ist
• Verstehen, warum die Beschreibung eines Pull Requests nicht ausreicht und warum ein Reviewer den vollständigen Diff jeder geänderten Datei öffnen und lesen muss
• Themenfremde Änderungen an Deploy-, Build- oder CI-Skripten als Signal werten, das ein genaueres, skeptischeres Review verlangt
• Die Review-Richtlinie härten: CODEOWNERS für sensible Dateien, verpflichtende Freigabe durch mehr als einen Reviewer und Grenzen dafür, was Pull Requests aus Forks ausführen dürfen
• Verstehen, warum Pull Requests aus Forks außerhalb der Vertrauensgrenze des Projekts liegen und besonders genau geprüft werden müssen, bevor man ihrem Code traut

Bösartige Pull Requests — Trainingsschritte

1. Das Projekt auskundschaften

   Heute hat Bob Fennroot im Visier, ein Open-Source-Projekt für Entwickler-Tools, das Pull Requests von jedem annimmt. Er beginnt dort, wo jeder Contributor beginnen würde: im öffentlichen Repository von Harrow, dem Build-Tool des Projekts. Ein offenes Projekt ist eine offene Tür: Jeder darf es forken, ändern und einen Pull Request eröffnen. Bob ist nicht hier, um zu helfen. Er will, dass sein Code gemergt wird — und das Review eines vielbeschäftigten Maintainers ist das Einzige, was ihm im Weg steht.

2. Forken und klonen

   Bob forkt das Repository in sein eigenes Konto und klont den Fork lokal, damit er seine Änderungen vornehmen und sie als Pull Request zurückschicken kann. Sein Plan ist simpel: eine wirklich nützliche Änderung als Tarnung mitliefern und daneben eine zweite, themenfremde verstecken.

3. Die Tarnung und das Ziel

   Bobs Tarnung ist echt: Er repariert einen tatsächlich instabilen Retry-Test — genau die Art kleiner Beitrag, über die sich ein Projekt freut. Diese Änderung ist ehrlich und hilfreich, und genau darum geht es: Sie lässt den Pull Request nach Routine aussehen. Sein eigentliches Ziel ist eine ganz andere Datei. Er öffnet das Deploy-Skript, das mit keinem Test etwas zu tun hat, und liest es durch, solange es noch sauber ist.

4. Die Backdoor einbauen

   Bob fügt dem Deploy-Skript eine einzige Zeile hinzu. Sie sieht aus wie harmlose Build-Telemetrie, schickt aber jede Umgebungsvariable an einen Server, den er kontrolliert. Das Deploy-Skript läuft in der CI des Projekts, und dort gehören zu diesen Variablen Deploy-Keys und Registry-Token. Eine Zeile, in einer Datei, die der Pull Request mit keinem Wort erwähnt. Das ist der ganze Angriff.

5. Vor aller Augen vergraben

   Die Zeile liest sich wie etwas, das ein Build-Engineer hinzugefügt haben könnte, und sie steht zwischen ganz gewöhnlichen Deploy-Schritten. Nichts daran schreit nach Angriff — und genau deshalb übersteht sie einen kurzen Blick.

6. Beide Änderungen committen

   Bob nimmt beide Änderungen gemeinsam in den Staging-Bereich und committet sie zusammen: den echten Test-Fix und die Zeile im Deploy-Skript, in einem einzigen Commit. So gebündelt reitet die bösartige Änderung auf dem Rücken der ehrlichen mit.

7. Auf den Fork pushen

   Bob pusht den Branch in seinen Fork. Der Push landet in seiner eigenen Kopie des Repositorys, und die Plattform antwortet mit einem Link, über den er einen Pull Request gegen Fennroot eröffnen kann.

8. Den Pull Request eröffnen

   Bob eröffnet den Pull Request gegen Fennroots Repository. Titel und Beschreibung handeln ausschließlich vom instabilen Test; das Deploy-Skript kommt darin nicht vor. Der Test-Fix ist die Erzählung, die der Reviewer lesen soll. Die Backdoor bleibt darin komplett unerwähnt.

9. Auf den Merge drängen

   Während die Pull-Anfrage geöffnet ist, fügt Bob einen freundlichen Kommentar hinzu, der für eine schnelle Zusammenführung sorgt. Er belässt es auf der Testzeile, sodass der Blick des Prüfers dort landet und nicht auf dem Bereitstellungsskript. Ein kleiner sozialer Druck, schnell zuzustimmen, bevor jemand zu genau liest.

10. Wissenscheck

    Sie haben gerade gesehen, wie eine Backdoor hinter einem echten Fix in einen Pull Request mitreist. Prägen Sie sich ein, warum das gefährlich ist.