Это жесть. Называется не выкладывайте детки на продакшн файлы svn ^)

stat5327000

http://habrahabr.ru/blogs/infosecurity/70330/
Были получены исходники 3300 глобальных интернет-проектов
Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды.
Казалось бы, что в XXI веке трудно найти подобную уязвимость. Кажется, что уже всё найдено, а то что не найдено, сидит где-то очень очень глубоко. Оказалось, что корнем сегодняшнего зла является вполне повседневная вещь. Наверняка каждый из вас когда-нибудь имел дело с системой контроля версий SVN.
SVN является продвинутым средством для организации совместной разработки десятков, а то и сотен разработчиков. В силу особенностей архитектуры, SVN хранит в каждой директории проекта свои метафайлы, аккуратно сложенные в скрытую директорию .svn. В одном из файлов под названием entries находится список всех файлов и директорий, расположенных в той же папке, что и .svn. Так же там находится информация о расположении репозитория, размере файлов, даты их изменения и логины пользователей, работающих над проектом. Уже не плохо, правда? Объясню, получается, если проект разрабатывается с помощью SVN, то заглянув по адресу draftcopy.ru/.svn/entries мы увидим файловую структуру корня проекта с авторами, последними изменениями, ссылкой на основную ветку репозитория итп.
Но можно пойти и далее. В той же папке .svn находится директори text-base, в которой лежат последние версии всех файлов, находящихся в репозитории. Картину дополняет так же и то, что файлы имеют не стандартное расширение (например .php которое позволяет их сразу отправить на интерпретатор, а дополнительное расширение .svn-base, благодаря которому файл отдается запросившему его человеку «как есть», т.е. голый исходный код!
draftcopy.ru/.svn/text-base/index.php.svn-base
Стоит заметить, что описанная картина является идеальной и хоть она и была таковой в большинстве случаев, все же большой процент исходных кодов не удалось получить по тем или иным причинам.
Впервые осознав, что обнаруженная уязвимость присуща большинству проектов последние девять лет, было решено полностью просканировать рунет чтобы посмотреть чем живут интернет-проекты и получить интересную статистику. Но перед историей о том как это было, следует рассказать седым админам, как защищаться от подобного…
Защита от уязвимости
Уязвимость можно обойти несколькими путями. Путь в лоб — запретить обращаться к метадиректориям SVN по 80-ому порту, т.е. средствами вебсервера.
Решение для nginx
location ~ /.svn/ {
deny all;
}
Глобальных локейшенов в nginx`е нет, поэтому прийдется подписывать для каждой server области. Чтобы правило имело силу, необходимо загружать его до других локейшенов с регулярным выражением. Универсальный способ — первым локейшеном.
Решение для Apache
<Directory ~ ".*\.svn">
Order allow,deny
Deny from all
Satisfy All
</Directory>
Тут немного проще, дописываем это в httpd.conf и на всех проектах под управлением apache чтение из директории .svn будет недоступно.
Решение средствами SVN
Защита от уязвимости средствами вебсервера — лечение болезни. Любой доктор скажет, что профилактика проще, легче и менее затратней, чем лечение. Поэтому лучшим решение будет отсутствие этих самых метадиректорий в корне проекта. Добиться этого можно средствами svn export из основной ветки.
Информация взята с twocomrades.ru
История исследования
Как я уже было сказано, было решено просканировать весь рунет на наличие подобной уязвимости. Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru. Первая версия скрипта работала две недели, получая сайт за сайтом в один поток. К завершению сканирования, база насчитывала более 3000 уязвимых сайтов и занимала более ста гигабайт исходных кодов.
Проблемой первого сканировния было то, что скачивались все сорцы без разбора, не зависимо от того, отдавали они 200 или 500 код, а так же закачивалась графика и js-скрипты. А так же часто веб-сервера были настроены таким образом чтобы отдавать 200 код, даже если файл на самом дела отсутствовал.
Вторая версия скрипта была уже шустрее, работала в несколько потоков с двух серверных машин и правильно различала коды ответа содержимое полученных страниц. Мы обошли весь рунет за 4 дня. Дальнейшими планами была база доткомов. Стало очевидно, что при текущих ресурсах обход был бы выполнен как минимум за пару лет (зона com сейчас насчитывает более 700 млн доменов (против 2 млн ru.
К дел был привлечен отличный си-программист Андрей Сатеренко, который написал быстрого демона, который сумел бы в пару раз сократить наши временные затраты. Но, к сожалению, к этому моменту лето кончилось, навалилилась работа. Грандиозные планы было решено свернуть.
Прежде чем публиковать открыто информацию об уязвимости, необходимо было предупредить всех пострадавших. В первую очередь письма были разосланы гигантам (yandex.ru, rambler.ru, mail.ru, opera.com, rbk.ru, 003.ru, bolero.ru, habrahabr.ru, итого 19 адресов затем, сегодняшней ночью, письма получили остальные 3000+ сайтов.
Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах.
Немного статистики:
Просканировано доменов: 2253388
Уязвимых: 3320
Статистики по оповещениям пока нет, возможна она будет опубликована через пару недель. Из крупных порталов, ответили шестеро. Самым оперативным оказался Яндекс, прислав ответное письмо ночью в воскресенье. Десять проектов никак не прореагировали на наши письма, три проекта закрыли уязвимость не поблагодарив.
Мы не злопамятные, мы запишем их имена…
Несколько интересных фактов:
1. Киберсквотеры полюбили SVN, как и оптимизаторы;
2. Единый CSS для календарей яндекса собирается из десятка CSS средстами $make из консоли 0_0;
3. На проектах Рамблера пользуются сервисами Яндекса 0_0, найдены файлы «подтверждения домена» для сервисов Яндекса;
4. РБК использует и сервисы яндекса и сервисы гугля и очень любят «сложные» пароли;
5. Опера уважает MySQL, но сайт у них на голом html с реальными директориями и поддиректориями;
6. Блондинка уважает CodeIgniter;
7. PostgreSQL уважают движок wikimedia => PostgreSQL уважают MySQL ;-)
8. Все проекты Футурико (и Лепра) написаны на perl.
9. Порядка 10 сайтов со словами в домене типа «hack» и «secure» уязвимы;
10. Многие уверены, что назвав директорию с phpmyadmin примерно «__xpma123uff__» но сохранив пароль в конфиг, это хорошая защита;
11. Многие до сих пор хранят конфиги в inc файлах, без расширения .php, которые открываются как текст в браузере.
Для вас старались 2Товарища (mobilz) и Антон Исайкин (oowl, twi).
Мы готовы к сотрудничеству ;)
P.S. Во избежании конфликтов все исходные коды, полученные за время исследования были

stat5327000

Из коментов:
http://www.classmates.com/.svn/entries
http://www.inkscape.org/.svn/
Были и другие интересные, но позакрывали часть уже.

apl13

Я чего-то не понимаю, или это долбоебизм?

zya369

не удалять .svn? да, долбоебизм :grin:

zloDEY

> не удалять
скорее создавать

Andbar

скорее создавать
может впредь будут спрашивать на собеседовании, какой командой следует получать из svn копию для продакшна.

Realist

Я подумал, предлагаю chmod -R go-a .snv
Кстати, мне протирали, что с помощью svn не деплоят.

Dasar

+1 за svn export
а с удаленными из svn файлами что при этом будет?

Realist

Я уже передумал :)

artimon

У меня в своё время был скрипт вида
cd ~/site
svn up
svn export /tmp/site
rsync .... /tmp/site /var/www/site

с правильными ключами для rsync, что бы удалял старые файлы.

Andbar

а с удаленными из svn файлами что при этом будет?
Ну так надо экспортить в новую папку, а потом просто хоумдир переключать или папки переименовывать

AlexV769

Вообще правильно выкладываться версионными пакетами.

Andbar

версионными пакетами
что это такое или как официально называется?

AlexV769

это когда apt-get install some-mega-portal
ну или производные в зависимости от системы.
А пакеты для этого собираются в сторонке.

Andbar

т.е., ты предлагаешь для одной единственной системы собирать ещё пакет? Конечно, это хорошо, если apt-get обеспечивает транзакционность установки, но, с другой стороны, ручками, по идее, можно добиться более быстрого переключения на новую ревизию.

artimon

Ну, капистрано какой-нибудь
svn up уж точно не подразумевает никакой атомарности

AlexV769

Тебе шашечки или ехать?

serega1604

>т.е., ты предлагаешь для одной единственной системы собирать ещё пакет?
ну а чо, я вот для localhost собираю - пусть это даже чуть дольше чем make && make install, зато не делаю из системы помойки.

tipnote

Забавно, а что криминального в просмотре .svn для статики проекта? Или я чего-то не понимаю?

timtaller

Жолтая пресса на самом деле. Заголовок не сильно соответствует содержанию статьи. Например, из заголовка я никак не понял, что речь идет только о веб-решениях.
Ну стырили авторы текста несколько паролей разработчиков, а заметочку так озаглавили, чтобы рейтинг на хабре прокачать

tipnote

паролей разработчиков
Я туповат, наверное, но они только логины потырили макс?

tokuchu

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

timtaller

да, логины

timtaller

Так, пардон. Статья названа нормально. Это - желтая пресса :) :)

tipnote

самое главное — исходники скриптов можно из репозитория стянуть.
Стянуть можно только статику, так? То, что в принципе и так открыто всем подряд.

nikita270601

Почему только статику-то?

nikita270601

А, я понял, у тебя никогда файлы со скриптами не лежали в document root'е. :)
Попробуй PHP!

tipnote

О..

stat5327000

Так, пардон. Статья названа нормально. Это - желтая пресса :) :)
Так точно. Сорри, копипастил под впечатлением.

sergey_m

Вообще правильно выкладываться версионными пакетами.
Я тоже так считаю. Полгода работал в компании, где так и делалось.
У вас сейчас хоть на одном проекте так делается?

artimon

Как мне кажется, у нас большинстве проектов именно так.

ava3443

Я тоже так считаю. Полгода работал в компании, где так и делалось.
А как по-правильному поступают с БД?
"Делаем еще одну БД", - как предложил - бывает непросто, если база здоровая...

AlexV769

yep

sergey_m

В первом посте вы же тоже упоминаетесь, значит не везде?
P.S. тоже уже там? :)

AlexV769

>В первом посте вы же тоже упоминаетесь, значит не везде?
Видимо не везде.
тут на месяц раньше меня оказался :)

sergey_m

А как по-правильному поступают с БД?
БД не есть код, поэтому она не релизится. Схема же БД может быть перестроена между релизами. Тогда в релиз включается conversion script.

cer2008

У вас сейчас хоть на одном проекте так делается?
Конечно, только так и никак иначе.

pilot

Тогда в релиз включается conversion script.
Нужно два скрипта. "вперед" и "назад".
Можете объяснить смысл выкатки версионными пакетами, если при выкатке надо попортить БД и почистить кэши?

AlexV769

какой метод выкатки позволяет этим НЕ заниматься?

pilot

Где это я написал что ими можно не заниматься?
Мне интересно в чем преимущества выкатки версионными пакетами.

artimon

Не знаю как у тебя, а у нас код обновляется чаще, чем схема БД.

pilot

Не знаю как у тебя, а у нас код обновляется чаще, чем схема БД.
И? Вы обычно раскатываете пакетами, а иногда — руками?

sergey_m

Можете объяснить смысл выкатки версионными пакетами, если при выкатке надо попортить БД и почистить кэши?
Смысл не теряется же от того, что выкатка становится трудоёмка.

pilot

Смысл не теряется же от того, что выкатка становится трудоёмка.
Мне кажется что "поставить" и "запустить" это 2 разные вещи. Я не прав?
То есть вот ставлю я себе новую программулину — она ставится, но не запускается при этом.
У тебя новая версия запускается отдельным скриптом? Как обеспечивается быстрое переключение на новую версию?
+ ко всему мне не нравится убогий менеджер пакетов во freebsd, думаю что не надо особо стремиться его использовать.
Вообще план был такой:
ты скажешь что при выкатке версионными пакетами выкаткой могут заниматься админы (и это так и есть).
тут я спрошу "а вы так делаете? и где это работает?" (а это должно работать в больших конторах)

AlexV769

тут я спрошу "а вы так делаете? и где это работает?" (а это должно работать в больших конторах)
На этот вопрос уже был даден ответ чуть выше.

pilot

На этот вопрос уже был даден ответ чуть выше.
На вопрос "делают ли так в Рамблере?". Не видел что-то.
Так про изменение БД, перезапуск и т.п. может быть ты ответишь?

artimon

Всегда пакетами. Если надо, в пакете есть скрипт конвертации.

pilot

Всегда пакетами. Если надо, в пакете есть скрипт конвертации.
А конвертации обратно? (Понятно что можно его там делать и что должен быть, делаете?)

sergey_m

тут я спрошу "а вы так делаете? и где это работает?" (а это должно работать в больших конторах)
Это отлично работало на моей прошлой работе, правда там специфика такая, что по выходным сайту работать совершенно не обязательно, и убытки при этом нулевые, даже косвенных убытков нет.
На 24/7 порталах конечно сложнее.
Не помню, такого чтобы приходилось откатывать назад базу. Если память не изменяет, то пути отката базы назад не было. Поэтому те версии, которые требовали конверсии, тестировались особо тщательно.
Оставить комментарий
Имя или ник:
Комментарий: