Basiese Gitea Inligting

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Struktuur

Die basiese Gitea omgewingstruktuur is om repos te groepeer volgens organisasie(s), elk van hulle kan verskeie repositories en verskeie spanne bevat. Let egter daarop dat, net soos in github, gebruikers repos buite die organisasie kan hê.

Boonop kan ’n gebruiker ’n lid van verskillende organisasies wees. Binne die organisasie kan die gebruiker verskillende toestemmings oor elke repository hê.

’n Gebruiker kan ook deel wees van verskillende spanne met verskillende toestemmings oor verskillende repos.

En uiteindelik kan repositories spesiale beskermingsmeganismes hê.

Toestemmings

Organisasies

Wanneer ’n organisasie geskep word word ’n span genaamd Eienaars geskep en die gebruiker word daarin geplaas. Hierdie span sal admin toegang oor die organisasie gee, daardie toestemmings en die naam van die span kan nie gewysig word nie.

Org admins (eienaars) kan die sigbaarheid van die organisasie kies:

  • Publiek
  • Beperk (slegs ingelogde gebruikers)
  • Privaat (slegs lede)

Org admins kan ook aandui of die repo admins toegang kan voeg of verwyder vir spanne. Hulle kan ook die maksimum aantal repos aandui.

Wanneer ’n nuwe span geskep word, word verskeie belangrike instellings gekies:

  • Dit word aangedui watter repos van die org die lede van die span toegang sal hê: spesifieke repos (repos waar die span bygevoeg is) of almal.
  • Dit word ook aangedui of lede nuwe repos kan skep (die skepper sal admin toegang tot dit kry)
  • Die toestemmings wat die lede van die repo sal hê:
  • Administrateur toegang
  • Spesifieke toegang:

Spanne & Gebruikers

In ’n repo kan die org admin en die repo admins (indien toegelaat deur die org) die rolle wat aan samewerkers (ander gebruikers) en spanne gegee word, bestuur. Daar is 3 moontlike rolle:

  • Administrateur
  • Skryf
  • Lees

Gitea Verifikasie

Webtoegang

Gebruik gebruikersnaam + wagwoord en moontlik (en aanbeveel) ’n 2FA.

SSH Sleutels

Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante private sleutel toelaat om aksies namens jou uit te voer. http://localhost:3000/user/settings/keys

GPG Sleutels

Jy kan nie die gebruiker met hierdie sleutels naboots nie maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy ontdek word vir die stuur van verbintenisse sonder ’n handtekening.

Persoonlike Toegangstokens

Jy kan ’n persoonlike toegangstoken genereer om ’n toepassing toegang tot jou rekening te gee. ’n Persoonlike toegangstoken gee volle toegang oor jou rekening: http://localhost:3000/user/settings/applications

Oauth Toepassings

Net soos persoonlike toegangstokens Oauth toepassings sal volledige toegang oor jou rekening en die plekke waar jou rekening toegang het hê, omdat, soos in die docs aangedui, scopes nog nie ondersteun word nie:

Ontplooi sleutels

Ontplooi sleutels kan lees-slegs of skryf toegang tot die repo hê, so hulle kan interessant wees om spesifieke repos te kompromitteer.

Takbeskermings

Takbeskermings is ontwerp om nie volledige beheer van ’n repository aan die gebruikers te gee nie. Die doel is om verskeie beskermingsmetodes te plaas voordat jy in staat is om kode binne ’n tak te skryf.

Die takbeskermings van ’n repository kan gevind word in https://localhost:3000/<orgname>/<reponame>/settings/branches

Note

Dit is nie moontlik om ’n takbeskerming op organisasievlak in te stel nie. So al hulle moet op elke repo verklaar word.

Verskillende beskermings kan op ’n tak toegepas word (soos op master):

  • Deaktiveer Push: Niemand kan na hierdie tak push nie
  • Aktiveer Push: Enigeen met toegang kan push, maar nie force push nie.
  • Whitelist Beperkte Push: Slegs geselekteerde gebruikers/spanne kan na hierdie tak push (maar geen force push nie)
  • Aktiveer Merge Whitelist: Slegs whitelisted gebruikers/spanne kan PRs saamvoeg.
  • Aktiveer Status kontroles: Vereis dat status kontroles slaag voordat saamgevoeg word.
  • Vereis goedkeuringe: Dui die aantal goedkeuringe aan wat vereis word voordat ’n PR saamgevoeg kan word.
  • Beperk goedkeuringe tot whitelisted: Dui gebruikers/spanne aan wat PRs kan goedkeur.
  • Blokkeer saamvoeg op verwerkte hersienings: As veranderinge aangevra word, kan dit nie saamgevoeg word nie (selfs as die ander kontroles slaag)
  • Blokkeer saamvoeg op amptelike hersieningsversoeke: As daar amptelike hersieningsversoeke is, kan dit nie saamgevoeg word nie
  • Verwerp verouderde goedkeuringe: Wanneer nuwe verbintenisse gemaak word, sal ou goedkeuringe verwerp word.
  • Vereis Onderteken Verbintenisse: Verbintenisse moet onderteken wees.
  • Blokkeer saamvoeg as die trekversoek verouderd is
  • Beskermde/Onbeskermde lêerpatrone: Dui patrone van lêers aan om teen veranderinge te beskerm/onbeskerm.

Note

Soos jy kan sien, selfs al het jy daarin geslaag om ’n paar akrediteerbare inligting van ’n gebruiker te verkry, kan repos beskerm wees wat jou verhinder om kode na master te push byvoorbeeld om die CI/CD-pyplyn te kompromitteer.

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks