Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Podstawowa struktura środowiska Gitea polega na grupowaniu repozytoriów według organizacji, z których każda może zawierać kilka repozytoriów i kilka zespołów. Należy jednak zauważyć, że podobnie jak w githubie, użytkownicy mogą mieć repozytoria poza organizacją.
Ponadto, użytkownik może być członkiem różnych organizacji. W ramach organizacji użytkownik może mieć różne uprawnienia do każdego repozytorium.
Użytkownik może być również częścią różnych zespołów z różnymi uprawnieniami do różnych repozytoriów.
I w końcu repozytoria mogą mieć specjalne mechanizmy ochrony.
Gdy organizacja jest tworzona, tworzony jest zespół o nazwie Właściciele i użytkownik jest do niego dodawany. Ten zespół zapewni dostęp administracyjny do organizacji, te uprawnienia oraz nazwa zespołu nie mogą być modyfikowane.
Administratorzy organizacji (właściciele) mogą wybrać widoczność organizacji:
Publiczna
Ograniczona (tylko zalogowani użytkownicy)
Prywatna (tylko członkowie)
Administratorzy organizacji mogą również wskazać, czy administratorzy repozytoriów mogą dodawać lub usuwać dostęp dla zespołów. Mogą również wskazać maksymalną liczbę repozytoriów.
Podczas tworzenia nowego zespołu wybierane są kilka ważnych ustawień:
Wskazuje się repozytoria organizacji, do których członkowie zespołu będą mieli dostęp: konkretne repozytoria (repozytoria, do których zespół jest dodany) lub wszystkie.
Wskazuje się również czy członkowie mogą tworzyć nowe repozytoria (twórca uzyska do nich dostęp administracyjny)
Uprawnienia, które członkowie repozytoriów będą mieć:
Dostęp administratora
Specyficzny dostęp:
W repozytorium, administrator organizacji oraz administratorzy repozytoriów (jeśli zezwala na to organizacja) mogą zarządzać rolami przyznawanymi współpracownikom (innym użytkownikom) i zespołom. Istnieją 3 możliwe role:
Administrator
Zapis
Odczyt
Używając nazwa użytkownika + hasło i potencjalnie (i zalecane) 2FA.
Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalając powiązanemu kluczowi prywatnemu na wykonywanie działań w twoim imieniu. http://localhost:3000/user/settings/keys
Nie możesz podszywać się pod użytkownika za pomocą tych kluczy, ale jeśli ich nie używasz, może być możliwe, że zostaniesz odkryty za wysyłanie commitów bez podpisu.
Możesz wygenerować osobisty token dostępu, aby dać aplikacji dostęp do swojego konta. Osobisty token dostępu daje pełny dostęp do twojego konta: http://localhost:3000/user/settings/applications
Podobnie jak osobiste tokeny dostępu, aplikacje Oauth będą miały pełny dostęp do twojego konta i miejsc, do których twoje konto ma dostęp, ponieważ, jak wskazano w dokumentacji, zakresy nie są jeszcze obsługiwane:
Klucze wdrożeniowe mogą mieć dostęp tylko do odczytu lub zapisu do repozytorium, więc mogą być interesujące do kompromitacji konkretnych repozytoriów.
Ochrona gałęzi ma na celu nieprzekazywanie pełnej kontroli nad repozytorium użytkownikom. Celem jest wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi.
Ochrona gałęzi repozytorium można znaleźć pod https://localhost:3000/<orgname>/<reponame>/settings/branches
Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji. Wszystkie muszą być zadeklarowane w każdym repozytorium.
Różne ochrony mogą być stosowane do gałęzi (jak do master):
Wyłącz Push: Nikt nie może przesyłać do tej gałęzi
Włącz Push: Każdy z dostępem może przesyłać, ale nie może wymusić przesyłania.
Biała lista ograniczonego Push: Tylko wybrani użytkownicy/zespoły mogą przesyłać do tej gałęzi (ale nie mogą wymusić przesyłania)
Włącz białą listę scalania: Tylko użytkownicy/zespoły z białej listy mogą scalać PR-y.
Włącz kontrole statusu: Wymagaj, aby kontrole statusu przeszły przed scaleniem.
Wymagaj zatwierdzeń: Wskaź liczbę zatwierdzeń wymaganych przed scaleniem PR.
Ogranicz zatwierdzenia do białej listy: Wskaź użytkowników/zespoły, które mogą zatwierdzać PR-y.
Zablokuj scalanie przy odrzuconych recenzjach: Jeśli zmiany są wymagane, nie może być scalone (nawet jeśli inne kontrole przejdą)
Zablokuj scalanie przy oficjalnych prośbach o recenzję: Jeśli są oficjalne prośby o recenzję, nie może być scalone
Odrzuć przestarzałe zatwierdzenia: Gdy pojawią się nowe commity, stare zatwierdzenia zostaną odrzucone.
Wymagaj podpisanych commitów: Commity muszą być podpisane.
Zablokuj scalanie, jeśli pull request jest przestarzały
Wzory plików chronionych/niechronionych: Wskaź wzory plików do ochrony/od ochrony przed zmianami
Jak widać, nawet jeśli udało ci się uzyskać jakieś dane uwierzytelniające użytkownika, repozytoria mogą być chronione, co uniemożliwia ci przesyłanie kodu do master, na przykład w celu kompromitacji pipeline CI/CD.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
