TL;DR
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 корректными методами.
Добавить 12 комментариев
A: Не использовать git.
P.S. Про SVN бред какой-то? Она не пихает папки .svn так давно, что я даже навскидку не скажу, сколько лет с тех пор прошло.
https://subversion.apache.org/faq.html#adm-dir
https://ru.wikipedia.org/wiki/Subversion#.D0.9F.D0.B0.D0.BF.D0.BA.D0.B0_.svn_.D0.B2_.D0.BA.D0.B0.D0.B6.D0.B4.D0.BE.D0.B9_.D0.BF.D0.B0.D0.BF.D0.BA.D0.B5
?
Между уязвимым сайтом и сайтом с «открытым» (через Git/SVN) исходным кодом разница такая же как между «вор знает шифр от вашего сейфа» и «вор знает модель вашего сейфа», т.е. принципиально огромная, и чаще всего непреодолимая. Однако, поскольку из второго случая никакого исследования и статьи не получится, то формулировки подогнаны под первый случай, хотя вроде как автор нигде не соврал, и даже усилил статью абзацем про возможность обнаружить в открытом доступе пароли.
В общем, молодец.
В git ровно столько же лет при деплое используется —depth 1 и тогда нет и следа контроля версий. А из-за того что почти весь набор утилит для деплоя использует такую технику, то и проблемы нет.
@Tvolod
нет, вор не просто знает модель вашего сейфа но и читает его конфигурационные файлы с доступом к базам данным, серверам кластера или проксисерверам, последнее даже еще опаснее, так как позволит dDOS-сить настоящий сервер а не проксируемый на сервисе защиты.
«Но, по моему мнению, лучше всего не использовать Git/SVN на production-сервере, осуществляя deploy корректными методами.»
ребят, а что такое деплой корректными методами?
Многие используют Git, чтобы одной командой получать обновления на production-сервер, при этом вся папка с проектом и служебными файлами находится в Document Root.
В идеальном варианте, на production-сервер не должно попадать никаких «лишних» файлов/данных/настроек.
Если существует причина, по которой наличие репозитория на сервере всё же необходимо, то размещать его стоит за пределами Document Root.
git —bare init
> hooks/post-receive
git —work-tree=${WEB_DIR} clean -fd —exclude=
git —work-tree=${WEB_DIR} checkout —force
svn export
Боюсь про «-depth 1» — это заблуждение. Папка .git всё так же создается при git clone —depth 1, соответственно, можно получить доступ к HEAD/config и восстановить файлы из последнего коммита.
SVN с версии 1.7 «не пихает» лишь в _каждую_ поддиректорию папки .svn, а хранит одну в корне.
Не знаю, это в шутку вопрос или всерьез? Если всерьез, то кажется очевидным, что корректный метод — это такой (любой), при котором инженер, ответственный за развертывание, полностью отдаёт себе отчет в том, что при этом происходит и какие в точности файлы идут на боевую машину. По-моему, также совершенно очевидно, что, поскольку VCS — это своего рода расширения для файловых систем, добавляющие к файлам и папкам еще одно измерение — время, то эти расширения не могут быть бесплатными, и где-то они это «время» хранят внутри обычной файловой системы. Не знаю, у меня наверно синдром нездоровой въедливости что ли, я не могу расслабица и рукожопить, как многие вокруг, поэтому как само собой разумеющееся писал скрипт, рекурсивно выкусывающий все скрытые папки .svn еще в те годы, когда никаким web’ом не занимался и когда надо было просто дать кому-то пачку сорцов. А некоторые, похоже, ленятся и не интересуются, как работает вся эта шняга, на которой будут крутиться сорцы стоимостью от нескольких миллионов рублей. Да и правда что, зачем? При мне однажды у предприятия грохнулась бухгалтерия и оказалось, что никто не почесался сделать бекапы!!! А всё потому, что предприятие было очень продвинутым — там все увлекались делегированием и бест практисами.
Вот эти цифры, которые в статье приведены, они конечно полный ахтунг. Потому, что это же топ-1000 проектов. Деплоем обычно занимается лид или его приближенный (ну не доверит же нормальный лид деплоить свою фанеру первому встречному ракообразному?). И если в «голове» такое, то что же в остальных местах? Уныло.
Зависит от. Частый сценарий — это именно что взяли опенсорс движок как он есть в репозитории, а конфигурировали уже на месте без коммитов. Т.е. никаких конфигураций баз данных, паролей и прочего уникального для конкретного сайта там нет.
«Частый сценарий» на основе каких данных?
Несмотря на то, что данный вариант возможен, — в «дикой природе» замечен не был.
Возможно это актуально для «сделанной вчера» тестовой поделки, но для публичных проектов, на мой взгляд, — редкость.
Если разработчики используют Git — они будут использовать его не только для того, чтобы «взять движок», в противном случае — они банально скачают его архив.