Основна інформація про Gitea

Reading time: 5 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

Основна структура

Основна структура середовища Gitea полягає в групуванні репозиторіїв за організаціями, кожна з яких може містити кілька репозиторіїв та кілька команд. Однак, зверніть увагу, що, як і в GitHub, користувачі можуть мати репозиторії поза організацією.

Більше того, користувач може бути членом різних організацій. У межах організації користувач може мати різні дозволи на кожен репозиторій.

Користувач також може бути частиною різних команд з різними дозволами на різні репозиторії.

І нарешті, репозиторії можуть мати спеціальні механізми захисту.

Дозволи

Організації

Коли організація створюється, команда під назвою Власники є створеною, і користувач потрапляє до неї. Ця команда надасть адміністративний доступ до організації, ці дозволи та назва команди не можуть бути змінені.

Адміністратори організації (власники) можуть вибрати видимість організації:

  • Публічна
  • Обмежена (тільки для авторизованих користувачів)
  • Приватна (тільки для членів)

Адміністратори організації також можуть вказати, чи можуть адміністратори репозиторіїв додавати або видаляти доступ для команд. Вони також можуть вказати максимальну кількість репозиторіїв.

При створенні нової команди вибираються кілька важливих налаштувань:

  • Вказується, до яких репозиторіїв організації члени команди зможуть отримати доступ: конкретні репозиторії (репозиторії, до яких додана команда) або всі.
  • Також вказується, чи можуть члени створювати нові репозиторії (творець отримає адміністративний доступ до нього).
  • Дозволи, які матимуть члени репозиторію:
  • Адміністративний доступ
  • Специфічний доступ:

Команди та користувачі

У репозиторії адміністратор організації та адміністратори репозиторіїв (якщо це дозволено організацією) можуть керувати ролями, наданими співпрацівникам (іншим користувачам) та командам. Є 3 можливі ролі:

  • Адміністратор
  • Запис
  • Читання

Аутентифікація Gitea

Веб-доступ

Використовуючи ім'я користувача + пароль і потенційно (і рекомендовано) 2FA.

SSH ключі

Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному приватному ключу виконувати дії від вашого імені. http://localhost:3000/user/settings/keys

GPG ключі

Ви не можете видавати себе за користувача з цими ключами, але якщо ви їх не використовуєте, може бути можливим, що ви будете виявлені за відправку комітів без підпису.

Особисті токени доступу

Ви можете згенерувати особистий токен доступу, щоб надати додатку доступ до вашого облікового запису. Особистий токен доступу надає повний доступ до вашого облікового запису: http://localhost:3000/user/settings/applications

Додатки Oauth

Так само, як і особисті токени доступу, додатки Oauth матимуть повний доступ до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як зазначено в документації, області ще не підтримуються:

Ключі для розгортання

Ключі для розгортання можуть мати доступ лише для читання або запису до репозиторію, тому вони можуть бути цікавими для компрометації конкретних репозиторіїв.

Захист гілок

Захист гілок призначений для не надання повного контролю над репозиторієм користувачам. Мета полягає в тому, щоб встановити кілька методів захисту перед тим, як можна буде писати код у деяку гілку.

Захист гілок репозиторію можна знайти за адресою https://localhost:3000/<orgname>/<reponame>/settings/branches

note

Неможливо встановити захист гілки на рівні організації. Тому всі вони повинні бути оголошені в кожному репозиторії.

Різні захисти можуть бути застосовані до гілки (наприклад, до master):

  • Вимкнути Push: Ніхто не може відправити дані в цю гілку
  • Увімкнути Push: Будь-хто з доступом може відправити дані, але не може примусово відправити.
  • Список дозволених обмежених Push: Тільки вибрані користувачі/команди можуть відправити дані в цю гілку (але без примусового відправлення)
  • Увімкнути список дозволених для злиття: Тільки користувачі/команди зі списку дозволених можуть зливати PR.
  • Увімкнути перевірки статусу: Вимагати, щоб перевірки статусу пройшли перед злиттям.
  • Вимагати схвалення: Вказати кількість схвалень, необхідних перед злиттям PR.
  • Обмежити схвалення для списку дозволених: Вказати користувачів/команди, які можуть схвалювати PR.
  • Блокувати злиття на основі відхилених оглядів: Якщо запитуються зміни, його не можна зливати (навіть якщо інші перевірки проходять)
  • Блокувати злиття на основі офіційних запитів на огляд: Якщо є офіційні запити на огляд, його не можна зливати
  • Скасувати застарілі схвалення: Коли є нові коміти, старі схвалення будуть скасовані.
  • Вимагати підписаних комітів: Коміти повинні бути підписані.
  • Блокувати злиття, якщо запит на злиття застарілий
  • Захищені/незахищені шаблони файлів: Вказати шаблони файлів для захисту/незахисту від змін

note

Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, репозиторії можуть бути захищені, що заважає вам відправляти код у master, наприклад, для компрометації CI/CD конвеєра.

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks