Накратко: Публична папка .git възниква, когато един уебсайт се внедрява с git clone или git pull директно в уеб корена и уеб сървърът не блокира скритите папки. Тогава целият изходен код заедно с историята на версиите може да бъде изтеглен, включително данни за достъп, добавени отдавна. Проверете домейните си с просто извикване, блокирайте достъпа веднага, преминете към внедряване с пакети без .git и сменете данните за достъп от историята.
Изходният код за вкъщи
Git е стандартният инструмент за контрол на версиите и за малките екипи е естествено да го ползват и за внедряване: свързване със сървъра, git pull, готово. Това работи надеждно и е бързо. Има обаче страничен ефект, който често никой не забелязва.
В папката на проекта има скрита папка .git. Тя съдържа не само текущото състояние, а всеки файл във всяка версия, която някога е била добавена, освен това съобщения към commit-ите, имена и имейл адреси на разработчиците и препратки към сървъри. Ако тази папка стои в уеб корена и уеб сървърът я доставя, всеки може да я изтегли.
За атакуващите това е подарък. С изходния код уязвимостите могат да се търсят целенасочено, вместо да се налучкват отвън. А в историята често се намират неща, които отдавна са изглеждали изтрити: парола за база данни от първоначалния период, API ключ, тестов файл с данни на клиенти.
Публична ли е Вашата папка .git? Така проверявате
Проверката отнема секунди и не променя нищо. Извикайте за всеки домейн и поддомейн файл, който съществува във всяко Git хранилище:
# Очаквано: 403 или 404
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/config
# На сървъра: има ли папки .git под уеб корените?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Статус 200 означава: папката е достъпна. Обърнете внимание и на подпапките. Понякога хранилището не е в самия уеб корен, а в папка на добавка или тема, която се поддържа отделно с Git.
Проверете освен това staging и тестовите среди. Те се актуализират с Git по-често от продукцията и често са достъпни на лесно налучкваеми поддомейни.
Веднага: блокирайте достъпа
Докато внедряването не бъде променено, правило в уеб сървъра блокира достъпа до папките на системата за контрол на версиите. Общо блокиране за скритите файлове, както е описано в Правилна защита на данните за достъп и .env файловете, покрива и това. Който иска да блокира целенасочено само контрола на версиите, ползва по-тясно правило:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
След това повторете проверката отгоре, и то с истинско извикване отвън: успешният тест на конфигурацията казва само, че синтаксисът е верен, а не че правилото действа преди други правила за статични файлове. При панели като Plesk или cPanel въведете правилото в предвидените допълнителни директиви, за да не се загуби при следващото генериране на конфигурацията.
Ако папката е била достъпна, третирайте всички данни за достъп, които някога са били в хранилището, като известни. Само блокиране тогава не е достатъчно, стойностите трябва да бъдат сменени.
Трайно: внедряване без .git в уеб корена
Блокирането е допълнителна защита, а не решение. Трайно контролът на версиите не принадлежи на продукционния сървър. Доказани пътища, в зависимост от Вашата среда:
| Метод | Как работи | Подходящ за |
|---|---|---|
| Build пакет от CI | Pipeline изгражда архив без .git, сървърът го разархивира в нова директория за изданието |
Екипи с CI/CD |
git archive |
създава архив на едно състояние без данни за версиите | Малки проекти без pipeline |
rsync с изключения |
прехвърля само необходимите файлове | Класически сървъри |
| Образ на контейнер | Кодът се копира в образа при изграждането, .git се изключва чрез .dockerignore |
Експлоатация с контейнери |
Директория за изданието за всяка версия със символна връзка към текущото състояние има още едно предимство: при проблеми можете веднага да се върнете назад. За контейнерни конфигурации CI/CD: автоматично ново изграждане на PHP образи описва как изгражданията стават възпроизводими. Там трябва да се провери и че .git не попада в образа.
# Пример: създаване на пакет от едно състояние без данни за версиите
git archive --format=tar.gz -o release.tar.gz HEAD
Други файлове на проекта, които не принадлежат в уеб корена
Папката .git е най-известният пример, но не е единственият. Който внедрява цели директории на проекти, внася в уеб корена и други файлове, които там нямат работа:
- Папки на среди за разработка като
.ideaили.vscode, в които разширения за качване на файлове понякога съхраняват адреси на сървъри и данни за достъп. composer.jsonиcomposer.lock, които издават точните версии на всички библиотеки и така улесняват търсенето на известни уязвимости.- Конфигурации за тестове, инструменти за изграждане и pipeline-и, които разкриват вътрешни имена на хостове и процеси.
- Останки от операционни системи като
.DS_Store, които съдържат списъци с файлове на цели директории.
Решението е същото като при папката .git: доставяйте само това, което трябва да е публично, в идеалния случай чрез отделна подпапка като уеб корен. Който така или иначе преминава внедряването към пакети, определя още тогава списък с изключени файлове и го проверява при всеки нов инструмент в проекта.
Ако папката е била отворена: проверка на историята и журналите
Ако се окаже, че папката .git е била достъпна, действайте в този ред:
- Блокирайте достъпа и повторете проверката.
- Преминете през историята кои тайни някога са били добавяни: конфигурационни файлове,
.env, ключове, дъмпове на бази данни. - Сменете данните за достъп, и то всички, намерени в стъпка 2, дори да не стоят днес в кода.
- Анализирайте журналите за достъп дали файлове под
/.git/са били извиквани със статус 200 и от кои адреси. Как се прави, показва Анализ на журналите на уеб сървъра след атака. - Проверете целенасочено изходния код, защото атакуващите вече го познават. Известните слабости трябва да се отстранят с предимство.
- Изяснете защитата на данните, ако в историята са били лични данни, например тестови експорти. Оценката поема Вашето длъжностно лице по защита на данните.
Инструменти за търсене на тайни в хранилища след това принадлежат трайно в pipeline-а. OWASP препоръчва изрично такива проверки, като hook преди добавянето и в CI.
Как помага PHP SOS конкретно?
- Проверяваме всички Ваши домейни и поддомейни за достъпни папки на системата за контрол на версиите.
- Блокираме достъпа веднага и преминаваме внедряването към пакети без данни за версиите.
- Претърсваме историята за тайни и съпровождаме смяната на засегнатите достъпи.
- Анализираме журналите за достъп и документираме дали и кога са били изтегляни данни.
Тези мерки са част от нашето заздравяване на сървъри за PHP уеб сървъри.
Често задавани въпроси
Как възниква публична папка .git?
Най-често чрез внедряване с git clone или git pull директно в уеб корена. Папката .git с цялата история на версиите стои тогава до index.php и без блокиране уеб сървърът доставя файловете ѝ.
Достатъчно ли е да изтрия папката .git?
За в бъдеще да, за миналото не. Ако папката е била достъпна, съдържанието вече може да е копирано. Данните за достъп, които някога са били в хранилището, затова трябва да смените.
Помага ли да премахна данните за достъп от историята на Git впоследствие?
Така се избягва новите копия да ги съдържат. Който вече е изтеглил хранилището, продължава да притежава старите състояния. Решаваща затова е смяната на данните за достъп, а не само пренаписването на историята.
Засяга ли това и други системи за контрол на версиите?
Да. И папки като .svn или .hg съдържат данни за проекта и никога не бива да са достъпни в уеб корена. Общо блокиране на файлове и папки с точка в началото покрива всички тези случаи.