Re: limiting what fields can be saved

2006-07-07 Thread Samuel DeVore
I belive that model::save takes a third parameter of fields to savehttp://api.cakephp.org/class_model.html#ef348bd6a62f8196fe42b2cebafc945f
Sam DOn 7/6/06, Felix Geisendörfer [EMAIL PROTECTED] wrote:



  
  


Hey Chris,

I think you've got a good point there. One solution I could think of is
to do something like this:

class PostsController extends AppController
{
 var $name = 'Posts';
 
 function update()
 {
 $post = $this-__limitFields($this-data['Post'],
array('text', 'title'));
 }
 
 function __limitFields($fields, $allowed_fields)
 {
 foreach ($fields as $field = $val)
 {
 if (!in_array($field, $allowed_fields))
 {
 unset($fields[$field]);
 }
 }
 
 return $fields;
 }
}

(didn't actually try it out, but I think you get the idea.).

But still, this could leave some holes in older apps if they store
critical data in tables that can be modified like this.

Best Regards,
Felix Geisendörfer

--
http://www.thinkingphp.org
http://www.fg-webdesign.de



Chris Renner schrieb:

  It just occurred to me that I've left a serious security hole in my recent cake apps. By blindly using $this-params['data'] in my save, I'm leaving a hole for users to change whatever fields they want to. I 
want to remind people about the potential for this, and see if the group has a more elegant way of solving it.Say for example I have a User model. Users need to be able to update their email address, etc., but I don't want them changing, say, the 
security_level field. So far, I've just used an edit form that contained inputs for email address, etc. but not for security_level. But (having just done it), it's easy for an html-savvy user to add an input name=data[User][security_level] / and change it along with 
the rest of the data. Because my controller simply contains $this-User-save($this-params['data']) any field that's present in the form will be saved, including security_level.Now, this fix for this can be easy: in my action, unset those fields I 
don't want to be writable. But it seems like there must be better way to do it... based on user roles in the before_filter perhaps? Or even in the model? What's the philosophy here? Should controllers have 
unfettered access to all fields of a model, or should access be limited from the model?  









--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake PHP group.  To post to this group, send email to cake-php@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/cake-php  -~--~~~~--~~--~--~---


Re: limiting what fields can be saved

2006-07-07 Thread Felix Geisendörfer




Ahh you are right, it does take such a parameter. Hmm I'm beginning to
wonder why I've got this
great CakeSheet laying next to me if I don't actually look at it : p.

--
http://www.thinkingphp.org
http://www.fg-webdesign.de



Samuel DeVore schrieb:
I belive that model::save takes a third parameter of
fields to save
  
  http://api.cakephp.org/class_model.html#ef348bd6a62f8196fe42b2cebafc945f
  
  
Sam D
  
  On 7/6/06, Felix
Geisendrfer [EMAIL PROTECTED]
wrote:
  

Hey Chris,

I think you've got a good point there. One solution I could think of is
to do something like this:

class PostsController extends AppController
{
 var $name = 'Posts';
 
 function update()
 {
 $post = $this-__limitFields($this-data['Post'],
array('text', 'title'));
 }
 
 function __limitFields($fields, $allowed_fields)
 {
 foreach ($fields as $field = $val)
 {
 if (!in_array($field, $allowed_fields))
 {
 unset($fields[$field]);
 }
 }
 
 return $fields;
 }
}

(didn't actually try it out, but I think you get the idea.).

But still, this could leave some holes in older apps if they store
critical data in tables that can be modified like this.

Best Regards,
Felix Geisendrfer

--
http://www.thinkingphp.org
http://www.fg-webdesign.de



Chris Renner schrieb:



  It just occurred to me that I've left a serious security hole in my 
recent cake apps. By blindly using $this-params['data'] in my save, 
I'm leaving a hole for users to change whatever fields they want to. I 

want to remind people about the potential for this, and see if the 
group has a more elegant way of solving it.

Say for example I have a User model. Users need to be able to update 
their email address, etc., but I don't want them changing, say, the 

security_level field. So far, I've just used an edit form that 
contained inputs for email address, etc. but not for security_level. 
But (having just done it), it's easy for an html-savvy user to add an 
input name="data[User][security_level]" / and change it along with 

the rest of the data. Because my controller simply contains 
$this-User-save($this-params['data']) any field that's present in 
the form will be saved, including security_level.

Now, this fix for this can be easy: in my action, unset those fields I 

don't want to be writable. But it seems like there must be better way 
to do it... based on user roles in the before_filter perhaps? Or even 
in the model? What's the philosophy here? Should controllers have 

unfettered access to all fields of a model, or should access be limited 
from the model?




  






  
  
  
  
  


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake PHP group.  To post to this group, send email to cake-php@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/cake-php  -~--~~~~--~~--~--~---





Re: limiting what fields can be saved

2006-07-07 Thread [EMAIL PROTECTED]

While, I feel a little less sheepish for not having noticed that if
these guys didn't either. I'm going to have to print out the api for my
bedtime reading :-)

I'm still not sure I like that solution best... when my user model
contains 40-some fields, I'd rather not be passing arrays of that size
around, when I could just blacklist the few fields I don't want
writable... I'll be thinking about the beforeValidate and limitFields
options.

Thanks for the input, guys.

chris


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake 
PHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---



Re: limiting what fields can be saved

2006-07-07 Thread Samuel DeVore
in your model file you could create your own save function that has a default $whitelist that then gets passed to the parent::save()Sam DOn 7/7/06, 
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
While, I feel a little less sheepish for not having noticed that ifthese guys didn't either. I'm going to have to print out the api for mybedtime reading :-)I'm still not sure I like that solution best... when my user model
contains 40-some fields, I'd rather not be passing arrays of that sizearound, when I could just blacklist the few fields I don't wantwritable... I'll be thinking about the beforeValidate and limitFieldsoptions.
Thanks for the input, guys.chris

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake PHP group.  To post to this group, send email to cake-php@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/cake-php  -~--~~~~--~~--~--~---


Re: limiting what fields can be saved

2006-07-07 Thread nate

I suppose we could add an option to treat the whitelist as a blacklist,
but anything beyond that and we're getting ahead of ourselves.
Handling security at this level is very application-specific.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake 
PHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---



Re: limiting what fields can be saved

2006-07-07 Thread brandags

Would the Security component be a solution to this problem?
http://manual.cakephp.org/chapter/18

With it, I believe you can ensure that people can't post data to your
controller from another server - so they'd have to somehow change the
html form on your own server for it to validate. I've never used it, so
I may not be understanding what it can do, but I thought I'd throw it
out there since it seems applicable.

- Brandon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake 
PHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---



Re: limiting what fields can be saved

2006-07-07 Thread nate

 Would the Security component be a solution to this problem?

Kind of, but not really.  The Security components handles access
requests at the HTTP level, and while it can detect and deflect POST
requests that don't come from within the application, it is still
possible inject form elements or spoof POST data via client-side script.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake 
PHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---



Re: limiting what fields can be saved

2006-07-06 Thread Felix Geisendörfer




Hey Chris,

I think you've got a good point there. One solution I could think of is
to do something like this:

class PostsController extends AppController
{
    var $name = 'Posts';
    
    function update()
    {
    $post = $this-__limitFields($this-data['Post'],
array('text', 'title'));
    }
    
    function __limitFields($fields, $allowed_fields)
    {
    foreach ($fields as $field = $val)
    {
    if (!in_array($field, $allowed_fields))
    {
    unset($fields[$field]);
    }
    }
    
    return $fields;
    }
}

(didn't actually try it out, but I think you get the idea.).

But still, this could leave some holes in older apps if they store
critical data in tables that can be modified like this.

Best Regards,
Felix Geisendörfer

--
http://www.thinkingphp.org
http://www.fg-webdesign.de 



Chris Renner schrieb:

  It just occurred to me that I've left a serious security hole in my 
recent cake apps. By blindly using $this-params['data'] in my save, 
I'm leaving a hole for users to change whatever fields they want to. I 
want to remind people about the potential for this, and see if the 
group has a more elegant way of solving it.

Say for example I have a User model. Users need to be able to update 
their email address, etc., but I don't want them changing, say, the 
security_level field. So far, I've just used an edit form that 
contained inputs for email address, etc. but not for security_level. 
But (having just done it), it's easy for an html-savvy user to add an 
input name="data[User][security_level]" / and change it along with 
the rest of the data. Because my controller simply contains 
$this-User-save($this-params['data']) any field that's present in 
the form will be saved, including security_level.

Now, this fix for this can be easy: in my action, unset those fields I 
don't want to be writable. But it seems like there must be better way 
to do it... based on user roles in the before_filter perhaps? Or even 
in the model? What's the philosophy here? Should controllers have 
unfettered access to all fields of a model, or should access be limited 
from the model?




  


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Cake PHP group.  To post to this group, send email to cake-php@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/cake-php  -~--~~~~--~~--~--~---