Уязвимость в SVN позволяет получать исходные коды сайтов

http://habrahabr.ru/blogs/infosecurity/70330/

Цитата:

Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды. Казалось бы, что в XXI веке трудно найти подобную уязвимость. Кажется, что уже всё найдено, а то что не найдено, сидит где-то очень очень глубоко. Оказалось, что корнем сегодняшнего зла является вполне повседневная вещь. Наверняка каждый из вас когда-нибудь имел дело с системой контроля версий SVN. SVN является продвинутым средством для организации совместной разработки десятков, а то и сотен разработчиков. В силу особенностей архитектуры, SVN хранит в каждой директории проекта свои метафайлы, аккуратно сложенные в скрытую директорию .svn. В одном из файлов под названием entries находится список всех файлов и директорий, расположенных в той же папке, что и .svn. Так же там находится информация о расположении репозитория, размере файлов, даты их изменения и логины пользователей, работающих над проектом. Уже не плохо, правда? Объясню, получается, если проект разрабатывается с помощью SVN, то заглянув по адресу draftcopy.ru/.svn/entries мы увидим файловую структуру корня проекта с авторами, последними изменениями, ссылкой на основную ветку репозитория итп. Но можно пойти и далее. В той же папке .svn находится директори text-base, в которой лежат последние версии всех файлов, находящихся в репозитории. Картину дополняет так же и то, что файлы имеют не стандартное расширение (например .php), которое позволяет их сразу отправить на интерпретатор, а дополнительное расширение .svn-base, благодаря которому файл отдается запросившему его человеку «как есть», т.е. голый исходный код!

короче проверяйтесь) глянул навскидку пару крупных ресурсов - .svn/entries виден.

угу, пиздец
везде виден, закрываем :)

такче делать то?

ну там описывается вроде.
запретить доступ через вебсервер в эти папки.
а по хорошему вообще удалить их из онлайна.
т.е. не делать svn update прям на сайт, а делать svn export, в этом случае не будет системных .svn папок.

мда

Мля неужели и гуглу так проторкали? ;)
http://www.askdamagex.com/f2/google-removed-me-someone-fucking-me-39756/

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

модеры, может прилепите тему?

Хм. Я ток один нашел. Чекал очеь крупные. даж интересно, кто подвержен то?

ну взять хотя бы мастер

grozny писал:

ну взять хотя бы мастер

Жесть
Но большинство таки пофиксили видимо

а .gov-ов там сколько....эх, для дорвейного дела-то )))

kebzu писал:

такче делать то?

ну например .svn-base в конфиге прописать также как .php
весьма забавно будет выглядеть ;)

уфф, чекнул свои, везде на свн - 404

еще в CVS/Root бывает пароли лежат

в git таже хуйня. Я всегда закрывал доступ к .svn и CVS.

Эх....сколько ещё интересного нас ждёт

Вау, вот смешные люди, никогда бы не подумал, что деплоить на веб можно иначе, нежели svn export... Ежу понятно, что все, что в папке .svn будет видно...
И это не уязвимость, а просто кривые руки, причем очень кривые.

ну почему же, для хотфиксов весьма удобно. Правда .svn надо закрывать, да.

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

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

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

И если проект небольшой, то хотфикс из SVN занимает 15 минут, а вся эта бюрократическая хуйня с бранчами, документированием, выпуском новой версии и полной перезаписью исходников занимает рабочий день.

Для малых проектов хотфиксы самое оно.

Pentarh писал:

И если проект небольшой, то хотфикс из SVN занимает 15 минут, а вся эта бюрократическая хуйня с бранчами, документированием, выпуском новой версии и полной перезаписью исходников занимает рабочий день.

Подожди, это как? Если у тебя есть рабочая версия, то у тебя в svn есть для нее транк, который ты у себя можешь держать отдельно от текущего транка, где ведется основная работа. Если тебе нужно сделать фикс, ты идешь в тот самый транк, фиксишь там, все, что надо, и деплоишь именно этот транк... Займет теже 15 минут. Никаких бранчей и новых версий не нужно...

ну наш ПМ иного мнения.

пс. я бывший девелопер

Toor писал:

Если у тебя есть рабочая версия, то у тебя в svn есть для нее транк, который ты у себя можешь держать отдельно от текущего транка, где ведется основная работа.

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

Вообще странная тема. Свновские каталоги не просто так начинаются с точки, обычно всё что начинается с точки (в том числе htaccess) денается на верхнем уровне.

Из файлов, начинающихся с точки, денай делается только на .ht* в дефолтной конфигурации:

Код:

<FilesMatch "^\.ht"> Order allow,deny Deny from all </FilesMatch>