Особенно радует то, что все найденные уязвимости оперативно устраняются.
А обновить проект на RoR — делов-то — bundle update.
Как говорится, не ошибается только тот, кто ничего не делает.
Обнаруживающиеся иногда уязвимости свидетельствуют, как мне кажется, о популярности — ибо постоянно кто-то что-то ищет. В ненужном никому продукте и рыться бы не стали.
Я думаю, не стоит переходить на позитивную ноту. Проблема ещё в том, что далеко не факт, что все 100% уязвимостей публикуются. Сколько потенциальных бэкдоров есть у тех, кто может их продать при случае?
Возможно, их нет. Возможно, нынешние 5-6 уязвимостей в месяц находятся только честными и порядочными людьми.
Поддерживаю такую точку зрения. Некоторые уязвимости в Rails затрагивают другие продукты — Redmine, виртуалки на Heroku etc. И эксплуатация уязвимостей для получения доступа к этим продуктам для некоторых может оказаться более выгодным, чем сообщить сообществу о новых дырах.
Да-да, сидит этакий злодей, знает только он о заветной уязвимости, и только ждет своего звездного часа, чтобы ломануть какой-нить Redmine и завладеть Миром! ;-)
Кстати, даже те найденные уязвимости довольно сложно применить на практике на самом-то деле.
Эти, возможно, и сложно применить. Но давайте вспомним предыдущие — с разбором XML или через которую поимели Github. А насчет Redmine — потенциально это получение доступа ко всем проектам, которые хранятся у людей в Redmine. Это же решение, которое ставится на ваш сервер.
Redmine — это вообще проблема. Многие его ставят вовсе не на отдельные сервера. И пользуются им все подряд. И, уверен, для большинства «bundle update» — пустой звук.
Кроме дыр фреймоврка неплохо бы думать вообще о безопасности — запускать сервисы под аккаунтами, которые в принципе не могут причинить вреда (в силу ограничений прав доступа в самой ОС) системе.
Любая разработка может содержать в себе какие-то ошибки. Наиболее правильный ответ в данном контексте — как быстро и качественно эти дыры закрываются разработчиками. Периодически обнаруживаются дыры и в Linux, однако Мир до сих пор не рухнул и не полетел в тар-тарары.
Да-да-да, я периодически наблюдаю картину в логах доступа к сайтам, написанных на RoR, как пытаются использовать php-эксплоиты, видимо, успешно приобретенные на том самом рынке ;-)
1. pluck. pluck теперь теряет select — github.com/rails/rails/issues/9777, что может привести к порче запроса. Возможные решения — valium или select(:field_name).map(&:field_name).
2. client_side_validations. Багфикс в рельсах — github.com/rails/rails/commit/756188b — ломает client_side_validations. Решение — хз.
3. default_scope. Новая фича — default_scope в STI родителе теперь наследуется STI детьми. Будьте бдительны.
4. Наличие default_scope в модели ломает chained scopes. Это полный писец, между прочим. Проявление 1 — gist.github.com/pivotal-chorus/5200366, проявление 2 — github.com/pjungwir/scope-error, тикет в рельсах — github.com/rails/rails/issues/9813. Решение: отказаться от использования default scope в сторону явного named scope или всем миром навалиться, пофиксить и обновиться на нестабильную версию сразу после фиксящего коммита.
5. Гитхабовская утренняя беда со скоупами — github.com/blog/1440-today-s-email-incident. Решение — то же, что и для (4). Похоже, обе проблемы спровоцированы одной и той же причиной — github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23.
6. Коллега сообщает, что в двух проектах в некоторых странных и редких обстоятельствах письма не отправляются с ошибкой sender cannot be blank, recipients cannot be blank. «В странных и редких»: например, при запуске тестовой сюиты — падают, при запуске тестовой сюиты поменьше (например, только этих тестов) — проходят. Решение — хз.
Мне кажется, надо следить за изменениями и все-таки более внимательно относится к тому, что Вы пишите и как оно на самом деле должно быть.
Это похоже на восклицание программиста к программе, долго отлаживающего сложный алгоритм: «Да сделай же ты уже то, что я хочу, а не то, что я пишу тебе сделать!»
Выпущены Rails 3.2.13, 3.1.12, и 2.3.18: исправление 4х уязвимостей безопасности