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

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

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

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

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

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

1. Оцініть ціль

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

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

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

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

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

4. Пройдіть по історії

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

5. Ключ досі на місці

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

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

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

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

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

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

9. Надходить сповіщення

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

10. Зник із HEAD, але живий в історії

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