да, баян. да, узнал на хабре.
сорс: https://github.com/rails/rails/issues/5228
коротко: RoR имеет проблемы, схожие с PHPшным register_globals
длиннее: по умолчанию атрибуты моделей могут загружать свои значения из переданных пользователем данных(POST). что потенциально является не просто дырой - прям-таки порталом.
резюме: я - паникер, а, если ты - RoR разработчик, почитай подробности и проверь свои сайты

Добавлено @ 02:22
и да, это не уязвимость.
но, черт возьми, почему в РНР соответствующую опция надо включать(читай: подвешивать над головой меч) вручную и самостоятельно ажно с 4.2.0? а в RoR только сейчас зашевелились? где же "возьмем лучшее"?


подумаешь, 10 лет.

Ну во-первых не стоит путать  своство языка и свойстви фреймверка. Кроме того, php импортировал это в переменные в global scope. А для эксплуатации этой "уязвимости" программист сам должен прописать update_attributes(params[...]). В PHP все так-же никто не запрещает писать 

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

то есть, пофиг, наступаем на те же грабли?

я с RoR и с Ruby не знаком. Вообще.
Потому скажи мне, пожалуйста, что значит:

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

Жёлтая пресса не обошла стороной и IT. Ошибки в коде Github не имеют ничего общего с register_globals.
Вся эта шумиха поднята вокруг реализации паттерна Active Record, которая позволяет создавать и обновлять записи в БД на основе хэша, который чаще всего приходит от пользователя, заполнившего некую форму. При этом есть возможность указывать белый или чёрный список атрибутов модели, которые можно(attr_accessible) или нельзя(attr_protected) обновлять таким образом.
Ну или более подробно в Guides: http://guides.rubyonrails.org/security.html#countermeasures


В цитате идёт речь лишь о том, что один из генераторов кода (scaffold), который используются исключительно для скринкастов, не генерируют attr_accessible или attr_protected, и как следствие появляется некоторое подмножество программистов, которые про них и не слышали.. Во всей этой истории удивляет лишь то, что программисты Github Inc. допустили так много ошибок подобного рода.


Как раз зря. Потому что Rails тут винить совершенно не в чем. Данная особенность есть в большинстве современных веб-фреймворков.. Взять к примеру документацию Yii:

и рядышком невзрачная ссылка, по которой написано:

Те же яйца только в профиль, причём даже primary key из коробки не защищен, в Rails хоть id нельзя так присвоить.
Так что про какие 10 лет речь? Документацию Yii наверно не 10 лет назад в последний раз обновляли? 

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

Это сообщение отредактировал(а) source777 - 9.3.2012, 12:12

признаю, был не прав 

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

По ссылке выше есть про опцию config.active_record.whitelist_attributes, если её установить в true, то всё так и будет. Почему она по умолчанию выставлена в false трудно сказать. 
Хотя вероятная причина состоит в том, что далеко не для всех моделей эти списки разрешённых атрибутов необходимы, т.к. в типичном веб-приложении обычному зарегистрированному юзеру доступно на создание/редактирование 2-5 моделей, а за сценой есть ещё несколько десятков моделей, доступ к которым есть только из админки.


Ну в Ruby ты не просто предупреждение, а runtime ошибку "NameError: undefined local variable or method" получишь в данном случае, только какая связь.. 
Тут просто палка о двух концах... С одной стороны можно запретить чистый SQL вызывать, дабы программист не смог SQL-Injection допустить, а с другой - от этого возникнет куча проблем, когда запрос на SQL написать в сто раз проще, чем мучать ORM, а такие случаи неизбежно бывают в нетривиальных приложениях. И над поиском разумного компромисса между защищенностью и гибкостью библиотек по факту бьётся весь IT-мир не первый десяток лет. 


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