Открытый .git на сайте и забытый .env: как исходный код утекает наружу

Это не экзотика и не сложная атака. Сайт работает, ничего не сломано, а по адресу ваш-сайт.ру/.git/config браузер спокойно показывает текст — и вместе с ним наружу уходит исходный код проекта и вся история его правок. Разберём, откуда это берётся, чем на самом деле опасно и как закрыть за один вечер.

Что такое каталог .git и почему он оказался на сервере

.git — служебный каталог системы контроля версий Git: в нём лежит вся история проекта, то есть каждая версия каждого файла, которая когда-либо была сохранена разработчиком. Сам сайт для работы этот каталог не использует: он нужен только людям, которые пишут код.

На боевом сервере ему делать нечего, и всё же он там регулярно оказывается. Причины однотипные и скучные:

• Папку проекта скопировали на сервер целиком. scp -r, FTP-клиент, «просто залил через файловый менеджер в панели хостинга» — переносится всё, включая скрытые каталоги. Скрытые они, кстати, только для файлового менеджера: веб-сервер их отдаёт как обычные файлы.
• Сайт развернули через git clone прямо в каталог, из которого он отдаётся. Удобно: обновление сводится к git pull. Побочный эффект — .git лежит внутри публичной части сайта и доступен всем.
• Корень сайта указывает не туда. У проектов на современных фреймворках публичной должна быть только подпапка (обычно public/), а всё остальное — уровнем выше. Если в настройках хостинга корнем указана папка проекта целиком, наружу выставляются разом и .git, и .env, и всё прочее содержимое.
• В конфигурации веб-сервера просто нет запрещающего правила. Стандартный Apache по умолчанию закрывает только собственные файлы вида .htaccess, а nginx «из коробки» не закрывает ничего. Всё, что лежит в корне, он честно отдаёт.
• Сайт переезжал. Смена хостинга или подрядчика — это почти всегда копирование каталога как есть, вместе с накопленным мусором.

Обратите внимание: ни в одном пункте нет злого умысла или редкой ошибки. Это обычный путь обычного сайта, поэтому находка встречается у компаний любого размера.

Почему это опаснее, чем «ну увидят исходники»

Первая реакция владельца обычно спокойная: «Ну и что, там нет ничего секретного, обычный сайт на PHP». Проблема в том, что открытый .git — это не «посмотреть пару файлов». Это доступ к архиву проекта, из которого восстанавливается рабочий исходный код целиком, а вместе с ним — вся история изменений.

Что из этого следует практически:

• Видна вся логика сайта. Как проверяется оплата, как формируется ссылка на скачивание документа, какие параметры принимает форма, где стоят проверки прав, а где их забыли. Искать уязвимость наугад больше не нужно — её можно прочитать.
• Видны подключаемые компоненты и их версии — а к версиям привязаны опубликованные уязвимости.
• В .git/config лежит адрес репозитория, а иногда и логин с токеном доступа к нему, если репозиторий подключали по HTTPS со встроенными учётными данными. Это уже не про сайт, а про доступ ко всей вашей кодовой базе, включая другие проекты.
• Видны имена и почты разработчиков из истории коммитов — готовый список целей для писем «от подрядчика».
• И главное — секреты из прошлых версий файлов. Об этом ниже, потому что именно здесь ошибаются чаще всего.

Ключевая мысль: удалить пароль из файла — не значит удалить его из истории

Git устроен так: каждое сохранение (коммит) фиксирует состояние файлов на тот момент и хранит его навсегда. Новый коммит не переписывает старый, а добавляется рядом. История — это не журнал изменений, это набор полных снимков.

Отсюда типичная история, которая происходила почти в каждом проекте:

1. Разработчик в спешке вписал пароль от базы данных прямо в файл конфигурации и сохранил изменения.
2. Через неделю опомнился, вынес пароль в переменные окружения, а из файла удалил. Сделал новый коммит.
3. В текущей версии кода пароля нет. Все спокойны.

Но коммит недельной давности никуда не делся — и в нём этот пароль лежит открытым текстом. Любой, у кого есть копия репозитория, читает не только последнюю версию файла, но и все предыдущие. То есть каждый ключ, пароль и токен, который хотя бы один раз попадал в коммит, остаётся доступным навсегда, даже если из рабочего кода его убрали в тот же день.

Именно поэтому открытый .git опасен даже на сайте-визитке, где «нечего красть»: интересен не текущий код, а то, что в этом коде когда-то лежало и было забыто.

Что обычно лежит рядом

Открытый .git редко бывает единственной находкой: причина у всех этих файлов общая — на сервер выложили рабочую папку целиком. Проверять стоит сразу весь набор.

Все эти адреса злоумышленники не угадывают — их перебирают автоматически, по списку, у всех подряд. Поэтому «наш сайт маленький, кому он нужен» здесь не работает: никто не выбирал ваш сайт персонально.

Как проверить у себя за минуту

Инструменты не нужны, достаточно браузера. Откройте по очереди (подставив свой домен):

1. ваш-сайт.ру/.git/config
2. ваш-сайт.ру/.env
3. ваш-сайт.ру/dump.sql и ваш-сайт.ру/backup.zip
4. ваш-сайт.ру/phpinfo.php

Что означает ответ:

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

Как закрыть

nginx

В блок server { ... } добавляется правило, запрещающее выдачу всего, что начинается с точки:

location ~ /\.(?!well-known) {
    deny all;
}

Оно закрывает разом .git, .env, .svn, .idea и любые другие скрытые файлы и каталоги.

Исключение .well-known убирать нельзя. Каталог /.well-known/ тоже начинается с точки, но он служебный и публичный: через него Let’s Encrypt подтверждает, что домен ваш, когда выпускает и продлевает бесплатный TLS-сертификат. Если закрыть скрытые файлы «все подряд», сертификат перестанет продлеваться — и месяца через три сайт встретит посетителей предупреждением браузера о небезопасном соединении. Конструкция (?!well-known) в правиле означает ровно одно: «всё, что с точки, кроме well-known».

Пара практических замечаний:

• Разместите этот блок выше других правил location ~ в том же server: nginx применяет первое подошедшее регулярное правило по порядку в конфиге.
• deny all; отвечает кодом 403, то есть подтверждает существование файла. Если хотите не подтверждать — замените строку на return 404;.
• После правки проверьте конфигурацию и примените её: nginx -t, затем systemctl reload nginx. Перезагрузка без проверки — хороший способ уронить сайт из-за опечатки.

Резервные копии в корне точкой не начинаются, поэтому их закрывают отдельным правилом:

location ~* \.(sql|zip|tar|gz|bak|old)$ {
    return 404;
}

Перед добавлением убедитесь, что сайт не раздаёт такие файлы легально: если у вас есть раздел с загрузкой прайса в .zip, он перестанет работать. Правильнее вообще не хранить дампы и архивы внутри публичной папки — переложите их уровнем выше.

Apache

Для Apache 2.4 достаточно одной строки в файле .htaccess в корне сайта (создайте его, если файла нет):

RedirectMatch 404 /\.(?!well-known)

Логика та же: любой адрес, содержащий скрытый файл или каталог, получает 404, а .well-known продолжает работать. Резервные копии закрываются отдельно:

<FilesMatch "\.(sql|zip|tar|gz|bak|old)$">
    Require all denied
</FilesMatch>

Если хостинг запрещает использовать .htaccess или директивы в нём игнорируются, правило нужно добавить в конфигурацию виртуального хоста — это делает хостер или системный администратор.

Правильный вариант: не выкладывать служебные каталоги вообще

Правило в конфиге — это страховка, а не решение. Решение — чтобы .git и .env физически не лежали в публичной части сайта:

• Выкладывайте результат сборки, а не рабочую копию репозитория. На сервер должны попадать только файлы, нужные для работы сайта.
• Если копируете вручную — исключайте служебное явно. У rsync для этого есть --exclude: например, rsync -a --exclude='.git' --exclude='.env' .... У FTP-клиентов есть фильтры передачи.
• Разворачиваете через git clone — клонируйте не в публичную папку. Держите репозиторий уровнем выше корня сайта, а наружу отдавайте только нужный подкаталог.
• Проверьте, что корнем сайта указана именно публичная папка (для типовых фреймворков — public/), а не каталог проекта целиком. Это одна настройка в панели хостинга, и она закрывает сразу половину описанных проблем.

Если каталог был открыт: закрыть доступ — это только половина

Самая частая и самая дорогая ошибка на этом шаге — остановиться. «Правило добавили, теперь 404, вопрос решён». Не решён.

Пока каталог был доступен, содержимое мог скачать кто угодно, и следов это почти не оставляет: обычный запрос к обычному файлу, ничего подозрительного в логах. Автоматические переборщики ходят по чужим сайтам постоянно и складывают найденное впрок — использовать добытые ключи могут через недели после того, как вы всё закрыли. У вас нет способа доказать, что копию никто не забрал. Значит, исходить нужно из того, что забрали.

Все секреты, которые лежали в коде и в истории, считаются скомпрометированными и подлежат перевыпуску. Практический список:

• Пароль базы данных — сменить, обновить в конфигурации приложения. Заодно проверьте, доступна ли база снаружи: если да, закрыть.
• Ключи платёжного шлюза — перевыпустить в личном кабинете эквайринга. Утёкший ключ — это не только чужие операции, но и доступ к данным ваших платежей.
• Ключи внешних сервисов и API — доставка, СМС, карты, CRM, склад, любые интеграции. Отзывать по списку, а не «те, что кажутся важными».
• Токены почтовых рассылок — с ними отправляют письма от вашего имени и с вашей репутацией домена, а получают их ваши клиенты.
• Секрет сессий и ключ шифрования приложения — со старым секретом можно подделать сессионную куку и войти под чужой учётной записью, не зная пароля. Учтите: смена секрета разлогинит всех пользователей — это неприятно, но это правильная цена.
• Ключи доступа к самому репозиторию, если они были в .git/config, и любые SSH-ключи, попавшие в проект.
• Пароли администраторов сайта — сменить, а заодно просмотреть список учётных записей: не появилось ли новых.

Перевыпуск ключей — работа на несколько часов и почти всегда с простоем интеграций. Соблазн решить, что «наверное, никто не успел», очень велик. Но цена ошибки несимметрична: перевыпустить ключи впустую — потерянный вечер, не перевыпустить вовремя — списания по вашему платёжному ключу и рассылка от вашего имени через месяц, когда связь с открытым .git уже никто не установит.

Как не допустить повторения

1. Внесите .env и подобные файлы в .gitignore — тогда они физически не попадут в репозиторий. Рядом держите .env.example с теми же именами настроек, но с пустыми значениями: новый разработчик поймёт, что нужно заполнить, а секрета в истории не появится.
2. Секреты — в переменных окружения или в хранилище хостинга, не в файлах кода. Правило простое: если значение нельзя показать постороннему, оно не должно попадать в репозиторий даже на минуту.
3. Разные ключи для тестовой и боевой среды. Тестовый контур почти всегда защищён хуже, и именно из него ключи утекают чаще. Если ключи одинаковые, утечка из теста — это утечка с боевого сайта.
4. Проверяйте после каждого переезда и каждой выкладки вручную. Смена хостинга, подрядчика, перенос на новый сервер — три ситуации, в которых .git возвращается на место чаще всего. Проверка занимает минуту.
5. Поставьте регулярную внешнюю проверку. Ручная проверка хороша ровно один раз: она ничего не скажет о файле, который появится в корне через полгода после спешного релиза в пятницу. Смысл имеет только повторяющийся контроль.
6. Если один такой файл нашёлся — ищите остальные. Причина у них общая, поэтому по одному они встречаются редко.