I didn''t get a chance to go to this meeting debating WebObjects Vs Rails, but here''s a report about it: http://desperatepundit.com/blog/cremes/technology/2006/02/15/WebObjects-versus-Ruby-On-Rails.html I don''t get what he''s saying, hand coding the model? yeah, you COULD ... but what about script/generate ??? And is that so what he said about security? -- Posted via http://www.ruby-forum.com/.
Nola wrote:> I didn''t get a chance to go to this meeting debating WebObjects Vs > Rails, but here''s a report about it: > > http://desperatepundit.com/blog/cremes/technology/2006/02/15/WebObjects-versus-Ruby-On-Rails.html > > I don''t get what he''s saying, hand coding the model? yeah, you COULD ... > but what about script/generate ??? > > And is that so what he said about security?-- Posted via http://www.ruby-forum.com/.
Nola wrote:> I didn''t get a chance to go to this meeting debating WebObjects Vs > Rails, but here''s a report about it: > > http://desperatepundit.com/blog/cremes/technology/2006/02/15/WebObjects-versus-Ruby-On-Rails.html > > I don''t get what he''s saying, hand coding the model? yeah, you COULD ... > but what about script/generate ??? > > And is that so what he said about security?"Second, when retrieving a list of parameters from a web form Rails returns a hash called ''params.'' This hash, by default, doesn''t do any security validation. So, if someone knew a field name (like "is_admin") they could add that variable to a custom form they create ("form stuffing") and have the Rails app process it without security validation. The result of this form stuffing could be that they receive elevated privileges within the system." Huh? Hardly default insecurity as far as I can see, just that as with anything you can create bad, insecure code in rails if you really try. -- R.Livsey http://livsey.org
On 2/16/06, Richard Livsey <richard@livsey.org> wrote:> "Second, when retrieving a list of parameters from a web form Rails > returns a hash called ''params.'' This hash, by default, doesn''t do any > security validation. So, if someone knew a field name (like "is_admin") > they could add that variable to a custom form they create ("form > stuffing") and have the Rails app process it without security > validation. The result of this form stuffing could be that they receive > elevated privileges within the system." > > Huh? > > Hardly default insecurity as far as I can see, just that as with > anything you can create bad, insecure code in rails if you really try.Exactly. No one who knows what he''s doing is ever going to trust anything the browser sends. Show me a single, properly designed, application that has an "is_admin" field populated by a request parameter. -- James
Richard Livsey wrote:> > "Second, when retrieving a list of parameters from a web form Rails > returns a hash called ''params.'' This hash, by default, doesn''t do any > security validation. So, if someone knew a field name (like "is_admin") > they could add that variable to a custom form they create ("form > stuffing") and have the Rails app process it without security > validation. The result of this form stuffing could be that they receive > elevated privileges within the system." > > Huh? > > Hardly default insecurity as far as I can see, just that as with > anything you can create bad, insecure code in rails if you really try.Exactly... PHP is the same way.. and good PHP developers know not to trust the _GET and _POST arrays... -- Posted via http://www.ruby-forum.com/.
On 2/16/06, Richard Livsey <richard@livsey.org> wrote:> > Nola wrote: > > I didn''t get a chance to go to this meeting debating WebObjects Vs > > Rails, but here''s a report about it: > > > > > http://desperatepundit.com/blog/cremes/technology/2006/02/15/WebObjects-versus-Ruby-On-Rails.html > > > > I don''t get what he''s saying, hand coding the model? yeah, you COULD ... > > but what about script/generate ??? > > > > And is that so what he said about security? > > > "Second, when retrieving a list of parameters from a web form Rails > returns a hash called ''params.'' This hash, by default, doesn''t do any > security validation. So, if someone knew a field name (like "is_admin") > they could add that variable to a custom form they create ("form > stuffing") and have the Rails app process it without security > validation. The result of this form stuffing could be that they receive > elevated privileges within the system." > > Huh? > > Hardly default insecurity as far as I can see, just that as with > anything you can create bad, insecure code in rails if you really try. > > -- > R.Livsey > http://livsey.org > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >This is very insecure, and is an enticing way to code. To protect your code, you would use attr_protected :is_admin to disable this. Or, attr_accessible :other_attribute to take the reverse approach and explicitly state that which can be automaticalyl set from params. It would be nice to have the option of having everything protected by default across an application. Nick -- Nicholas Van Weerdenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060216/0fb02ccf/attachment.html
On Thu, 2006-02-16 at 16:24 +0000, Richard Livsey wrote:> Nola wrote: > > I didn''t get a chance to go to this meeting debating WebObjects Vs > > Rails, but here''s a report about it: > > > > http://desperatepundit.com/blog/cremes/technology/2006/02/15/WebObjects-versus-Ruby-On-Rails.html > > > > I don''t get what he''s saying, hand coding the model? yeah, you COULD ... > > but what about script/generate ??? > > > > And is that so what he said about security? > "Second, when retrieving a list of parameters from a web form Rails > returns a hash called ''params.'' This hash, by default, doesn''t do any > security validation. So, if someone knew a field name (like "is_admin") > they could add that variable to a custom form they create ("form > stuffing") and have the Rails app process it without security > validation. The result of this form stuffing could be that they receive > elevated privileges within the system." >But when the biggest book on the subject codes this way, it could cause every programmer learning rails to also code this way.> Huh? > > Hardly default insecurity as far as I can see, just that as with > anything you can create bad, insecure code in rails if you really try. >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060216/53339372/attachment.html
On 2/16/06, Charlie Bowman <cmbowma@castlebranch.com> wrote:> But when the biggest book on the subject codes this way, it could cause > every programmer learning rails to also code this way.What are you referring to? -- James
On Feb 16, 2006, at 8:44 AM, Charlie Bowman wrote:> On Thu, 2006-02-16 at 16:24 +0000, Richard Livsey wrote: >> > I don''t get what he''s saying, hand coding the model? yeah, you >> COULD ... >> > but what about script/generate ??? >> > >> > And is that so what he said about security? >> "Second, when retrieving a list of parameters from a web form Rails >> returns a hash called ''params.'' This hash, by default, doesn''t do any >> security validation. So, if someone knew a field name (like >> "is_admin") >> they could add that variable to a custom form they create ("form >> stuffing") and have the Rails app process it without security >> validation. The result of this form stuffing could be that they >> receive >> elevated privileges within the system." > But when the biggest book on the subject codes this way, it could > cause every programmer learning rails to also code this way.Since you seem to have the book, it won''t cost you much to read Chapter 21, an section 21.4 specifically. -- -- Tom Mornini -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060216/250f9c6f/attachment.html
Adam Fields
2006-Feb-16 19:08 UTC
Rails and ruby safe modes (was: Re: [Rails] RoR VS Rails ???)
On Thu, Feb 16, 2006 at 11:42:24AM -0500, Nicholas Van Weerdenburg wrote: [...]> It would be nice to have the option of having everything protected by > default across an application.Speaking of which, ruby core supports safe modes, where all data from external sources can be tainted and raises exceptions if you try to pass it to insecure system methods. It seems like a major oversight that rails doesn''t support this. <%= @params.tainted? %> in a view should return true, but it''s false. Am I missing some reason why rails doesn''t use this built-in facility? -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.everylastounce.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki [ http://del.icio.us/fields ] ............. Links
> "Second, when retrieving a list of parameters from a web form Rails > returns a hash called ''params.'' This hash, by default, doesn''t do > any security validation. So, if someone knew a field name (like > "is_admin") they could add that variable to a custom form they > create ("form stuffing") and have the Rails app process it without > security validation. The result of this form stuffing could be that > they receive elevated privileges within the system."So he''s pointing out here that a lot of rails apps do: my_object = MyClass.new(params[:my_object]) which is potentially insecure, whereas they should be doing: my_object = MyClass.new my_object.a = params[:my_object][:a] my_object.b = params[:my_object][:b] or something similar. While I think he''s overstating the issue, there is a good point in here. The second form is very clunky and un-rails-ish. Why isn''t there something along the lines of: my_object = MyClass.new(params[:my_object].fields(:a, :b)) or perhaps: my_object = MyClass.new_from_params(params[:my_object], :a, :b) Cheers, Pete Yandell
On Feb 16, 2006, at 2:15 PM, Pete Yandell wrote:>> "Second, when retrieving a list of parameters from a web form >> Rails returns a hash called ''params.'' This hash, by default, >> doesn''t do any security validation. So, if someone knew a field >> name (like "is_admin") they could add that variable to a custom >> form they create ("form stuffing") and have the Rails app process >> it without security validation. The result of this form stuffing >> could be that they receive elevated privileges within the system." > > So he''s pointing out here that a lot of rails apps do: > > my_object = MyClass.new(params[:my_object])Yes, the right way to do it...> which is potentially insecure, whereas they should be doing: > > my_object = MyClass.new > my_object.a = params[:my_object][:a] > my_object.b = params[:my_object][:b] > > or something similar.Yikes...NO! Read up on attr_accessible and attr_protected. http://ar.rubyonrails.com/classes/ActiveRecord/Base.html#M000270 -- -- Tom Mornini
Yikes.
Also want to mention that scaffold generates code like this:
def update
@entry = Entry.find(params[:id])
@entry.attributes = params[:entry]
if @entry.save
flash[:notice] = "Entry was successfully updated"
redirect_to :action => "show", :id => @entry
else
render_scaffold(''edit'')
end
end
Joe
--
Posted via http://www.ruby-forum.com/.
On Feb 16, 2006, at 2:46 PM, Joe wrote:> Yikes. > > Also want to mention that scaffold generates code like this: > > def update > @entry = Entry.find(params[:id]) > @entry.attributes = params[:entry] > > if @entry.save > flash[:notice] = "Entry was successfully updated" > redirect_to :action => "show", :id => @entry > else > render_scaffold(''edit'') > end > endThere''s nothing wrong with that code. It just needs attr_accessible and attr_protected applied to the model, and it''s perfectly fine. Certainly you''re not suggesting that scaffolding should somehow generate secure code? Security is a bit too high level for anything short of a machine that can pass the Turing test, don''t you think? Hey, Rails core team: I want an app generate that can take five pages of text and produce a, secure, high performance, and artistically appealing application! -- -- Tom Mornini
On Thu, Feb 16, 2006 at 03:40:55PM -0800, Tom Mornini wrote: [...]> Certainly you''re not suggesting that scaffolding should > somehow generate secure code? > > Security is a bit too high level for anything short of > a machine that can pass the Turing test, don''t you think?Certainly you''re not suggesting that the code the scaffolding generates evolved somehow, and was not written originally by people?> Hey, Rails core team: I want an app generate that can > take five pages of text and produce a, secure, high > performance, and artistically appealing application!That may be a bit much to ask. How about my other point about ruby safe modes that no one responded to? This seems like a big deal, no? -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.everylastounce.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki [ http://del.icio.us/fields ] ............. Links
On Thu, 2006-02-16 at 15:40 -0800, Tom Mornini wrote:> On Feb 16, 2006, at 2:46 PM, Joe wrote: > > > Yikes. > > > > Also want to mention that scaffold generates code like this: > > > > def update > > @entry = Entry.find(params[:id]) > > @entry.attributes = params[:entry] > > > > if @entry.save > > flash[:notice] = "Entry was successfully updated" > > redirect_to :action => "show", :id => @entry > > else > > render_scaffold(''edit'') > > end > > end > > There''s nothing wrong with that code. > > It just needs attr_accessible and attr_protected applied > to the model, and it''s perfectly fine. > > Certainly you''re not suggesting that scaffolding should > somehow generate secure code? > > Security is a bit too high level for anything short of > a machine that can pass the Turing test, don''t you think? > > Hey, Rails core team: I want an app generate that can > take five pages of text and produce a, secure, high > performance, and artistically appealing application!---- me too! ;-) sarcasm doesn''t play well on mailing lists. Craig
On Feb 16, 2006, at 3:48 PM, Adam Fields wrote:> On Thu, Feb 16, 2006 at 03:40:55PM -0800, Tom Mornini wrote: > [...] >> Certainly you''re not suggesting that scaffolding should >> somehow generate secure code? >> >> Security is a bit too high level for anything short of >> a machine that can pass the Turing test, don''t you think? > > Certainly you''re not suggesting that the code the scaffolding > generates evolved somehow, and was not written originally by people?No, quite the opposite! Perhaps I misunderstood your point, which I (perhaps mistakenly) implied that the scaffold code was a security problem that needed fixing.>> Hey, Rails core team: I want an app generate that can >> take five pages of text and produce a, secure, high >> performance, and artistically appealing application! > > That may be a bit much to ask. > > How about my other point about ruby safe modes that no one responded > to? This seems like a big deal, no?Sorry, didn''t see that post. Thank God for Spotlight! Pretty cool idea. I''m sure the developers would love a patch. -- -- Tom Mornini
Tom Mornini wrote:> > Certainly you''re not suggesting that scaffolding should > somehow generate secure code?Is that like saying OSX shouldn''t be secure out of the box? Joe -- Posted via http://www.ruby-forum.com/.
On Feb 16, 2006, at 9:15 PM, Joe wrote:> Tom Mornini wrote: > >> Certainly you''re not suggesting that scaffolding should >> somehow generate secure code? > > Is that like saying OSX shouldn''t be secure out of the box?No, but it seems that you''re saying that XCode shouldn''t allow you to write insecure code. OS X out of the box is a user environment. The fact that the initial account (which the vast majority of OS X users use as their primary account) has the ability to write into the /Applications directory is an example of how wrong you are in that assertion, though. Rails, by default, is not an application generator. The scaffold feature was named scaffold for a reason. Notice it''s not called final_application, secure_as_hell, batteries_included, or requires_no_additional_effort. From the Oxford American Dictionary: a temporary structure (snip) used by workers while building (snip) How in the world *might* a feature designed to get a quick scaffold in place be able to guess which DB columns might need to be secured against "form stuffing?" What is it you''re asking for, and what was your point, other than your admittedly interesting suggestion about safe mode? <rant> Whenever people drag on about these subjects, I *always* wonder if they have any sharp tools at their house? Knives, scissors, forks, Skill saws, Chain Saws, etc. are just so damn dangerous! It seems that the safe is better than sorry folks, have someone taken that term to mean "So safe it''s impossible to hurt yourself." However, I must admit the ultra safe folks got this one right: http://www.sawstop.com/ </rant> -- -- Tom Mornini
Tom Mornini wrote:> final_application, secure_as_hell, batteries_included, or > requires_no_additional_effort.Where can those be downloaded? Joe -- Posted via http://www.ruby-forum.com/.
On Thu, Feb 16, 2006 at 10:45:02PM -0800, Tom Mornini wrote:> What is it you''re asking for, and what was your point, other > than your admittedly interesting suggestion about safe mode?Tom - you''re conflating multiple authors. You responded to a message from Joe, but I wrote some of that. Particularly, the observation about ruby safe mode was mine. (Which I''m thinking about, although I''m not terribly familiar with the rails source yet.)> <rant> > Whenever people drag on about these subjects, I *always* wonder > if they have any sharp tools at their house? Knives, scissors, > forks, Skill saws, Chain Saws, etc. are just so damn dangerous! > It seems that the safe is better than sorry folks, have someone > taken that term to mean "So safe it''s impossible to hurt > yourself." > > However, I must admit the ultra safe folks got this one right: > > http://www.sawstop.com/ > </rant>I tend to go for "hopefully it won''t aim directly at your head when you first turn it on". -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.everylastounce.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki [ http://del.icio.us/fields ] ............. Links
Tom Mornini wrote:> On Feb 16, 2006, at 2:15 PM, Pete Yandell wrote: > >> my_object = MyClass.new(params[:my_object]) > Yes, the right way to do it... > >> which is potentially insecure, whereas they should be doing:This is the #1 security hole in Rails applications. I have found several apps where this bug could be exploited to gain admin permissions.>> my_object = MyClass.new >> my_object.a = params[:my_object][:a] >> my_object.b = params[:my_object][:b] >> >> or something similar. > > Yikes...NO! > > Read up on attr_accessible and attr_protected.Deciding what the web form can change in the model is not the responsibility of the model, but of the controller. An administrator might have to edit fields that a normal user is not allowed to edit, etc. Using attr_accessible and attr_protected for this is a violation of the MVC concept. -- Posted via http://www.ruby-forum.com/.