Обхід захисту гілки

Що таке Обхід захисту гілки?

Основна гілка без захисту приймає все, що в неї надсилають. Будь-хто з правом надсилати зміни може закомітити просто в main або примусовим push переписати її історію. Рев'ю та перевірки статусу працюють лише тоді, коли щось змушує зміни через них проходити. Ви надішлете зміни просто в main з обліковими даними контриб'ютора, здобутими фішингом, потім примусовим push перепишете історію й побачите, як обминається CI. Далі ви налаштуєте захист гілки: вимагатимете пул-реквест, рев'юерів і успішні перевірки та забороните примусовий push, а також увімкнете параметр, який поширює правила на адміністраторів, бо правило, яке привілейовані облікові записи можуть обійти, не є засобом контролю.

Що ви дізнаєтесь у Обхід захисту гілки

• Розпізнавайте, що дозволяє незахищена основна гілка: прямі push і примусові push, які переписують історію та обходять рев'ю пул-реквестів і перевірки статусу CI
• Простежте, як один зламаний обліковий запис контриб'ютора може надіслати код без рев'ю просто в продакшн, якщо злиття в основну гілку автоматично розгортаються
• Зрозумійте, чому примусовий push у спільну гілку небезпечний: він переписує історію, яку інші переглянули й на якій працюють, і може стерти коміти з гілки для всіх, хто її оновлює
• Застосовуйте правила захисту гілки, які вимагають пул-реквест, обов'язкових рев'юерів і успішні перевірки статусу та блокують примусовий push в основній гілці
• Вмикайте параметр, який поширює правила на адміністраторів, щоб правило не можна було обійти привілейованими обліковими записами, — тоді засіб контролю діє для всіх

Обхід захисту гілки — Кроки навчання

1. Викрадений обліковий запис контриб'ютора

   Сьогодні Боб націлився на Riftwell, компанію, яка розробляє програмне забезпечення для логістики. Він виманив фішингом облікові дані контриб'ютора репозиторію dispatch-api і хоче, щоб його власний код запрацював у продакшні, а перед тим ніхто його не переглядав. Спершу він відкриває репозиторій, у який можна надсилати зміни з викраденого облікового запису.

2. Гілку main нічим не захищено

   Панель стану репозиторію каже Бобу все, що йому потрібно. Основна гілка — main, у полі «Захист гілки» стоїть «немає», а кожен push у main розгортається прямо в продакшн. Без жодних правил на гілці він може надсилати зміни просто в неї та примусовим push переписувати її історію, а все, що потрапляє в гілку, одразу йде в продакшн.

3. Клонуйте репозиторій

   Боб клонує репозиторій локально з викраденого облікового запису, щоб переписати його історію й підготувати свою зміну, перш ніж надіслати її назад у main.

4. Відмотайте історію повз коміт аудиту

   Останній коміт у main, що пройшов рев'ю, додав журналювання аудиту до сервісу автентифікації — саме той запис, який привернув би увагу до зміни, що Боб збирається зробити. Тому він починає з того, що відмотує свою локальну гілку main на один коміт назад і повністю відкидає коміт із журналюванням аудиту. На захищеній гілці це було б неможливо. Тут це одна команда.

5. Примусовий push поверх main

   Боб примусово надсилає свою відмотану історію просто в main. Гілку не захищено, тож сервер її приймає, і коміт із журналюванням аудиту, що пройшов рев'ю, зникає зі спільної гілки, ніби його ніколи не зливали. Усі, хто тепер зробить pull із main, теж тихо втратять цей коміт. Ось що робить примусовий push у спільну гілку: він переписує історію, яку інші вже переглянули й на якій працюють.

6. Відкрийте middleware автентифікації

   Тепер Боб додає свій код. Він відкриває middleware автентифікації — файл, через який проходить кожен запит до API диспетчеризації, — і спершу читає його до будь-яких змін.

7. Підкиньте обхід захисту

   Боб додає невеликий блок угорі middleware. Він схожий на шар сумісності зі старим ретранслятором, але будь-який запит із одним фіксованим значенням заголовка пропускається як запит адміністратора — без токена й без перевірки підпису. Бекдор у кожен маршрут, який захищає сервіс, замаскований під нешкідливу дрібницю.

8. Сховано на видноті

   Доданий блок стоїть серед звичайного middleware і виглядає як те, що міг би написати бекенд-розробник. На перший погляд у ньому немає нічого тривожного — саме тому він пройшов би швидке рев'ю, якби рев'ю взагалі було.

9. Коміт просто в main

   Боб комітить зміну прямо в main з повідомленням про тайм-аут ретранслятора — нічого, що згадувало б автентифікацію. Жодної гілки й жодного пул-реквесту: коміт уже лежить в основній гілці його клона.

10. Push просто в продакшн

    Боб надсилає коміт просто в main. Не потрібно відкривати пул-реквест, ніхто не має його схвалити, жодна перевірка статусу не блокує. Гілка приймає коміт, а оскільки злиття в main автоматично розгортаються, його бекдор за лічені секунди працює в продакшні.