Basic Gitea Information
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
La struttura di base dell'ambiente Gitea è quella di raggruppare i repo per organizzazione(i), ognuna delle quali può contenere diversi repository e diversi team. Tuttavia, nota che proprio come in github, gli utenti possono avere repo al di fuori dell'organizzazione.
Inoltre, un utente può essere un membro di diverse organizzazioni. All'interno dell'organizzazione, l'utente può avere diversi permessi su ciascun repository.
Un utente può anche essere parte di diversi team con permessi diversi su diversi repo.
E infine, i repository possono avere meccanismi di protezione speciali.
Quando un'organizzazione viene creata, viene creato un team chiamato Owners e l'utente viene inserito al suo interno. Questo team darà accesso admin sull'organizzazione, tali permessi e il nome del team non possono essere modificati.
Org admins (proprietari) possono selezionare la visibilità dell'organizzazione:
Pubblica
Limitata (solo utenti con accesso)
Privata (solo membri)
Org admins possono anche indicare se gli admin dei repo possono aggiungere o rimuovere accesso per i team. Possono anche indicare il numero massimo di repo.
Quando si crea un nuovo team, vengono selezionate diverse impostazioni importanti:
Viene indicato ai repo dell'org a cui i membri del team potranno accedere: repo specifici (repo a cui il team è aggiunto) o tutti.
Viene anche indicato se i membri possono creare nuovi repo (il creatore otterrà accesso admin a esso)
I permessi che i membri del repo avranno:
Accesso Amministratore
Accesso Specifico:
In un repo, l'org admin e gli admin dei repo (se consentito dall'org) possono gestire i ruoli assegnati ai collaboratori (altri utenti) e ai team. Ci sono 3 possibili ruoli:
Amministratore
Scrittura
Lettura
Utilizzando nome utente + password e potenzialmente (e raccomandato) un 2FA.
Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa chiave privata di eseguire azioni per tuo conto. http://localhost:3000/user/settings/keys
Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che tu venga scoperto per aver inviato commit senza una firma.
Puoi generare un token di accesso personale per dare a un'applicazione accesso al tuo account. Un token di accesso personale fornisce accesso completo al tuo account: http://localhost:3000/user/settings/applications
Proprio come i token di accesso personali, le applicazioni Oauth avranno accesso completo al tuo account e ai luoghi a cui il tuo account ha accesso perché, come indicato nella documentazione, gli scope non sono ancora supportati:
Le chiavi di distribuzione possono avere accesso in sola lettura o scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici.
Le protezioni dei branch sono progettate per non dare il controllo completo di un repository agli utenti. L'obiettivo è mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un certo branch.
Le protezioni dei branch di un repository possono essere trovate in https://localhost:3000/<orgname>/<reponame>/settings/branches
Non è possibile impostare una protezione del branch a livello di organizzazione. Quindi tutte devono essere dichiarate su ciascun repo.
Diverse protezioni possono essere applicate a un branch (come a master):
Disabilita Push: Nessuno può pushare su questo branch
Abilita Push: Chiunque abbia accesso può pushare, ma non forzare il push.
Whitelist Restricted Push: Solo utenti/team selezionati possono pushare su questo branch (ma non forzare il push)
Abilita Merge Whitelist: Solo utenti/team in whitelist possono unire PR.
Abilita controlli di stato: Richiedere che i controlli di stato passino prima di unire.
Richiedere approvazioni: Indica il numero di approvazioni richieste prima che un PR possa essere unito.
Restrict approvals to whitelisted: Indica utenti/team che possono approvare PR.
Blocca merge su revisioni rifiutate: Se vengono richiesti cambiamenti, non può essere unito (anche se gli altri controlli passano)
Blocca merge su richieste di revisione ufficiali: Se ci sono richieste di revisione ufficiali non può essere unito
Annulla approvazioni obsolete: Quando ci sono nuovi commit, le approvazioni vecchie saranno annullate.
Richiedere Commit Firmati: I commit devono essere firmati.
Blocca merge se la pull request è obsoleta
Modelli di file protetti/non protetti: Indica modelli di file da proteggere/non proteggere contro le modifiche
Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, i repo potrebbero essere protetti impedendoti di pushare codice su master per esempio per compromettere il pipeline CI/CD.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
