Comments 17
Особенно радует то, что все найденные уязвимости оперативно устраняются.
А обновить проект на RoR — делов-то — bundle update.
Как говорится, не ошибается только тот, кто ничего не делает.
Обнаруживающиеся иногда уязвимости свидетельствуют, как мне кажется, о популярности — ибо постоянно кто-то что-то ищет. В ненужном никому продукте и рыться бы не стали.
А обновить проект на RoR — делов-то — bundle update.
Как говорится, не ошибается только тот, кто ничего не делает.
Обнаруживающиеся иногда уязвимости свидетельствуют, как мне кажется, о популярности — ибо постоянно кто-то что-то ищет. В ненужном никому продукте и рыться бы не стали.
Я думаю, не стоит переходить на позитивную ноту. Проблема ещё в том, что далеко не факт, что все 100% уязвимостей публикуются. Сколько потенциальных бэкдоров есть у тех, кто может их продать при случае?
Возможно, их нет. Возможно, нынешние 5-6 уязвимостей в месяц находятся только честными и порядочными людьми.
Возможно, их нет. Возможно, нынешние 5-6 уязвимостей в месяц находятся только честными и порядочными людьми.
Поддерживаю такую точку зрения. Некоторые уязвимости в Rails затрагивают другие продукты — Redmine, виртуалки на Heroku etc. И эксплуатация уязвимостей для получения доступа к этим продуктам для некоторых может оказаться более выгодным, чем сообщить сообществу о новых дырах.
Да-да, сидит этакий злодей, знает только он о заветной уязвимости, и только ждет своего звездного часа, чтобы ломануть какой-нить Redmine и завладеть Миром! ;-)
Кстати, даже те найденные уязвимости довольно сложно применить на практике на самом-то деле.
Кстати, даже те найденные уязвимости довольно сложно применить на практике на самом-то деле.
Эти, возможно, и сложно применить. Но давайте вспомним предыдущие — с разбором XML или через которую поимели Github. А насчет Redmine — потенциально это получение доступа ко всем проектам, которые хранятся у людей в Redmine. Это же решение, которое ставится на ваш сервер.
Redmine — это вообще проблема. Многие его ставят вовсе не на отдельные сервера. И пользуются им все подряд. И, уверен, для большинства «bundle update» — пустой звук.
Кроме дыр фреймоврка неплохо бы думать вообще о безопасности — запускать сервисы под аккаунтами, которые в принципе не могут причинить вреда (в силу ограничений прав доступа в самой ОС) системе.
Любая разработка может содержать в себе какие-то ошибки. Наиболее правильный ответ в данном контексте — как быстро и качественно эти дыры закрываются разработчиками. Периодически обнаруживаются дыры и в Linux, однако Мир до сих пор не рухнул и не полетел в тар-тарары.
Любая разработка может содержать в себе какие-то ошибки. Наиболее правильный ответ в данном контексте — как быстро и качественно эти дыры закрываются разработчиками. Периодически обнаруживаются дыры и в Linux, однако Мир до сих пор не рухнул и не полетел в тар-тарары.
Чёрный рынок эксплоитов вполне себе существует.
github.com/blog/1440-github-enterprise-email-incident-today а вот пример того, как эти патчи могут вызвать проблемы
Довольно странно, как у них это получилось, но я сейчас провел подобный тест (Rails 3.2.13) — запрос формируется абсолютно правильно.
А там не только это выплыло. Процитирую коллег:
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. «В странных и редких»: например, при запуске тестовой сюиты — падают, при запуске тестовой сюиты поменьше (например, только этих тестов) — проходят. Решение — хз.
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. «В странных и редких»: например, при запуске тестовой сюиты — падают, при запуске тестовой сюиты поменьше (например, только этих тестов) — проходят. Решение — хз.
рассмотрел некоторые проблемы…
порой люди привыкли получать не совсем то, что нужно, наглядный пример с pluck:
In 3.2.12, the generated query looks like
SELECT photos.*, (LOG(…
while in 3.2.13 it looks like
SELECT photos.id FROM «photos»…
но так-то в 3.2.13 это работает более правильно.
Человек заказывает получение одного поля, а ожидает получить все поля… довольно странные ожидания, вам не показалось?
Тем более, обо всех изменениях рассказывается по мере их появления еще до выхода очередной версии:
github.com/rails/rails/blob/3-2-stable/activerecord/CHANGELOG.md
Мне кажется, надо следить за изменениями и все-таки более внимательно относится к тому, что Вы пишите и как оно на самом деле должно быть.
Это похоже на восклицание программиста к программе, долго отлаживающего сложный алгоритм: «Да сделай же ты уже то, что я хочу, а не то, что я пишу тебе сделать!»
порой люди привыкли получать не совсем то, что нужно, наглядный пример с pluck:
In 3.2.12, the generated query looks like
SELECT photos.*, (LOG(…
while in 3.2.13 it looks like
SELECT photos.id FROM «photos»…
но так-то в 3.2.13 это работает более правильно.
Человек заказывает получение одного поля, а ожидает получить все поля… довольно странные ожидания, вам не показалось?
Тем более, обо всех изменениях рассказывается по мере их появления еще до выхода очередной версии:
github.com/rails/rails/blob/3-2-stable/activerecord/CHANGELOG.md
Мне кажется, надо следить за изменениями и все-таки более внимательно относится к тому, что Вы пишите и как оно на самом деле должно быть.
Это похоже на восклицание программиста к программе, долго отлаживающего сложный алгоритм: «Да сделай же ты уже то, что я хочу, а не то, что я пишу тебе сделать!»
как бы то ни было… поправят и это
Вы можете назвать какой-нибудь другой программный продукт схожего назначения, к которому не относится сказанное вами? 0_о
Такова жизнь…
Такова жизнь…
Sign up to leave a comment.
Выпущены Rails 3.2.13, 3.1.12, и 2.3.18: исправление 4х уязвимостей безопасности