Секрети в історії Git

Що таке Секрети в історії Git?

Видалення жорстко закодованих облікових даних у новому коміті не видаляє їх. Git зберігає кожну версію кожного файлу, тому значення все ще залишається в коміті перед очищенням. Поточний код виглядає чистим, тому ці витоки зберігаються роками. Ви знайдете комміт, у якому стверджується, що було видалено робочий ключ API, прочитайте його з коміту раніше та відтворіть його в реальному API адміністратора. Тоді ви очистите історію за допомогою git filter-repo, навмисно в неправильному порядку, і дізнаєтесь, чому ротація стоїть на першому місці.

Що ви дізнаєтесь у Секрети в історії Git

• Визнайте, що видалення жорстко закодованого секрету в новому коміті не видаляє його: git зберігає значення в кожному попередньому коміті та в reflog, тому кожен, хто клонує репо, може його прочитати
• Дотримуйтеся шляху зловмисника від клонування загальнодоступного репо до списку історії комітів файлу, до показу комітів перед видаленням до повторного відтворення активного ключа API, який ніколи не обертався
• Зрозумійте, що переписування історії не може згадати секрет, який уже був клонований або просканований, тому зміна облікових даних є єдиним кроком, який фактично робить недійсним витік значення
• Надайте пріоритет ротації облікових даних як основному виправленню та застосуйте перезапис історії за допомогою git filter-repo або BFG і примусове віддалене оновлення, щоб видалити секрет із кожного коміту як очищення, а не як виправлення
• Запобігайте повторенню, зберігаючи секрети поза джерелом за допомогою змінних середовища та додаючи хук сканування секретів перед фіксацією, щоб облікові дані блокувалися ще до того, як вони потраплять в історію сховища

Секрети в історії Git — Кроки навчання

1. Збільште розмір мішені

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

2. Клонуйте репо

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

3. Перевірте поточний код

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

4. Пройдіться історією

   Чистий файл у HEAD нічого не говорить про минуле. Ключ зник із поточного коду, але git зберіг усі попередні версії цього файлу. Боб це знає, тому він перераховує історію комітів конфігурації, щоб побачити, що вона містила раніше, а не лише те, що містить зараз.

5. Ключ все ще там

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

6. Ключ все ще працює

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

7. Список клієнтів відкритий

   Сервер довірив ключу та відповів. Боб читає внутрішній список клієнтів Larkfell із публічного API, не маючи власного облікового запису.

8. Перевірка знань

   Ви щойно спостерігали, як видалений секрет все ще відкриває робочий API. Зафіксуйте чому.

9. Тривога приземляється

   Ви володієте серверним репо Larkfell. Вночі служба секретного сканування, яка стежить за вашими публічними сховищами, випустила сповіщення та надіслала його вам електронною поштою. Висновок однозначний: активний робочий ключ API присутній в історії відкритих комітів. Його немає в поточному коді, але сканер пройшовся по історії та знайшов його в попередньому коміті.

10. Пішов із ГОЛОВИ, живий в історії

    Ваш перший інстинкт — перевірити поточний код, і ключ справді зник із HEAD. Хтось уже видалив рядок у пізнішому коміті. Це не допомогло. Ви самі показуєте попередній комміт, і активний ключ друкується відразу. Він зберігається в кожному коміті, який все ще містить його, тому видалення рядка з останньої версії залишило облікові дані повністю читабельними для всіх, хто клонував репо.