Basic Gitea Information
Last updated
Last updated
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
La structure de base de l'environnement Gitea est de regrouper les dépôts par organisation(s), chacune d'elles pouvant contenir plusieurs dépôts et plusieurs équipes. Cependant, notez que tout comme sur GitHub, les utilisateurs peuvent avoir des dépôts en dehors de l'organisation.
De plus, un utilisateur peut être membre de différentes organisations. Au sein de l'organisation, l'utilisateur peut avoir différentes autorisations sur chaque dépôt.
Un utilisateur peut également être partie de différentes équipes avec différentes autorisations sur différents dépôts.
Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.
Lorsqu'une organisation est créée, une équipe appelée Propriétaires est créée et l'utilisateur y est ajouté. Cette équipe donnera un accès admin sur l'organisation, ces autorisations et le nom de l'équipe ne peuvent pas être modifiés.
Les admins d'org (propriétaires) peuvent sélectionner la visibilité de l'organisation :
Public
Limité (utilisateurs connectés uniquement)
Privé (membres uniquement)
Les admins d'org peuvent également indiquer si les admins de dépôt peuvent ajouter ou retirer l'accès pour les équipes. Ils peuvent également indiquer le nombre maximum de dépôts.
Lors de la création d'une nouvelle équipe, plusieurs paramètres importants sont sélectionnés :
Il est indiqué les dépôts de l'org auxquels les membres de l'équipe pourront accéder : dépôts spécifiques (dépôts où l'équipe est ajoutée) ou tous.
Il est également indiqué si les membres peuvent créer de nouveaux dépôts (le créateur obtiendra un accès admin à celui-ci)
Les autorisations que les membres du dépôt auront :
Accès Administrateur
Accès Spécifique :
Dans un dépôt, l'admin d'org et les admins de dépôt (si autorisés par l'org) peuvent gérer les rôles attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il y a 3 rôles possibles :
Administrateur
Écrire
Lire
Utilisation de nom d'utilisateur + mot de passe et potentiellement (et recommandé) un 2FA.
Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée associée d'effectuer des actions en votre nom. http://localhost:3000/user/settings/keys
Vous ne pouvez pas usurper l'identité de l'utilisateur avec ces clés mais si vous ne l'utilisez pas, il pourrait être possible que vous soyez découvert pour avoir envoyé des commits sans signature.
Vous pouvez générer un jeton d'accès personnel pour donner à une application accès à votre compte. Un jeton d'accès personnel donne un accès complet à votre compte : http://localhost:3000/user/settings/applications
Tout comme les jetons d'accès personnels, les applications Oauth auront un accès complet à votre compte et aux endroits auxquels votre compte a accès car, comme indiqué dans la documentation, les scopes ne sont pas encore pris en charge :
Les clés de déploiement peuvent avoir un accès en lecture seule ou en écriture au dépôt, elles peuvent donc être intéressantes pour compromettre des dépôts spécifiques.
Les protections de branche sont conçues pour ne pas donner un contrôle complet d'un dépôt aux utilisateurs. L'objectif est de mettre plusieurs méthodes de protection avant de pouvoir écrire du code dans une certaine branche.
Les protections de branche d'un dépôt peuvent être trouvées à https://localhost:3000/<orgname>/<reponame>/settings/branches
Il est impossible de définir une protection de branche au niveau de l'organisation. Donc, toutes doivent être déclarées sur chaque dépôt.
Différentes protections peuvent être appliquées à une branche (comme à master) :
Désactiver Push : Personne ne peut pousser vers cette branche
Activer Push : Quiconque ayant accès peut pousser, mais pas forcer le push.
Liste blanche de Push restreint : Seuls les utilisateurs/équipes sélectionnés peuvent pousser vers cette branche (mais pas de force push)
Activer la liste blanche de fusion : Seuls les utilisateurs/équipes sur liste blanche peuvent fusionner des PRs.
Activer les vérifications d'état : Exiger que les vérifications d'état réussissent avant de fusionner.
Exiger des approbations : Indiquer le nombre d'approbations requises avant qu'une PR puisse être fusionnée.
Restreindre les approbations aux utilisateurs sur liste blanche : Indiquer les utilisateurs/équipes qui peuvent approuver les PRs.
Bloquer la fusion sur des revues rejetées : Si des modifications sont demandées, elle ne peut pas être fusionnée (même si les autres vérifications réussissent)
Bloquer la fusion sur des demandes de révision officielles : Si des demandes de révision officielles existent, elle ne peut pas être fusionnée
Rejeter les approbations obsolètes : Lors de nouveaux commits, les anciennes approbations seront rejetées.
Exiger des commits signés : Les commits doivent être signés.
Bloquer la fusion si la demande de tirage est obsolète
Modèles de fichiers protégés/non protégés : Indiquer les modèles de fichiers à protéger/non protéger contre les modifications
Comme vous pouvez le voir, même si vous parvenez à obtenir des identifiants d'un utilisateur, les dépôts peuvent être protégés vous empêchant de pousser du code vers master par exemple pour compromettre le pipeline CI/CD.
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
