Тайни в кода: изтичането с дълготрайни последствия

Тайни, включени в изходния код или публикуван пакет, могат да предоставят на нападателя директен достъп до свързани системи. Откриваме ги в мобилни приложения, хранилища за код, клиентски JavaScript пакети и конфигурационни файлове. Разглеждаме как се разкриват, какво позволяват и как да ограничите последствията.

Къде се крият тайните

• Двоични файлове на мобилни приложения. Приложението е файл на устройството на нападателя. Разархивирайте го, прочетете текстовите низове и API ключовете и данните за достъп до сървърната част, компилирани в него, са точно там.
• Код на предната част. Всичко в JavaScript от страна на клиента е публично. „Вътрешен“ API ключ в пакет не е вътрешен.
• Хранилища и история. Изтриването от текущите файлове не премахва тайната от по-стари commits или съществуващи копия. Публични или изтекли хранилища могат да разкриват стойностите до отнемане на засегнатите credentials.
• Конфигурация, разпространена до клиенти. Данни за достъп по подразбиране, ключове за подписване, низове за връзка, вградени в инсталатори.

Защо продължава да се случва

Тайните се кодират твърдо, защото това е пътят на най-малкото съпротивление при краен срок и защото „никой няма да погледне“. Хората гледат — автоматично, в голям обем. По-дълбокият проблем е архитектурен: приложението изобщо е било проектирано да държи дълготрайна тайна. Ако една стойност в разпространения ви артефакт би била опасна в ръцете на нападател, не бива да е в артефакта.

Как да спрете изтичането

• Не разпространявайте дълготрайни тайни. Удостоверявайте потребителя и посредничете за достъпа до сървърните части от страна на сървъра; ограничавайте всеки токен до този потребител и тази сесия.
• Системи за управление на тайни вместо конфигурационни файлове. Внасяйте тайните по време на работа от хранилище за тайни; дръжте ги извън хранилището за код и извън билда.
• Сканирайте непрекъснато. Проверки преди подаване и сканиране за тайни в CI улавят изтичанията, преди да бъдат разпространени. Сканирайте историята, не само текущото състояние.
• Отнемайте или заменяйте при разкриване. Приемайте, че разкрит работещ credential може да е получен, прекратете приемането му и оценете употребата и правата. Превърнете замяната в обичайна, проверена операция.

Обфускацията купува минути. Архитектурата купува безопасност: единствената тайна, която нападателят не може да открадне от вашия артефакт, е онази, която никога не е била в него.

Подмяната е частта, която всички прескачат

Приемайте разкрит credential за потенциално компрометиран и своевременно го отнемете или заменете, като прекратите приемането на стария. Проучете правата и наличните данни за употреба; замяната не премахва достъпа на нападателя и не отменя предишни действия. Частен локален commit сам по себе си не доказва, че някой е получил тайната, но изтриването не я премахва от съществуващата история или копията.

Гледната точка на зависимостите

Тайните ви не са само във вашия код. Всяка зависимост, която внасяте, работи в същия процес и може да чете същата среда — така че компрометиран или злонамерен пакет може да отнесе данните за достъп, които приложението ви държи. Ограничавайте тайните толкова строго, колкото задачата позволява, предпочитайте краткотрайни токени и допускайте, че код от трета страна може да вижда всичко, което процесът вижда. Рискът по веригата на доставки и хигиената на тайните са един и същ разговор.

Как работи сканирането за тайни

Скенерите се опират на две допълващи се техники и разбирането на двете обяснява защо пропускат неща. Първата е съвпадение по шаблон: регулярни изрази, настроени към формата на известни данни за достъп, често закотвени към специфичен за доставчика префикс и фиксирана дължина. Те са точни и евтини, но улавят само тайни, за чийто формат някой вече е написал правило. Специфичен HMAC ключ за подписване или вътрешен токен без отличителен префикс минава направо.

Филтрите по ентропия могат да откриват случайно изглеждащи низове, но хешове, идентификатори и тестови данни също могат да имат високи стойности. При правило с минимална ентропия понижаването на прага допуска повече кандидати; повишаването отхвърля повече и може да пропусне реални тайни с ниска ентропия. Настройвайте конкретния инструмент и правило с представителни положителни и отрицателни примери, вместо да приемате един праг за универсален контрол на качеството.

Честният извод е, че никое единично преминаване не е пълно. Правилата по шаблон пропускат необичайното; ентропията пропуска обикновеното. Най-силните инструменти съчетават и двете с проверка — обръщане към доставчика, за да се потвърди, че кандидатът е действащ — което намалява шума драматично, но трябва да се прави само срещу собствената ви среда.

Изтриването не е прочистване: правилно изчистване на историята на git

Тайна, подадена в хранилище за код, не се премахва чрез изтриване на файла и ново подаване. Git е адресируем по съдържание и само добавящ: старият обект все още живее в историята, достижим през предходното подаване, а всеки, който е клонирал или форкнал хранилището, все още държи пълно копие. Огледалата, кешовете на CI, мрежите от форкове и референциите на заявките за сливане също го запазват.

Решете дали е необходимо изчистване на историята след отнемане и оценка на риска. Ако чувствителен материал трябва да бъде премахнат, използвайте подходяща процедура за пренаписване и координирайте засегнатите branches, tags, references и участници. Кеширани изгледи и pull-request препратки могат да изискват помощ според политиката на платформата. Пренаписването на remote не изтрива чужди копия; ново клониране или внимателно почистване предотвратява връщането на стари обекти.

Всичко това е бавно, разстройващо и никога напълно гарантирано, щом едно хранилище е било споделяно. Затова преписването на историята е ограничаване на вредата, не поправка.

Ограничаване на риска: краткотрайни данни за достъп и идентичност на работните процеси

Федерацията на workload идентичности може да замени съхранен cloud ключ с платформено твърдение, обменяно за краткотрайни credentials. Това намалява срока и управлението на статичните тайни, но не предотвратява повторната употреба на откраднати bearer токени. Откраднат токен може да работи до изтичане, а компрометиран runner да получава нови credentials. Ограничете издателя, получателя, субекта и предоставените права и защитете самото приложение или runner.

Това се сблъсква с проблема на „нулевата тайна“: едно натоварване все пак има нужда от някакво първоначално доверие, за да докаже идентичността си. Целта не е това доверие да бъде премахнато, а да бъде сведено до една, строго ограничена, удостоверена от платформата идентичност — и да бъде закотвено в нещо, което средата притежава по същност, а не в копиран низ.

Обръщане на играта: honeytokens като сигнал за неоторизиран достъп

Honeytoken е примамлива стойност, свързана с механизъм за наблюдение и непредназначена за нормална продукционна употреба. Произволен измислен низ не създава автоматично сигнал. Неочаквана употреба може да показва откриване, но скенери, упражнения или случайни действия също могат да я предизвикат. Записвайте разполагането и очакваните тестове и проучвайте сигнала, вместо да приемате всеки за потвърдено компрометиране.