Авторы исследования: Александр Недзельский, исполнительный директор ITSOFT
16 сайтов из топ-1000 самых посещаемых сайтов Рунета согласно статистике LiveInternet с совокупной посещаемостью в 34 231 732 пользователей в месяц подвержены простой уязвимости, позволяющей получить доступ к исходникам проекта. Более 2 922 сайтов содержат ошибку конфигурации десятилетней давности. В рамках исследования компания ITSOFT проанализировала более полумиллиона сайтов русскоязычного интернета.
Проблематика
«Всё новое — это хорошо забытое старое». Уязвимость, речь о которой пойдёт ниже, появилась не сегодня и известна давно, как минимум с начала двухтысячных. Но результаты исследования показывают, что актуальная она и сейчас, равно, как и поднимаемые ею проблемы: качества и безопасности разработки интернет-проектов, уровня специалистов на рынке и халатности.
Раньше системы контроля версий использовались лишь на крупных проектах для решения проблем совместной разработки. Время шло, предпочтения менялись, все большее количество разработчиков начало использовать VCS и далеко не всегда по назначению. В 2008 году появился GitHub и к началу 2010-х годовбольшинство разработчиков перешло на Git.
За это время сменились поколения разработчиков, но отношение к вопросам безопасности системно не сильно изменилось. Информационная безопасность, в контексте её базовых аспектов для широкой аудитории, всё так же находится в зачаточной стадии, хотя после утечек данных о покупках в интернет-магазинахи HeartBleed всё большее количество людей начинают о ней задумываться.
Тем не менее, простая ошибка конфигурации и человеческий фактор, который приводил к масштабным последствиям десять лет назад, всё так же актуален.
Уязвимость
Специфика систем контроля версий подразумевает наличие на файловой системе скрытых служебных папок, хранящих информацию о файлах проекта и их изменениях. При неверной конфигурации сервера данная информация становится доступна публично всем пользователям, что позволяет получить доступ к исходникам всего проекта и открывает широкий простор для поиска дальнейших уязвимостей.
По умолчанию Git использует каталог ».git» в папке проекта, в котором хранится информация о всех изменениях файлов проекта. SVN, в свою очередь, содержит подобную информацию в папке ».svn».
Веб-серверы Nginx и Apache по умолчанию не ограничивают доступ к этим папкам, несмотря на то, что файлы и папки, начинающиеся с точки, в UNIX-like системах являются скрытыми, а Apache и сам использует служебные файлы».htaccess».
Поскольку проблема очень распространенная — разработчики CMS и фреймворков рано или поздно вносят запрет на отображение подобных файлов в свои сборки, например как со временем сделал 1С-Битрикс в своем Веб-окружении. Но разработчики веб-серверов подразумевают, что предоставляют базовый инструмент, гибкость которого должна быть использована системными администраторами взависимости от их задач, перекладывая ответственность.
В результате — огромное количество сайтов, предоставляющих свободный доступ к своим исходным кодам, а как следствие — базам данных, серверам, логам, бэкапам и чувствительной информации (в зависимости от каждого конкретного случая).
Статистика и анализ
Спустя семь лет после того, как подобная уязвимость была обнаружена у таких крупных IT-компаний, как Яндекс, Mail.ru, Rambler, Opera (правда тогда речь шла только про SVN), — рассчитывать на повторение истории с теми же участниками не приходилось. Однако, за это время новые ресурсы завоевали свою популярность, количество сайтов в Рунете увеличилось, равно как и пользователей, на смену SVN во многом пришёл Git и уже новое поколение разработчиков создавало эти проекты и переделывало старые. Поэтому количество уязвимых сайтов известных брендов довольно велико: от крупных телекоммуникационных компаний и производителей техники до медицинских клиник и федеральных порталов.
Для иллюстрации мы взяли данные статистики LiveInternet для сайтов Рунета и проверили, какое количество среди содержат данную уязвимость.
Результатом анализа топ-1000 самых посещаемых стали 16 проектов с совокупной аудиторией в 34 231 732 пользователей в месяц.
Решив не останавливаться на достигнутом, мы собрали информацию по 559 411 сайтам рейтинга LiveInternet, получив в результате 2 922 уязвимых.
За прошедшие годы распространенность систем контроля версий увеличилась, и теперь их можно встретить не только на крупных проектах, а повсеместно, что можно увидеть на графике. Из смещения распределения для SVN вправо можно сделать вывод о том, что разработчики крупных сайтов в своё время выучили урок или просто перешли на Git. Огорчает тот факт, что системно опыт не был накоплен и передан новому поколению разработчиков, которое, уже используя другие инструменты, совершает те же ошибки на крупных проектах. Результат: количество уязвимых сайтов в разы выше при приближении к первому месту в рейтинге посещаемости.
Соотношение количества уязвимых проектов, использующих Git и SVN, повторяет результаты рейтинга систем контроля версий. Это может говорить о том, что вероятность ошибок безопасности не зависит от инструмента и условно-постоянна.Примечательно, что есть проекты, у которых доступны обе скрытые папки.
Само по себе раскрытие информации, хранящейся в скрытых папках, может не привести к серьёзным последствиям, если в репозитории находятся только файлы, относящиеся к фронтенд-части проекта. Однако, на практике мы имеем: пароли в открытом виде от удаленных хостингов репозиториев проектов, пароли от баз данных, бэкапы, пароли от других серверов, чувствительную информацию пользователей, ключи доступа к сторонним сервисам; не говоря о том, что доступ к исходникам серверной части проекта позволяет обнаружить уязвимости в коде.
Как проверить и исправить
Для того, чтобы узнать, уязвим ли ваш проект, достаточно лишь ввести в адресной строке браузера http://domain.ru/.git/HEAD или http://domain.ru/.svn/entries для Git и SVN соответственно. Если вы увидели что-то отличное от сообщения о ненайденной странице — стоит задать вопрос разработчикам.
Закрыть брешь можно настроив веб-сервер на запрет доступа к скрытым файлам и папкам. Но, по моему мнению, лучше всего не использовать Git/SVN на production-сервере, осуществляя deploy корректными методами.
