Pull to refresh

Comments 36

Когда то давно, лет 5 назад, а может и больше, была статья на хабре, человек собирал такую же статистику, только для svn.
Идут года, технологи меняются, проблемы остаются :)
ого, давно было.
Это какая то печаль, я начал думать что уже старый.
Я и про svn тогда писал и про git, ага.
Если меня разбудят через 100 лет и спросят чем живут хакеры, я отвечу «сканируют директории и порты».
Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 599 (0,0060% от общего числа)

0,6%

Для чего вообще может быть нужно держать в паблик-директории сервера весь проект и иметь извне доступ к чему-либо кроме public/web/...?
В моём опыте этого не нужно было никогда делать, но, судя по посту, такое иногда делают (пусть даже закрыв git/svn). В каких случаях?
Часто такое бывает в виде дефолтной конфигурации. Зачем это делать? Действительно причин не сильно много.
могу предположить, что это способ деплоя, ручное обновление кода из репозитория
Не обязательно ручное, хуки на обновление при пушах никто не отменял. Это ленивый деплой, конечно же.
взяв выборку скажем в один миллион сайтов — это уже порядка 10 000 сайтов с подобной брешью

агануда
image

Дабы подкрепить это утверждение, я только что поставил на проверку первые миллион сайтов из топа. Вечером сообщу результаты.
Извините за задержку с ответом, поздно вернулся домой. Итак, товарищ justmara был прав — моя оценка была некорректна. На выборке из миллиона я нашел лишь порядка 5 000 репозиториев, что в два раза меньше моей оценки. Таким образом, распределение примерно линейное (вне зависимости от посещаемости сайта).

По поводу защиты:


На самом деле, хранение git-репозитария внутри рабочей директории сама по себе плохая практика by design.
Хорошая практика:


git init --separate-git-dir=/special/folder/for/git/<project-name>
git clone --separate-git-dir=/special/folder/for/git/<project-name> <orig-repository>

И т.д.


В этом случае внутри рабочей директории будет храниться только файлик .git с содержанием вида:


gitdir: /special/folder/for/git/<project-name>
Это всё от лени. Вместо того чтобы клонировать сайт куда-либо в закрытое место, потом архивировать его исключая .hg и .git папки, многие разработчики просто делают «git pull» прямо на рабочем сайте и не заморачиваются.

Почему нет? Выкладку может быть проще делать напрямую из репозитория через git fetch/git pull. Достаточно закрывать .git в конфиге веб-сервера и все счастливы

Вообще нет нужды закрывать её в конфиге, если вебрут ниже корня репы, разве нет?

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

Я несколько лет думал, что все уже только так и делают…

А ведь всё было бы так хорошо имей эти сайты в проекте просто отдельную паблик директорию, в которую бы уже и смотрел веб сервер. И эта проблема бы ушла и десяток других по сокрытию приватных файликов проекта.

на некоторых фреймворках типа ларавела все так и происходит. Есть папка public в которой только index.php и папки с стилями скриптами и картинками
Не на некоторых, а на почти всех фреймворках есть public директория с точкой входа а весь код лежит выше.
Весь проект в корне — это обычно CMS, которые устанавливаются путем копирования по ftp, разумется про git там не слышали. Так что собственно поэтому у нас всего 0.6%
3 Используйте систему деплоя, которая за вас пересоберёт для продакшна проект и корректно экспортирует в публичную папку.
Лучше всетаки бороться с первопричиной и выносить файлы гита за пределы публичной папки веб-сервера, так гораздо меньше шансов забыть про что-то и допустить ошибку, чем при попытках закрывать доступ на них по отдельности. Паролям, сертификатам и любым другим аутентификационным данным, ровно как и бекапам баз данных содержащим такие данные под версионным контролем делать нечего.
Вот только я не понял, как в статье оказался скрин веб-шелла (пример полученных исходных кодов). Вы через админку залазили и заливали (судя по варианту вектора атаки)? :)

//ждем статьи про mercurial?

я думаю, имя доступ к исходникам (проектов такого качества), найти дыру позволившую залить шелл труда не составило)

Это шелл на моем личном сервере, используется, в частности, как удобный файловый менеджер.
Этим грешит даже сайт одного небезызвестного архиватора.
Они как-то отреагировали на сообщение? Потому что я только что попробовал (дальше .git/index не ходил) — всё по-прежнему доступно.
Я отправил им письмо касательно искомого. Пока ответа и/или исправлений не поступало.
Прошли уже сутки, а .git/index все равно доступен… Интересно, сколько появится клонов этого небезызвестного сайта в сети, благодаря Хаброэффекту?
Он доступен уже очень давно, и, судя по всему, будет доступен и далее. Причина, в частности, в том, что на сервере нет особо секретной информации.
Отвечая на ваше предположение по поводу «хаброэффекта», могу сказать, что клонов появится ±0 штук. Ибо это никому не надо. А если бы было надо, то для этого не обязательно залезать в чужой репозиторий (моя субъективная оценка).
Only those users with full accounts are able to leave comments. Log in, please.