# Публична папка .git: недооценено изтичане на данни

> Публична ли е Вашата папка .git? Как да проверите, да блокирате достъпа, да преминете към друго внедряване и да се справите с данните за достъп от историята.

Източник: https://phpsos.de/bg/blog/git-ordner-oeffentlich/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Публична папка .git възниква, когато един уебсайт се внедрява с `git clone` или `git pull` директно в уеб корена и уеб сървърът не блокира скритите папки. Тогава целият изходен код заедно с историята на версиите може да бъде изтеглен, включително данни за достъп, добавени отдавна. Проверете домейните си с просто извикване, блокирайте достъпа веднага, преминете към внедряване с пакети без `.git` и сменете данните за достъп от историята.

## Изходният код за вкъщи

Git е стандартният инструмент за контрол на версиите и за малките екипи е естествено да го ползват и за внедряване: свързване със сървъра, `git pull`, готово. Това работи надеждно и е бързо. Има обаче страничен ефект, който често никой не забелязва.

В папката на проекта има скрита папка `.git`. Тя съдържа не само текущото състояние, а всеки файл във всяка версия, която някога е била добавена, освен това съобщения към commit-ите, имена и имейл адреси на разработчиците и препратки към сървъри. Ако тази папка стои в уеб корена и уеб сървърът я доставя, всеки може да я изтегли.

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

## Публична ли е Вашата папка .git? Така проверявате

Проверката отнема секунди и не променя нищо. Извикайте за всеки домейн и поддомейн файл, който съществува във всяко Git хранилище:

```bash
# Очаквано: 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 файловете](https://phpsos.de/bg/blog/env-dateien-schuetzen/), покрива и това. Който иска да блокира целенасочено само контрола на версиите, ползва по-тясно правило:

```nginx
location ~ /\.(git|svn|hg)(/|$) {
    return 404;
}
```

```apache
RedirectMatch 404 /\.(git|svn|hg)(/|$)
```

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

> **Действайте веднага:**
> Ако папката е била достъпна, третирайте всички данни за достъп, които някога са били в хранилището, като известни. Само блокиране тогава не е достатъчно, стойностите трябва да бъдат сменени.

## Трайно: внедряване без .git в уеб корена

Блокирането е допълнителна защита, а не решение. Трайно контролът на версиите не принадлежи на продукционния сървър. Доказани пътища, в зависимост от Вашата среда:

| Метод | Как работи | Подходящ за |
|---|---|---|
| Build пакет от CI | Pipeline изгражда архив без `.git`, сървърът го разархивира в нова директория за изданието | Екипи с CI/CD |
| `git archive` | създава архив на едно състояние без данни за версиите | Малки проекти без pipeline |
| `rsync` с изключения | прехвърля само необходимите файлове | Класически сървъри |
| Образ на контейнер | Кодът се копира в образа при изграждането, `.git` се изключва чрез `.dockerignore` | Експлоатация с контейнери |

Директория за изданието за всяка версия със символна връзка към текущото състояние има още едно предимство: при проблеми можете веднага да се върнете назад. За контейнерни конфигурации [CI/CD: автоматично ново изграждане на PHP образи](https://phpsos.de/bg/blog/php-images-in-ci-neu-bauen/) описва как изгражданията стават възпроизводими. Там трябва да се провери и че `.git` не попада в образа.

```bash
# Пример: създаване на пакет от едно състояние без данни за версиите
git archive --format=tar.gz -o release.tar.gz HEAD
```

## Други файлове на проекта, които не принадлежат в уеб корена

Папката `.git` е най-известният пример, но не е единственият. Който внедрява цели директории на проекти, внася в уеб корена и други файлове, които там нямат работа:

- Папки на среди за разработка като `.idea` или `.vscode`, в които разширения за качване на файлове понякога съхраняват адреси на сървъри и данни за достъп.
- `composer.json` и `composer.lock`, които издават точните версии на всички библиотеки и така улесняват търсенето на известни уязвимости.
- Конфигурации за тестове, инструменти за изграждане и pipeline-и, които разкриват вътрешни имена на хостове и процеси.
- Останки от операционни системи като `.DS_Store`, които съдържат списъци с файлове на цели директории.

Решението е същото като при папката `.git`: доставяйте само това, което трябва да е публично, в идеалния случай чрез отделна подпапка като уеб корен. Който така или иначе преминава внедряването към пакети, определя още тогава списък с изключени файлове и го проверява при всеки нов инструмент в проекта.

## Ако папката е била отворена: проверка на историята и журналите

Ако се окаже, че папката `.git` е била достъпна, действайте в този ред:

1. **Блокирайте достъпа** и повторете проверката.
2. **Преминете през историята** кои тайни някога са били добавяни: конфигурационни файлове, `.env`, ключове, дъмпове на бази данни.
3. **Сменете данните за достъп,** и то всички, намерени в стъпка 2, дори да не стоят днес в кода.
4. **Анализирайте журналите за достъп** дали файлове под `/.git/` са били извиквани със статус 200 и от кои адреси. Как се прави, показва [Анализ на журналите на уеб сървъра след атака](https://phpsos.de/bg/ratgeber/logfiles-auswerten/).
5. **Проверете целенасочено изходния код,** защото атакуващите вече го познават. Известните слабости трябва да се отстранят с предимство.
6. **Изяснете защитата на данните,** ако в историята са били лични данни, например тестови експорти. Оценката поема Вашето длъжностно лице по защита на данните.

Инструменти за търсене на тайни в хранилища след това принадлежат трайно в pipeline-а. OWASP препоръчва изрично такива проверки, като hook преди добавянето и в CI.

## Как помага PHP SOS конкретно?

- Проверяваме всички Ваши домейни и поддомейни за достъпни папки на системата за контрол на версиите.
- Блокираме достъпа веднага и преминаваме внедряването към пакети без данни за версиите.
- Претърсваме историята за тайни и съпровождаме смяната на засегнатите достъпи.
- Анализираме журналите за достъп и документираме дали и кога са били изтегляни данни.

Тези мерки са част от нашето [заздравяване на сървъри за PHP уеб сървъри](https://phpsos.de/bg/leistungen/server-haertung/).


## Често задавани въпроси

**Как възниква публична папка .git?**  
Най-често чрез внедряване с git clone или git pull директно в уеб корена. Папката .git с цялата история на версиите стои тогава до index.php и без блокиране уеб сървърът доставя файловете ѝ.

**Достатъчно ли е да изтрия папката .git?**  
За в бъдеще да, за миналото не. Ако папката е била достъпна, съдържанието вече може да е копирано. Данните за достъп, които някога са били в хранилището, затова трябва да смените.

**Помага ли да премахна данните за достъп от историята на Git впоследствие?**  
Така се избягва новите копия да ги съдържат. Който вече е изтеглил хранилището, продължава да притежава старите състояния. Решаваща затова е смяната на данните за достъп, а не само пренаписването на историята.

**Засяга ли това и други системи за контрол на версиите?**  
Да. И папки като .svn или .hg съдържат данни за проекта и никога не бива да са достъпни в уеб корена. Общо блокиране на файлове и папки с точка в началото покрива всички тези случаи.

## Източници

- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [Документация на Nginx](https://nginx.org/en/docs/)
- [Apache HTTP Server: документация](https://httpd.apache.org/docs/)