Last updated
Gitea is 'n self-gehoste gemeenskap-bestuurde ligte kode hospitaal-oplossing geskryf in Go.
Om 'n Gitea-instantie plaaslik te hardloop, kan jy net 'n docker-houer hardloop:
Koppel aan poort 3000 om die webblad te besoek.
Jy kan dit ook hardloop met kubernetes:
Openbare repositors: http://localhost:3000/explore/repos
Geregistreerde gebruikers: http://localhost:3000/explore/users
Geregistreerde Organisasies: http://localhost:3000/explore/organizations
Merk op dat standaard Gitea nuwe gebruikers toelaat om te registreer. Dit sal nie spesiaal interessante toegang gee aan die nuwe gebruikers oor ander organisasies/gebruikers se repositors nie, maar 'n ingeteken gebruiker mag dalk in staat wees om meer repositors of organisasies te visualiseer.
Vir hierdie scenario gaan ons aanneem dat jy toegang tot 'n github-rekening verkry het.
As jy op een of ander manier al legitimasie vir 'n gebruiker binne 'n organisasie het (of jy het 'n sessiekoekie gesteel) kan jy net in teken en kyk watter regte jy het oor watter repositors, in watter spanne jy is, ander gebruikers lys, en hoe die repositors beskerm is.
Merk op dat 2FA gebruik kan word sodat jy hierdie inligting slegs kan benader as jy ook daardie toets kan slaag.
Merk op dat as jy die i_like_gitea koekie slaag om te steel (tans gekonfigureer met SameSite: Lax) kan jy die gebruiker heeltemal naboots sonder om legitimasie of 2FA nodig te hê.
Gitea laat gebruikers toe om SSH-sleutels in te stel wat as verifikasiemetode gebruik sal word om kode te implementeer namens hulle (geen 2FA word toegepas).
Met hierdie sleutel kan jy veranderinge aanbring in repositors waar die gebruiker sekere regte het, maar jy kan dit nie gebruik om toegang tot die gitea-api te kry om die omgewing op te som nie. Jy kan egter plaaslike instellings opnoem om inligting te kry oor die repositors en gebruiker waarop jy toegang het:
Indien die gebruiker sy gebruikersnaam ingestel het as sy gitea gebruikersnaam, kan jy die openbare sleutels wat hy ingestel het in sy rekening by https://github.com/<gitea_gebruikersnaam>.keys toegang, jy kan dit nagaan om te bevestig dat die privaatsleutel wat jy gevind het, gebruik kan word.
SSH-sleutels kan ook in repositories ingestel word as implementeringsleutels. Iemand met toegang tot hierdie sleutel sal in staat wees om projekte vanaf 'n repository te begin. Gewoonlik sal in 'n bediener met verskillende implementeringsleutels die plaaslike lêer ~/.ssh/config jou inligting gee oor watter sleutel verband hou.
Soos verduidelik hier is dit soms nodig om die commits te onderteken of jy mag ontdek word.
Kyk plaaslik of die huidige gebruiker enige sleutel het met:
Vir 'n inleiding oor Gebruikerstokens, sien die basiese inligting.
'n Gebruikerstoken kan gebruik word in plaas van 'n wagwoord om teen die Gitea-bediener te verifieer via API. Dit sal volledige toegang oor die gebruiker hê.
Vir 'n inleiding oor Gitea Oauth-toepassings, sien die basiese inligting.
'n Aanvaller kan 'n boosaardige Oauth-toepassing skep om toegang te verkry tot bevoorregte data/aksies van die gebruikers wat hulle waarskynlik aanvaar as deel van 'n hengelveldtog.
Soos verduidelik in die basiese inligting, sal die toepassing volledige toegang oor die gebruikersrekening hê.
In Github het ons github-aksies wat standaard 'n token met skryftoegang oor die repo kry wat gebruik kan word om takbeskerming te omseil. In hierdie geval bestaan dit nie nie, so die omseilings is meer beperk. Maar laat ons kyk wat gedoen kan word:
Skryftoegang aktiveer: As enigiemand met skryftoegang na die tak kan skryf, skryf net daarna.
Witlys Beperkte Pus: Op dieselfde manier, as jy deel is van hierdie lys, skryf na die tak.
Voeg witlys vir samenvoeging toe: As daar 'n samenvoegwitlys is, moet jy binne-in wees
Vereis goedkeurings is groter as 0: Dan... moet jy 'n ander gebruiker kompromitteer
Beperk goedkeurings tot witgelysde: As slegs witgelysde gebruikers kan goedkeur... moet jy 'n ander gebruiker kompromitteer wat binne daardie lys is
Verwerp ou goedkeurings: As goedkeurings nie met nuwe toewysings verwyder word nie, kan jy 'n reeds goedgekeurde PR kaap om jou kode in te spuit en die PR saam te voeg.
Merk op dat as jy 'n org/repo-admin is, kan jy die beskerming omseil.
Webhooks is in staat om spesifieke gitea-inligting na sekere plekke te stuur. Jy mag dalk in staat wees om daardie kommunikasie te uitbuit. Gewoonlik word 'n geheim wat jy nie kan terugkry in die webhook ingestel wat sal voorkom dat eksterne gebruikers wat die URL van die webhook ken, maar nie die geheim nie, die webhook kan uitbuit. Maar in sommige gevalle, stel mense in plaas van die geheim op sy plek, dit in die URL as 'n parameter in, sodat deur die URLs te kontroleer jy geheime en ander plekke wat jy verder kan uitbuit, kan vind.
Webhooks kan op repo- en op org-vlak ingestel word.
As jy op een of ander manier binne die bediener waarop Gitea hardloop, kon kom, moet jy soek na die Gitea-konfigurasie-lêer. Standaard is dit geleë in /data/gitea/conf/app.ini
In hierdie lêer kan jy sleutels en wagwoorde vind.
In die Gitea-pad (standaard: /data/gitea) kan jy ook interessante inligting vind soos:
Die sqlite DB: As Gitea nie 'n eksterne db gebruik nie, sal dit 'n sqlite-db gebruik
Die sessies binne die sessies-vouer: Deur cat sessions/*/*/* te hardloop, kan jy die gebruikersname van die aangemelde gebruikers sien (Gitea kan ook die sessies binne die DB stoor).
Die jwt privaatsleutel binne die jwt-vouer
Meer sensitiewe inligting kan in hierdie vouer gevind word
As jy binne die bediener is, kan jy ook die gitea-binêre lêer gebruik om toegang/inligting te wysig:
gitea dump sal Gitea dump en 'n .zip-lêer genereer
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET sal 'n token van die aangeduide tipe (volharding) genereer
gitea admin user change-password --username admin --password newpassword Verander die wagwoord
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Skep 'n nuwe admin-gebruiker en kry 'n toegangstoken
