Comments on: Quick Note on Ruby on Rails Security http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/ Ruby, Ruby on Rails, Los Angeles, Technology, Geek, Science, Life Thu, 28 Aug 2008 12:29:26 +0000 http://wordpress.org/?v=2.5.1 By: Anthony Etti... http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-19306 Anthony Etti... Mon, 28 Jan 2008 21:51:31 +0000 http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-19306 Good example...I have all my writeable stuff behind an admin interface, but good to know that publicly writable areas will need to be whitelisted before going to the db. Good example…I have all my writeable stuff behind an admin interface, but good to know that publicly writable areas will need to be whitelisted before going to the db.

]]> By: Vysnu »... http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16577 Vysnu »... Wed, 05 Dec 2007 00:36:27 +0000 http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16577 [...] Daniel Fischer - Got Fisch? » Quick Note on Ruby on Rails Security (tags: programming rails ruby rubyonrails) [...] [...] Daniel Fischer - Got Fisch? » Quick Note on Ruby on Rails Security (tags: programming rails ruby rubyonrails) [...]

]]> By: Daniel Fisch... http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16574 Daniel Fisch... Wed, 05 Dec 2007 00:25:35 +0000 http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16574 Thanks for pointing that out, I just corrected it. I completely agree with everything you said! Thanks for pointing that out, I just corrected it.

I completely agree with everything you said!

]]> By: Dan Kubb http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16542 Dan Kubb Tue, 04 Dec 2007 09:30:18 +0000 http://www.danielfischer.com/2007/12/01/quick-note-on-ruby-on-rails-security/#comment-16542 I think you've got the terms reversed, attr_accessible is Whitelisting, while attr_protected is Blacklisting. I believe the attr_accessible is the more secure and safer approach. You make a decision about what you allow to be set, and protect everything else by default.. the classic firewall approach. Even still attr_accessible is only the first line of defense. Liberal usage of the validates_* methods should be used to specify constraints for each attribute as well. I generally start by making the DB columns as restrictive as the underlying DB engine allows in terms of length/precision/type, etc, while still allowing for expected data. Then I match the validates_* methods to each column's constraints. Finally I top it off with domain specific constraints; this part really is the key.. and the hardest part to get right. I think you’ve got the terms reversed, attr_accessible is Whitelisting, while attr_protected is Blacklisting.

I believe the attr_accessible is the more secure and safer approach. You make a decision about what you allow to be set, and protect everything else by default.. the classic firewall approach.

Even still attr_accessible is only the first line of defense. Liberal usage of the validates_* methods should be used to specify constraints for each attribute as well. I generally start by making the DB columns as restrictive as the underlying DB engine allows in terms of length/precision/type, etc, while still allowing for expected data. Then I match the validates_* methods to each column’s constraints. Finally I top it off with domain specific constraints; this part really is the key.. and the hardest part to get right.

]]>