Пару месяцев назад нами (
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, rbc.ru, 003.ru, bolero.ru, habrahabr.ru, итого 19 адресов), затем, сегодняшней ночью, письма получили остальные 3000+ сайтов.
Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах.
Немного статистики:
Просканировано доменов: 2253388
Уязвимых: 3320
Статистики по оповещениям пока нет, возможна она будет опубликована через пару недель. Из крупных порталов, ответили шестеро. Самым оперативным оказался Яндекс, прислав ответное письмо ночью в воскресенье. Десять проектов никак не прореагировали на наши письма, три проекта закрыли уязвимость не поблагодарив.
Мы не злопамятные, мы запишем их имена…
Несколько интересных фактов:
- Киберсквотеры полюбили SVN, как и оптимизаторы;
- Единый CSS для календарей яндекса собирается из десятка CSS средстами $make из консоли 0_0;
- На проектах Рамблера пользуются сервисами Яндекса 0_0, найдены файлы «подтверждения домена» для сервисов Яндекса;
- РБК использует и сервисы яндекса и сервисы гугля и очень любят «сложные» пароли;
- Опера уважает MySQL, но сайт у них на голом html с реальными директориями и поддиректориями;
- Блондинка уважает CodeIgniter;
PostgreSQL уважают движок wikimedia => PostgreSQL уважают MySQL ;-) ошибко ;-(- Все проекты Футурико (и Лепра) написаны на perl.
- Порядка 10 сайтов со словами в домене типа «hack» и «secure» уязвимы;
- Многие уверены, что назвав директорию с phpmyadmin примерно «__xpma123uff__» но сохранив пароль в конфиг, это хорошая защита;
- Многие до сих пор хранят конфиги в inc файлах, без расширения .php, которые открываются как текст в браузере.
Для вас старались
2Товарища (
mobilz) и
Антон Исайкин (
oowl,
twi).
Мы готовы к сотрудничеству ;)
P.S. Во избежании конфликтов все исходные коды, полученные за время исследования были распечатанны и сожжены :-)
P.S.S. Два пункта:
- абсолютно все, кто мог пострадать, получили предупреждения об уязвимости с точной датой обнародования заранее.
- никакие исходные коды ни при каких условиях не будут опубликованы или проданы. Не стоит писать нам по этому поводу.
P.P.P.S. Спасибо за содействие хабрапользователю
oowl.
P.P.P.P.S. Никаких сорцов самого поискового механизма Яндекса получено не было, однако были получены корни веб морды некоторых ресурсов. Верстка, xmlapi, xsl шаблоны итп. Ничего серьезного, разве что все адреса репозиториев, логины разработчиков итп. Кукуц, Бобук, расслабьтесь.
Игорь Сысоев, ведущий системный администратор компании
Рамблер, разработчик известного своей легкостью веб-сервера
nginx ответил на пару наших вопросов:
- Q: Отчего сразу столько известных проектов пренебрегли такой элементарной возможностью утечки?
A: Причин, я думаю, много — кто-то считает, что в .svn лежит всё то же самое, доступное и без .svn. Кто-то, возможно, просто не знал или забыл об .svn.
- Q: Планируется ли внести в nginx возможность глобально перенаправлять URL (до директивы server, чтобы можно было при настройке сразу заблокировать потенциально опасные адреса)?
A: Нет. Я считаю, что глобальные настройки в конечном итоге приводят к конфигурации, которую с каждым разом всё сложнее сопровождать.
комментарии (898)
Новость года, однозначно.
www.scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/
www.sitepoint.com/blogs/2006/02/07/using-svn-for-web-development/
М.А.Булгаков, «Мастер и Маргарита»
> Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru.
Они сканировали только зону .RU, а есть еще .COM, .NET, .ORG и больше сотни национальных TLD…
Таким образом, VSS — это VCS.
apache.org/.svn/entries
p.s. И вообще, я думаю опенсурсу к взломам не привыкать, в открытых движках постоянно находят уязвимости
p.p.s И вообще, ломать опенсоурс сайты или вредить их деятельности — бесчеловечно и низко, я считаю.
И кстати, с чего вы взяли что крупные сайты делаются квалифицированными разработчиками? Может clssmates индусы делают (это к слову о 10-долларовых сайтах, не надо понимать что он и в самом деле столько стоит)?
Скажите, а чем вообще занимаются квалифицированные разработчики?
А если ближе к теме — интерфейс одноклассников квалифицировнный разработчик бы не придумал (ну или не смог бы выносить, если его придумали до него). И дыру с svn бы не оставил.
У меня столько в морозилке держит, -18.
Причем исходники сливаются очень красиво, не надо писать никаких парсеров:
git clone example.com/.git/
К счастью, в большинстве случаев корень репа, а значит и папка .git закрыты извне.
ПС: Кто-нибудь, переведите эту статью на английский!
1. Если репозитарий на продакшн сервере. Из корня репозитария:
git checkout-index -a -f --prefix=<destination e.g. /var/www>
2. Если репозитарий на удаленном сервере. Из корня вебсервера:
git-archive --format=tar --remote=ssh://:/<repo_path> master | tar -xf -
bolzamo.org.ru/82/
А расположение же настроек вне корня сайтов… Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта. Скорее всего такой разработчик будет сначала трижды проклят, а потом уже, возможно, понят.
Некоторые разработчики суеверны, и не любят, когда их проклинают.
> Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта.
Можно напистаь установщик, кроме того нормальныен сайты устанавливает разработчик а не заказчик.
Но насчет последовательности — улыбнуло, плюсанул :)
Галактеко опасносте!
*Поставил наблюдение за тостером. Кто их занет
А вообще — да, болезнь на удивление детская.
Это дыра из серии, «положу install.php в корень, никто же не знает что он тут лежит». Детский сад, ей богу.
Раскрытие исходных кодов не должно приводить к уязвимостям.
это просто тупо лень и низкая квалификация. Эта новость скорее повергла меня в гнев и обида за тех разработчиков, которые не поняли очевидного «левак в паблике, да ещё и не собственноручно генерируемый — потенциальная опасность в любом случае». И не важно какой это левак. .svn это канеш совсем верх совершенства, но даже .htaccess это УЖЕ идиотизм. И это не паранойа, это совсем другой подход «программа — слева, код — справа».
Вот это действительно лень… притом, в мне известных случаях, программистов…
Или отложили действия на время прихода музы подобных действий…
Но тем не менее страшно интересно:
1. чем все закончится с гигантами.
2. ещё десяток интересных фактов о сайтах.
3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn
там просто не работали по SVN, либо уже были защищены.
2. Возможно будет апдейт или новый пост, как наберем достаточно интересного.
3. Под раздачу попали крупные сайты именно потому что в них ведется командная разработка. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.
habrahabr.ru/blogs/infosecurity/70330/#comment_2010652
Медленно, но верно?
тоже хочу это!
Разрабатываться то они могли и с SVN, вот только разработчки отбкатав тесты, не поленились сделать экспорт на «боевой» сервер, а не разрабатывать на нём.
2) не представляю, как узнать домен, на котором у Яндекса репозиторий
Пошёл закрывать дыру на своих сайтах :)
Структура не позволяет (в паблике токо рисунки и джаваскрипты)
За уязвимостью я предполагал, что можно вытаскивать скрипты.
А юзеров и репозиторий узнать — это конечно плохо…
Также экспорт всей папки с проектом невозможен по причине того, что в папке могут быть неверсионированные файлы, например сессии. Одной командой обновить проект не получиться, придется писать скрипт экспорта — а это лишние телодвижения и лишние проблемы.
Вставить в конфиг апача настройку для закрытости папки .svn намного проще и лучше будет.
Я серьезно, было бы интересно, чем экспорт удобнее рабочей копии, я свои привел в пользу рабочей копии — она гораздо более информативна и управляема.
Никаких «svn up (до любой ревизии), svn revert, svn merge» в production быть не должно, это всё должно делать в другом месте, а на рабочую копию исходников должен отражаться только проверенный (протестированный) результат всех этих действий.
Если вы копаетесь в коде прямо на production-сервере, то я право не знаю, что тут можно сказать.
А скрипт писать надо все равно, потому что перед обновлением исходников сайт должен быть закрыт заставкой, а после обновления — открыт.
current
system (лежат папки с именем timestamp, вовнутрь которых делается как раз export. Задеплоили — симлинк current указал на последний снапшот.)
shared (some user data, logs, temp, ...)
И капистрано уже делает revert и много чего другого. Конечная цель — на сервер руками перестаешь лазить.
ЗЫ: к минусующим не отношусь.
Кто сказал, что я лезу на сервак и там делаю руками svn up? Это не так, все делает скрипт через панельку деплоя. При этом в панельке можно посмотреть результаты обновления (svn diff боевой раб копии проекта с интересующей ревизией) перед обновлением, результаты собстно самого процесса обновления — этого без раб копии не посмотришь.
По поводу отделения обновляемых данных от необновляемых — у меня в раб. копии при ее создании прописывается игнор на неверсионированные папки — аналогия вашему разделению shared/system.
Ну и все-таки имеется специфика, такая, что на сервер руками все же лазят править, хотя я с этим борюсь и это неправильно, но т.к. все-таки это делают, я предпочитаю видеть измененными те файлы, которые изменили на боевом, кстати при svn up эти локальные правки не теряются.
>Если лежит раб. копия, то видно, какие в ней версии файлов
я и так знаю что за ревизия у меня выкачена на боевой
>какие локальные правки
боже упаси. Зоопарк такой уже проходили, наигрались, увольте.
>svn up (до любой ревизии), svn revert, svn merge.
cap deploy [-s revision=N], cap deploy:rollback…
>в папке могут быть неверсионированные файлы, например сессии.
Опять-таки, все подобное храним вне дерева исходников. Всем от этого жить проще. Пример на пальцах: есть dev-версия и production, и периодически надо вливать живые данные в dev. БД я синхронизирую, а папки от production банально копирую в dev. А так пришлось бы куски выискивать по всему дереву.
>Одной командой обновить проект не получится, придется писать скрипт экспорта
Это делается аж единожды для проекта (а дальше копипастит в другие). Кроме того, скрипт экспорта включает в себя лишь создание правильных ссылок, остальное — на автопилоте (в самом Capistrano уже много чего написано).
Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.
Только я пока остаюсь при своем мнении, т.к. у меня те же цели, что и у вас достигаются проще (без доп. софта и других телодвижений). Единственное, что требуется — понимание работы свн.
И я тоже не говорю, что мой подход суперпупер правильный, но я против тех, кто говорит что раб. копии не место на боевом.
Папки .svn светятся?
Так прикройте их апачем и снаружи не будет никакой разницы между экспортом и раб. копией. Мы свои .svn в корневом конфиге апача закрыли сразу, как перешли к раб. копиям (сначала, кстати экспорт использовали со скриптами).
Мне кажется, что ваш методе действительно хорош. Я пару месяцев, после прочтения github.com/blog/470-deployment-script-spring-cleaning, планирую всё таки использовать готовые скрипты автоматизации деплоя.
Пока использую .deb пакеты (собранные на офисном сервере), и делаю apt-get update && apt-get upgrade на каждом сервере ручками.
Раньше использовал rsync исходников с офисной машины (с локальной машины скрипт заходил на офисный сервер, делали git checkout нужной версии, а потом с боевой машины делался rsync на дерево исходников, использовали ssh-forwarding и на продакшене не хранили данные о офисной машине)
А не опишете процесс создания своего apt-репо и сборку деб-пакетов (с нуля) блогпостом? ;) Я пришел к необходимости создания своего репо с nginx, чтоб все сервера апдейтить как-раз не руками.
Для деплоймента конфигов — Puppet, но не проникся как-то.
Была еще тулза аналогичная владу на питоне — простая довольно. Но я не питонист, увы.
Основная причина выбора именно Capistrano — я программлю на Ruby & Rails. А таски для Capistrano пишутся именно на руби. Убив день-два на то чтоб сним основательно разобраться и поэкспериментировать понимаешь, что этой штуковиной можно сделать все.
По поводу дебиановского репозитория — я не спец в нём и сделал достаточно просто и быстро, без всяких заморочек (создание простого пакета, создание репозитория, выливка пакетов по rsync в репозиторий и обновление его структуры). Из всех функций deb-ов я использовал едва ли 5% (к примеру не использовал цифровую подпись пакетов и при апдейне надо указывать --force-yes).
Если такая информация будет интересна — могу попробовать описать блогпостом. Стоит писать?
У них же всегда тестовый(-е) сервер(-а) есть.
Зачем при этом держать всё дерево на основных серверах — решительно непонятно. Ведь даже если не задумываться о безопасности (что очень сомнительно), есть же ещё и такая вещь, как захламление сервера ненужными файлами.
Есть мнение, что работать от этого быстрее система не будет.
Всегда пользовали export и не парили себе мозг.
поэтому обновление производится в часы «пик-аута» (короче, ночью-утром).
И замедление системы один раз в неделю (условно говоря) лучше, чем небольшое замедление системы постоянно.
к тому же, никаких проблем с файлами, которые срочно пришлось поправить на сервере (ну бывает такое иногда, хотя это нехорошо).
экспорт в соседнюю папку и затем замена ей папки с проектом.
у нас в проекте дольше всегл переназначались владельцы файлов, так что это было непринципиально.
Это и будет основной проблемой при «обновления проэкта из тысяч файлов» (авторский синтаксис;))
Ещё в FileZilla есть настройка — игнорировать директории .svn при заливке.
Давно написал для простого экспорта от ревизии до ревизии скрипт. Жизнь облегчает неимоверно!
Делюсь:
webiteam.ru/2009/03/eksport-iz-svn/
Первое запускает второе, второе — третье и т.д. Лучше же один скрипт
Если кто-то решит всерьез судиться — они своего добьются. Надежда на этику.
Но все равно, если 80й порт открыт и на нем стоит web-сервер отображающий изначально публичный сайт, то либо уж признавать что любые действия без использования эксплойтов и уязвимостей в программных продуктах не могут быть предметом преследования, либо каждый раз загружая логотип яндекса судорожно размышлять «а вдруг я сейчас несанкционированно его получаю!».
Хотя может это действительно уже больше к этике и здравому смыслу относитя.
К примеру существующая уязвимость в сервере контроля периметра небольшой компании не должна содержать на себе баннер «Посторонним вход воспрещен» для того, чтобы осудить проникнувшего в сеть. Да, информация не защищена должным образом, нет это не является безнаказанным.
Тут дело в этике. Негласно принято, что исследователи делают доброе дело и сообщают о проблемах из лучших побуждений и не следует на них идти с вилами. До тех пор пока все следуют этике и морали — все хорошо, но если кто-то решит пойти против, могут быть неприятности.
Сделать дело можно на любого.
Качество кода не знаю, но задача решена хорошо потому что
а) все работает быстро. Значит код как минимум хорошо масштабируется (не все можно смасштабировать просто поставив доп. сервер и скопировав на него код с первого и пустив в режиме round-robbing
б) хороший поиск. Есть синтаксический анализатор (который как минимум разные варианты имени подбирает), поиск частично сам определяет что конкретно мы ищем даже без конкретного указания. Ну и какие-то другие плюшки, давно не заходил на сайт, уже не помню. Скорость тоже на высоте.
в) работает без глюков. Иногда конечно встречаются недоработки, но на таких масштабах это неудивительно. Значит что код хорошо тестируется и, видимо, не только живыми тестерами.
г) По проекту видно, что высокая скорость работы обеспечивается не только серверной массой, но и оптимизациями. Наверняка используются нереляционные базы в дополнение к реляционным, наверняка есть отслеживание скорости работы этих баз. Не могу судить, просто некоторые изменения что происходят в проекте мне кажутся оптимизирующими шагами.
Ну итд. Проект работает хорошо не смотря на колоссальные нагрузки и огромное количество пользователей.
А теперь скажите, с чего вы взяли что код там плохой? Ну то что сеть не нравится, это понятно, мне тоже, но ругать техническую реализацию мне не позволяет совесть…
Если бы вконтакте тормозил, то об этом бы на каждом углу кричали, сайт то очень популярный. И со временем начали бы пользователей терять. Не помню название сети, но топовая в Штатах сеть в свое время и слила юзеров Майспейсу отчасти из-за того, что перестала справляться с нагрузкой и начала тормозить.
Если у 0.01% юзеров наблюдаются какие-то проблемы, это не говорит о том, что код плохой. Может какой-то сервер оказался перегружен, а админы не заметили…
> Не помню название сети, но топовая в Штатах сеть
Вы, наверное, про facebook.
И периодически встречал баги «от забывчивости» — типа того, что в мобильной версии на главной странице вместо названия кнопки вылезает какое-нибудь дефолтное имя шаблона.
Надеюсь полученной статистикой распорядитесь не менее грамотно: ) Ждем, ждём: )
А написать что типа пофиксили и не предоставить пруф линк — вполне вероятно. Ну а структуру папок нарисовать — две минуты.
Вот на виртуальных хостингах достаточно ограничений и там надо предусматривать такую «багу» и защищаться, а когда есть свой сервер, то такое можно сделать только осознанно…
Как будто что-то нужное сказал.
Это гораздо проще чем настраивать все что написано в статье.
p.s. в своих проектах в document_root только index.php, даже статика выше корня. Спасибо nginx`у!
Щас глянул, у меня по всем проектам раскиданы папочки .svn, но всё лежит за пределами паблика.
Скажет, что в Гугле все еще хуже и что Гугль ему не нравится…
Столько раз хотелось ткнуть его носом и в их почту и в их «народ»… Но потом понимаю — это бесполезно.
Вот Бобука слышал, и, пожалуй, не согласен во многом, что касается «какие мы хорошие и какие они плохие». Но я могу понять, про конкурентов всегда так — либо плохо, либо ничего. :)
А слушать его интересно. Без него шоу было бы тусклым.
Здесь просто скажу, что с удовольствием пользуюсь всем тем, что касается поиска. Для меня он привлекательнее. Но вот с почтой когда-то были проблемы — поэтому перешел на мэйл и гмэйл и ни разу не пожалел об этом. И бобуковские наезды выглядят немного странными :) Ну на Радио-Т есть кому его притормаживать. А за возможность высказать пожелания лично — спасибо :)
via twitter
Рисково. Накопай бы я что-то эдакое, сидел молчал бы.
Если бы просто нашли, не читали, но сообщили — благое дело.
Из этого текста я понял, что уязвимость они обнаружили сами. Плюс за это говорит и то, что в таких больших проектах, как Яндекс, она не закрыта, а там далеко не лохи сидят. ;)
Есть пруфлинк, что уязвимость старая?
и это не фейк. нашел один русский поисковик, зашел по нему в .svn/entries и чуть не ослеп.
Кстати, отблагодарили.
Он понимает, что во многих местах mod_rewrite подсовывает что-то, что никак не фалы с .svn/?
Или Вы в итоге обрабатывали его результаты вручную?
Поищите еще служебные файлы CVS. Её тоже многие используют :)
И таки да, вмест совета админам закрывать доступ к файлам на уровне вебсервера, лучше рекомендовать не пускать программистов в DocumentRoot, а писать для них инсталятор. Который и файлы лишние уберет и права правильные поставит.
Это как доказывать, мол «пиратством» не занимаюсь, потому что на торрентах лежит в открытом доступе. Если что-то сейчас случится с этими кодами, то шишки посыпятся на тех, кто первый о них открыто заговорил.
Будем надеяться, что всё обойдется :)
digg.com/security/Source_Code_of_3300_Internet_Projects_Were_Got_Through_svn
Senior Mobile Software Developer 95 000 USD / month
Coder 30 000 USD / month
Webmaster s / n Contract
Sales Manager (all regions) s / n Contract
Programmer PHP / JS s / n Contract
Freelancer-joomler. Novosibirsk s / n Contract
PHP Programmer 50 000 USD / month
А я то, наивный, за рубли работал!
А про Яндекс то вроде как неправда.
Еще одно подтверждение о пользе хранения исходников вне public_html, рельсы, джанги и Git рулят :)
Bazaar отдаёт только по ssh, никаких http. Если конечно не ставить специально веб-интерфейс.
Для того, чтобы выливать сырцы на сайт, есть svn export. Это же ясно как божий день. Как можно додуматься лить в веб исходники со скрытыми каталогами .svn? Небось еще и скрытые файлы IDE (такие как .project) туда же попадают…
Есть своя прелесть, когда проект находится под контролем версий и его можно обновить до любой ревизии в течении пары секунд.
Для обновления пишутся скрипты, которые закрывают сайт, потом экспортят код, делают какие-то действия если надо, а потом открывают сайт.
Мне еще интересно, что вы будете делать, если посреди «живого» апдейта упадет связь с SVN-сервером?
Но, на моей практике у меня ещё ни разу svn не давал сбой при апдейте. Тут важнее второй вопрос… Что вы будете делать, если деплоймент скрипт будет написан с ошибкой и во время обновления он внезапно отвалится :)
И в том и в другом случае есть схоластические данные, которые сравнивать просто нереально.
Да, вы намного удобнее используйте способ для обновления своих проектов, и, вероятно, умнее меня и многих других ребят, про которых написан этот пост, но не стоит строить из этого целую драму.
Я бы выбрал репутацию. :)
Работа бывает не только в офисе :) И не только в Москве :)
Вопрос к авторам статьи кстати касательно рунета. Вы скан зоны .su делали?
уязвимы 389
RewriteEngine on
RewriteRule .*\.svn/.* — [F]
для nginx:
location ~ /\.svn {
deny all;
}
RewriteEngine On
RewriteRule ^\. — [F] # От файлов начинающихся с точки
RewriteRule ~$ — [F] # От бэкапов vim
RedirectMatch 404 /\.svn(/|$)
Если говорить про сам проект, то хранить пароль в файле придётся.
Если доступ к базе есть только из локальной сети, а запустить чужой скрипт на серверах не даст система безопасности — не вижу никакой проблемы.
А если речь именно о пхпмайадмин — пароль в файлике хранить конечно не надо)
И разрешить доступ к нему только с доверенных айпи.
я сказал лишь, что если получен доступ к сайту для записи — это уже до чрезвычайности плохо.
а встречный вопрос — вы где предлагаете хранить пароль к базе? в базе? в другой базе? в мемкеше? на листочке записать?)
а так — файл за пределами паблика + жесткое ограничение по ip/подсети для таргетного логина. Лучше и не придумать =).
Пруфа маловато :)
По мелочам — возможно, да)
Спасибо большое.
А то в последнее время — одни топики ссылки, жалобы на продавцов и всякая подобная дребедень.
Давайте еще интересных фактов! Жду с нетерпением :)
«It's working on MAJOR .com sites right now!»
Чувствую, что-то грядет…
Есть подозрение, что про указанные Рамблер, Яндекс и иже с ними тоже инфа не совсем правдивая.
И, кстати, да: Как Вы себе представляете использование кода Миранды (Чистый C) в проекте под Симбиан (Стогое ООП)? Я хоть и не являюсь фанатом этой компании, но все же склонен верить людям, имеющим непосредственное отношение к разработке агента, которых я узнал задолго до появления их симбиан-клиента.
Лично я себе это представляю легко.
Все гениальное, как обычно просто :) Браво!
В крупных проектах, оказывается, народ совсем обленился.
Программер должен программировать, а не искать и испровлять уязвимости стороних приложений.
Действительно, при чем тут он? Скрипты же работают, сайт стоит. Хотя… если это он настраивал svn — думать надо прежде :) Да и не виноват он. Сам, наверное, в шоке сидит, за голову держится…
Не бейте его.
много интересного
Начинается…
В познавательных целях.
яндекс со своим xml достал ;(
Так что люди пользуйтесь правильным FTP менеджером.
Не закрыли. :(
www.bolero.ru/.svn/text-base/phpinfffo.php.svn-base
да отличный способ скрыть phpinfo добавив буквы ff :)
location ~ ^/\.svn/.+$ {
deny all;
}
url.access-deny = ( "~", ".inc", ".svn" )
url.access-deny = ( "~", ".inc", ".svn", «entries», «all-wcprops», «dir-prop-base», «format»,".svn-base",".svn-work" )
а для вресий 1.5
$PHYSICAL[«path»] !~ "^/\.svn" {
access.deny-all = «enable»
}
403 Forbidden
Итог — не используйте svn update для продакшна, используйте svn export.
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php
А вот так не судьба?
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
И ждаь ли нам яндекс-подобных, мэйл-подобных ресурсов в ближайшем будущем?)
Статью прочел, но… надежда-то все равно осталась, что «не все сгорело в пожаре»)
Дайте ссылку скачать исходники.
в принципе если кто получил исходники и сам их юзает а другим не дает, только шуму поднял
А вот то что другие молчали ранее, это уже не наши проблемы =)
Однако простым языком, это дырка в SVN.