Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die grundlegende Gitea-Umgebungsstruktur besteht darin, Repos nach Organisation(en) zu gruppieren, von denen jede mehrere Repositories und mehrere Teams enthalten kann. Beachten Sie jedoch, dass Benutzer wie bei GitHub Repos außerhalb der Organisation haben können.
Darüber hinaus kann ein Benutzer ein Mitglied von verschiedenen Organisationen sein. Innerhalb der Organisation kann der Benutzer verschiedene Berechtigungen für jedes Repository haben.
Ein Benutzer kann auch Teil verschiedener Teams mit unterschiedlichen Berechtigungen für verschiedene Repos sein.
Und schließlich können Repositories spezielle Schutzmechanismen haben.
Wenn eine Organisation erstellt wird, wird ein Team namens Owners erstellt und der Benutzer wird darin platziert. Dieses Team gewährt Admin-Zugriff auf die Organisation, diese Berechtigungen und der Name des Teams können nicht geändert werden.
Org-Admins (Eigentümer) können die Sichtbarkeit der Organisation auswählen:
Öffentlich
Eingeschränkt (nur angemeldete Benutzer)
Privat (nur Mitglieder)
Org-Admins können auch angeben, ob die Repo-Admins Zugriff für Teams hinzufügen oder entfernen können. Sie können auch die maximale Anzahl von Repos angeben.
Bei der Erstellung eines neuen Teams werden mehrere wichtige Einstellungen ausgewählt:
Es wird angegeben, auf welche Repos der Org die Mitglieder des Teams zugreifen können: spezifische Repos (Repos, in die das Team hinzugefügt wird) oder alle.
Es wird auch angegeben, ob Mitglieder neue Repos erstellen können (der Ersteller erhält Admin-Zugriff darauf).
Die Berechtigungen, die die Mitglieder des Repos haben:
Administrator-Zugriff
Spezifischer Zugriff:
In einem Repo können der Org-Admin und die Repo-Admins (sofern von der Org erlaubt) die Rollen verwalten, die den Mitarbeitern (anderen Benutzern) und Teams zugewiesen werden. Es gibt 3 mögliche Rollen:
Administrator
Schreiben
Lesen
Verwendung von Benutzername + Passwort und möglicherweise (und empfohlen) einer 2FA.
Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen privaten Schlüssel ermöglichen, in Ihrem Namen Aktionen auszuführen. http://localhost:3000/user/settings/keys
Sie können den Benutzer mit diesen Schlüsseln nicht impersonifizieren, aber wenn Sie ihn nicht verwenden, könnte es möglich sein, dass Sie entdeckt werden, weil Sie Commits ohne Signatur senden.
Sie können persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu gewähren. Ein persönliches Zugriffstoken gewährt vollständigen Zugriff auf Ihr Konto: http://localhost:3000/user/settings/applications
Genau wie persönliche Zugriffstoken haben Oauth-Anwendungen vollständigen Zugriff auf Ihr Konto und die Orte, auf die Ihr Konto Zugriff hat, da, wie in den Dokumenten angegeben, Scopes noch nicht unterstützt werden:
Bereitstellungsschlüssel können Lese- oder Schreibzugriff auf das Repo haben, sodass sie interessant sein könnten, um spezifische Repos zu kompromittieren.
Branch-Schutzmaßnahmen sind so konzipiert, dass sie nicht die vollständige Kontrolle über ein Repository an die Benutzer geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor man in der Lage ist, Code in einen bestimmten Branch zu schreiben.
Die Branch-Schutzmaßnahmen eines Repositories finden Sie unter https://localhost:3000/<orgname>/<reponame>/settings/branches
Es ist nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen. Daher müssen alle in jedem Repo deklariert werden.
Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:
Push deaktivieren: Niemand kann in diesen Branch pushen.
Push aktivieren: Jeder mit Zugriff kann pushen, aber nicht force pushen.
Whitelist eingeschränkter Push: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein force push).
Whitelist für Merge aktivieren: Nur auf die Whitelist gesetzte Benutzer/Teams können PRs mergen.
Statusprüfungen aktivieren: Erfordert, dass Statusprüfungen bestehen, bevor gemerged wird.
Genehmigungen erforderlich: Geben Sie die Anzahl der erforderlichen Genehmigungen an, bevor ein PR gemerged werden kann.
Genehmigungen auf Whitelist beschränken: Geben Sie Benutzer/Teams an, die PRs genehmigen können.
Merge bei abgelehnten Überprüfungen blockieren: Wenn Änderungen angefordert werden, kann es nicht gemerged werden (auch wenn die anderen Prüfungen bestehen).
Merge bei offiziellen Überprüfungsanfragen blockieren: Wenn es offizielle Überprüfungsanfragen gibt, kann es nicht gemerged werden.
Veraltete Genehmigungen zurückweisen: Bei neuen Commits werden alte Genehmigungen zurückgewiesen.
Signierte Commits erforderlich: Commits müssen signiert sein.
Merge blockieren, wenn der Pull-Request veraltet ist.
Geschützte/ungeschützte Dateimuster: Geben Sie Muster von Dateien an, die gegen Änderungen geschützt/ungeschützt werden sollen.
Wie Sie sehen können, selbst wenn Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, könnten Repos geschützt sein, was es Ihnen beispielsweise erschwert, Code in master zu pushen, um die CI/CD-Pipeline zu kompromittieren.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
