5 ms·

If it's a simple mass-assignment vulnerability, the Rails team has nothing to do with it given that mass-assignment is a feature and the vulnerability is well d

If it's a simple mass-assignment vulnerability, the Rails team has nothing to do with it given that mass-assignment is a feature and the vulnerability is well documented: http://edgeguides.rubyonrails.org/security.html#mass-assignment http://edgeguides.rubyonrails.org/security.html#mass-assignm... Heck, I even learned this way back when I was learning Rails: http://railscasts.com/episodes/26-hackers-love-mass-assignment http://railscasts.com/episodes/26-hackers-love-mass-assignme...

vidarh 15y ago
The fact that this is even a discussion is sufficient for me to consider it a bug. It's irresponsible of the Rails team to leave this default the way it is given that it's long been a known risk. That they like to consider it a "feature" doesn't make it any better - it just makes them look like idiots
- marshray 15y ago
  I was going to say the same thing. The Security guide does describe the issue, and even describes attr_accessible as a "Countermeasure". http://guides.rubyonrails.org/security.html#mass-assignment http://guides.rubyonrails.org/security.html#mass-assignment Without any precautions Model.new(params[:model]) allows attackers to set any database column’s value. Unbelieveable! PHP showed long ago that allowing a web request to auto-populate arbitrary members in app objects is just a spectacularly bad idea. Even the canonical "Hello Rails" example code neglects to specify attr_accessible. http://guides.rubyonrails.org/getting_started.html#hello-rails http://guides.rubyonrails.org/getting_started.html#hello-rai... The general attitude of Rails developers towards security here is really shocking. I don't think I could recommend anyone use Rails.
  - bryanbibat 15y ago
    Er.. that's because there's nothing malicious an attacker can do with the mass-assignment vulnerability in the "Hello Rails" app? Being able to change the :id or timestamps of the post isn't anywhere near the SQL injection vulnerabilities I've seen in many tutorials in other languages/frameworks. I agree, though, I wouldn't recommend Rails to people who can't bother to read documentation.

vidarh 15y ago

The fact that this is even a discussion is sufficient for me to consider it a bug. It's irresponsible of the Rails team to leave this default the way it is given that it's long been a known risk. That they like to consider it a "feature" doesn't make it any better - it just makes them look like idiots

marshray 15y ago
I was going to say the same thing. The Security guide does describe the issue, and even describes attr_accessible as a "Countermeasure". http://guides.rubyonrails.org/security.html#mass-assignment http://guides.rubyonrails.org/security.html#mass-assignment Without any precautions Model.new(params[:model]) allows attackers to set any database column’s value. Unbelieveable! PHP showed long ago that allowing a web request to auto-populate arbitrary members in app objects is just a spectacularly bad idea. Even the canonical "Hello Rails" example code neglects to specify attr_accessible. http://guides.rubyonrails.org/getting_started.html#hello-rails http://guides.rubyonrails.org/getting_started.html#hello-rai... The general attitude of Rails developers towards security here is really shocking. I don't think I could recommend anyone use Rails.
- bryanbibat 15y ago
  Er.. that's because there's nothing malicious an attacker can do with the mass-assignment vulnerability in the "Hello Rails" app? Being able to change the :id or timestamps of the post isn't anywhere near the SQL injection vulnerabilities I've seen in many tutorials in other languages/frameworks. I agree, though, I wouldn't recommend Rails to people who can't bother to read documentation.