Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Основна структура середовища Gitea полягає в групуванні репозиторіїв за організаціями, кожна з яких може містити кілька репозиторіїв та кілька команд. Однак, зверніть увагу, що, як і в github, користувачі можуть мати репозиторії поза організацією.
Більше того, користувач може бути членом різних організацій. У межах організації користувач може мати різні дозволи на кожен репозиторій.
Користувач також може бути частиною різних команд з різними дозволами на різні репозиторії.
І нарешті, репозиторії можуть мати спеціальні механізми захисту.
Коли організація створюється, команда під назвою Власники є створеною і користувач поміщається всередину неї. Ця команда надасть адміністративний доступ до організації, ці дозволи та назва команди не можуть бути змінені.
Адміністратори організації (власники) можуть вибрати видимість організації:
Публічна
Обмежена (тільки для авторизованих користувачів)
Приватна (тільки для членів)
Адміністратори організації також можуть вказати, чи можуть адміністратори репозиторіїв додавати або видаляти доступ для команд. Вони також можуть вказати максимальну кількість репозиторіїв.
При створенні нової команди вибираються кілька важливих налаштувань:
Вказується, до яких репозиторіїв організації члени команди зможуть отримати доступ: конкретні репозиторії (репозиторії, до яких додана команда) або всі.
Також вказується, чи можуть члени створювати нові репозиторії (творець отримає адміністративний доступ до нього)
Дозволи, які матимуть члени репозиторію:
Адміністративний доступ
Специфічний доступ:
У репозиторії адміністратор організації та адміністратори репозиторіїв (якщо це дозволено організацією) можуть керувати ролями, наданими співпрацівникам (іншим користувачам) та командам. Є 3 можливі ролі:
Адміністратор
Запис
Читання
Використовуючи ім'я користувача + пароль і потенційно (і рекомендовано) 2FA.
Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному приватному ключу виконувати дії від вашого імені. http://localhost:3000/user/settings/keys
Ви не можете видавати себе за користувача з цими ключами, але якщо ви їх не використовуєте, може бути можливим, що ви будете виявлені за надсилання комітів без підпису.
Ви можете згенерувати особистий токен доступу, щоб надати додатку доступ до вашого облікового запису. Особистий токен доступу надає повний доступ до вашого облікового запису: http://localhost:3000/user/settings/applications
Так само, як і особисті токени доступу, Oauth додатки матимуть повний доступ до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як зазначено в документації, області ще не підтримуються:
Ключі розгортання можуть мати доступ лише для читання або запису до репозиторію, тому вони можуть бути цікавими для компрометації конкретних репозиторіїв.
Захист гілок призначений для не надання повного контролю над репозиторієм користувачам. Мета полягає в тому, щоб встановити кілька методів захисту перед тим, як зможете писати код у деякій гілці.
Захист гілок репозиторію можна знайти за адресою https://localhost:3000/<orgname>/<reponame>/settings/branches
Неможливо встановити захист гілки на рівні організації. Тому всі вони повинні бути оголошені в кожному репозиторії.
На гілку можуть бути застосовані різні захисти (наприклад, до master):
Вимкнути Push: Ніхто не може надіслати дані в цю гілку
Увімкнути Push: Будь-хто з доступом може надіслати дані, але не може примусово надіслати.
Список дозволених обмежених Push: Тільки вибрані користувачі/команди можуть надіслати дані в цю гілку (але без примусового надсилання)
Увімкнути список дозволених злиттів: Тільки користувачі/команди зі списку дозволених можуть зливати PR.
Увімкнути перевірки статусу: Вимагати, щоб перевірки статусу пройшли перед злиттям.
Вимагати схвалення: Вказати кількість схвалень, необхідних перед злиттям PR.
Обмежити схвалення до списку дозволених: Вказати користувачів/команди, які можуть схвалювати PR.
Блокувати злиття на основі відхилених оглядів: Якщо запитуються зміни, його не можна зливати (навіть якщо інші перевірки проходять)
Блокувати злиття на основі офіційних запитів на огляд: Якщо є офіційні запити на огляд, його не можна зливати
Скасувати застарілі схвалення: Коли є нові коміти, старі схвалення будуть скасовані.
Вимагати підписаних комітів: Коміти повинні бути підписані.
Блокувати злиття, якщо запит на злиття застарілий
Захищені/незахищені шаблони файлів: Вказати шаблони файлів для захисту/незахисту від змін
Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, репозиторії можуть бути захищені, що заважає вам надіслати код до master, наприклад, для компрометації CI/CD конвеєра.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
