Цитата(skyboy @ 7.3.2012, 23:58  ) | | то есть, пофиг, наступаем на те же грабли? |
Жёлтая пресса не обошла стороной и IT. Ошибки в коде Github не имеют ничего общего с register_globals.
Вся эта шумиха поднята вокруг реализации паттерна Active Record, которая позволяет создавать и обновлять записи в БД на основе хэша, который чаще всего приходит от пользователя, заполнившего некую форму. При этом есть возможность указывать белый или чёрный список атрибутов модели, которые можно(http://apidock.com/rails/ActiveModel/MassAssignmentSecurity/ClassMethods/attr_accessible) или нельзя(http://apidock.com/rails/ActiveModel/MassAssignmentSecurity/ClassMethods/attr_protected) обновлять таким образом.
Ну или более подробно в Guides: http://guides.rubyonrails.org/security.html#countermeasures
| Цитата(skyboy @ 7.3.2012, 23:58 ) | | потому что мне показалось, что речь про дефолтный механизм, генерящий код. не зависящий от желания сделать |
В цитате идёт речь лишь о том, что один из генераторов кода (scaffold), который используются исключительно для скринкастов, не генерируют attr_accessible или attr_protected, и как следствие появляется некоторое подмножество программистов, которые про них и не слышали.. Во всей этой истории удивляет лишь то, что программисты Github Inc. допустили так много ошибок подобного рода.
| Цитата(skyboy @ 7.3.2012, 23:58 ) | | и да, я ничего не сказал о программистах. |
Как раз зря. Потому что Rails тут винить совершенно не в чем. Данная особенность есть в большинстве современных веб-фреймворков.. Взять к примеру документацию Yii:
| Цитата |
// assume $_POST['Post'] is an array of column values indexed by column names
$post->attributes=$_POST['Post'];
$post->save();
|
и рядышком невзрачная ссылка, по которой написано:
| Цитата |
After a model instance is created, we often need to populate its attributes with the data submitted by end-users.
...
The last statement is called massive assignment which assigns every entry in $_POST['LoginForm'] to the corresponding model attribute.
...
It is crucial to determine which attributes are safe. For example, if we expose the primary key of a table to be safe, then an attacker could get a chance to modify the primary key of the given record and thus tamper the data he is not authorized to.
...
Sometimes, we want to declare an attribute to be safe, even though we do not really have any specific rule for it. An example is an article's content attribute which can take any user input. We can use the special safe rule to achieve this goal:
array('content', 'safe')
For completeness, there is also an unsafe rule which is used to explicitly declare an attribute to be unsafe:
array('permission', 'unsafe')
|
Те же яйца только в профиль, причём даже primary key из коробки не защищен, в Rails хоть id нельзя так присвоить.
Так что про какие 10 лет речь? Документацию Yii наверно не 10 лет назад в последний раз обновляли?
А дальше уже философский вопрос.. должен ли фреймворк "из коробки" защищать программиста от всех возможных ошибок? И если да, то реализуем ли такой фреймворк хотя бы теоретически? |
