Forum: Ruby on Rails RoR VS Rails ???

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7252adadcb6c9e824375c8deaf7174ae?d=identicon&s=25 Nola (Guest)
on 2006-02-16 15:30
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/...

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?
7252adadcb6c9e824375c8deaf7174ae?d=identicon&s=25 Nola (Guest)
on 2006-02-16 15:44
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/...
>
> 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?
C004d67820a114e24ccf6f2ddaf5b236?d=identicon&s=25 Richard Livsey (Guest)
on 2006-02-16 17:23
(Received via mailing list)
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/...
>
> 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.
7252adadcb6c9e824375c8deaf7174ae?d=identicon&s=25 Nola (Guest)
on 2006-02-16 17:35
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...
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-16 17:38
(Received via mailing list)
On 2/16/06, Richard Livsey <richard@livsey.org> 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
4e1cda7ca71ce8ae801331a30c319257?d=identicon&s=25 Charlie Bowman (Guest)
on 2006-02-16 17:50
(Received via mailing list)
On Thu, 2006-02-16 at 16:24 +0000, 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."
>

    But when the biggest book on the subject codes this way, it could
cause every programmer learning rails to also code this way.
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-16 17:53
(Received via mailing list)
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
902654bac6dff9567f018bd2ed933151?d=identicon&s=25 Nicholas Van Weerdenburg (Guest)
on 2006-02-16 18:29
(Received via mailing list)
On 2/16/06, Richard Livsey <richard@livsey.org> wrote:
> >
>
> 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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-16 18:32
(Received via mailing list)
On Feb 16, 2006, at 8:44 AM, Charlie Bowman 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.
912436ffe7c27e25658a3f5f556a8c96?d=identicon&s=25 Adam Fields (Guest)
on 2006-02-16 20:09
(Received via mailing list)
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
C9c7a65848f13e2b1a226bbe43bc3672?d=identicon&s=25 Pete Yandell (pete)
on 2006-02-16 23:29
(Received via mailing list)
> "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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-16 23:41
(Received via mailing list)
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:
>
> 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/Bas...

--
-- Tom Mornini
429500a5a54600958c9c7ac032a37f66?d=identicon&s=25 Joe (Guest)
on 2006-02-16 23:46
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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-17 00:44
(Received via mailing list)
On Feb 16, 2006, at 2:46 PM, Joe wrote:

>        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!

--
-- Tom Mornini
912436ffe7c27e25658a3f5f556a8c96?d=identicon&s=25 Adam Fields (Guest)
on 2006-02-17 00:51
(Received via mailing list)
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
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-02-17 01:00
(Received via mailing list)
On Thu, 2006-02-16 at 15:40 -0800, Tom Mornini wrote:
> >      if @entry.save
> 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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-17 01:03
(Received via mailing list)
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
429500a5a54600958c9c7ac032a37f66?d=identicon&s=25 Joe (Guest)
on 2006-02-17 06:15
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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-17 07:46
(Received via mailing list)
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
429500a5a54600958c9c7ac032a37f66?d=identicon&s=25 Joe (Guest)
on 2006-02-17 09:53
Tom Mornini wrote:
> final_application, secure_as_hell, batteries_included, or
> requires_no_additional_effort.

Where can those be downloaded?

Joe
912436ffe7c27e25658a3f5f556a8c96?d=identicon&s=25 Adam Fields (Guest)
on 2006-02-17 16:14
(Received via mailing list)
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.)

>   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
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2006-03-03 22:48
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.
This topic is locked and can not be replied to.