Всем привет! Мы постоянно исследуем проекты наших клиентов совернешшно разного уровня ИТ зрелости и периодически “то там, то тут” натыкаемся на доступные из интернета /.git (часто) и /.svn (редко) репозитории. Так и решили что стоит рассказывать о самых частых уязвимостях и почему они действительно опасны.

И что не маловажно – мы будем рассказывать и рассматривать в наших статьях не только как защититься, но и как проверить себя, и даже будем показывать утилиты которыми пользуются исследователи безопасности и злоумышленники. Мы не несем ответственности за возможный ущерб при неправильном использовании представленной информации, а так же за неправильное ее восприятие или произвольную трактовку.

Подробнее про ответсвенность мы написали в статье Преступление и наказание.

GIT – с чем его едят и что он хранит в себе

Начать стоит с того практически все сайты сейчас используют систем контроля версий и хранилища кода, такие как GIТ¹ (мы на нем остановимся в нашей статье) для совместной работы разрыботчиками над проектом. Сейчас использование GIT является индустриальным стандартом.

Код проекта очень чувствительное место – он хранит в себе описание бизнес логики, алгоритмов. Злоумышленник так же там может найти уязвимости в коде, некорретную обработку данных, пароли и ключи доступа к различным API, базам данных и облачным сервисам (если не используются системы хранения секретов) или даже просто файл бэкапа, что откроет доступ к данным. Все это может привести к эксплуатации уязвимостей и доступу к данным.

Доступный GIT во вне и как получают доступ к исходным кодам проекта

Из-за некорректной и недостаточной настройки вебсервера, и использовании GIT на сайте часто можно найти доступными файлы .git/config и .git/index. Именно их сначала проверяют исследователи.

.git/config раскрывает информацию о конфигурации и путях до репозиториев

Как видите .git/config может показать ссылку на репозиторий проекта, так же тут иногда бывают ключи доступа к репозиториям, почты и имена сотрудников.

.git/index дает пути до всех файлов, которые есть в репозитории

Этот файл – кладезь данных для исследователя. Тут перечислены все файлы, с которыми ведется работа в репозитории. И даже доступп только к этому файлу может нести уже риски безопасности раскрывая пути до файлов, которые хранятся в проекте.

Нужно то всего выполнить 3 консольные команды и у исследователя на руках будут все пути файлов.

А файл .gitignore может показать какие файлы разработчики хотели исключить

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

Полное “выкачивание” репозитория

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

Как обезопасить GIT

Артефактам нечего делать на продуктивных серверах

На самом деле ответ на “а как сделать так, чтобы GIT не был доступен на серверах” очень просто. GIT на вервере быть не должно. Проект должен собирать автоматически артефакт в рамках CI/CD процесса и доставлять его на сервер с только необходимыми файлами и директориями проекта. В таком случае он и не будет доступен :)

А елси очень-очень нужен GIT на продакшне – то что делать?

Бывают ситуации, когда компания не может выстраивать сложные и безопасные CI/CD процессы по ряду причин. В таких случаях разработчики часто просто используют GIT прямо на сервере чтобы дотягивать изменения, но из-за недотаточной конфигурации сервера он становится уязвимым.

В таким случае рекомендуется ограничить доступ до директорий и файлов, начинающихся с точки. В случае с NGINX можно добавить такую конструкцию в конфигурационный файл NGINX

location ~ /\.git {
  deny all;
}

А в случае с Apache, например,

<Directorymatch "^/.*/\.git/">
  Order 'deny,allow'
  Deny from all
</Directorymatch>

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