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?
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?
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.
Richard L. 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…
On 2/16/06, Richard L. [email protected] wrote:
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
On Thu, 2006-02-16 at 16:24 +0000, Richard L. 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.”
But when the biggest book on the subject codes this way, it could
cause every programmer learning rails to also code this way.
On 2/16/06, Charlie B. [email protected] 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 2/16/06, Richard L. [email protected] wrote:
[email protected]
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
On Thu, Feb 16, 2006 at 11:42:24AM -0500, Nicholas Van W.
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 ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
On Feb 16, 2006, at 8:44 AM, Charlie B. wrote:
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.
On Feb 16, 2006, at 2:15 PM, Pete Y. wrote:
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 M.
“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 Y.
On Feb 16, 2006, at 2:46 PM, Joe wrote:
redirect_to :action => "show", :id => @entry else render_scaffold('edit') endend
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!
–
– Tom M.
On Thu, Feb 16, 2006 at 03:40:55PM -0800, Tom M. 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 ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
On Thu, 2006-02-16 at 15:40 -0800, Tom M. wrote:
if @entry.saveto 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 F. wrote:
On Thu, Feb 16, 2006 at 03:40:55PM -0800, Tom M. 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 M.
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
Tom M. 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
Tom M. wrote:
final_application, secure_as_hell, batteries_included, or
requires_no_additional_effort.
Where can those be downloaded?
Joe
On Feb 16, 2006, at 9:15 PM, Joe wrote:
Tom M. 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?
However, I must admit the ultra safe folks got this one right:
–
– Tom M.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs