I've committed the patch and will release 1.3.5 and 1.4.5 shortly. Thanks for everyone's input. Kris
-- Kris Wallsmith | Release Manager [email protected] Portland, Oregon USA http://twitter.com/kriswallsmith On May 28, 2010, at 3:43 AM, Stephen Melrose wrote: > I know that. And Kris proposed a fix for that. My answer was about the > mass-assignment problem and the attr_accessible thing Rails has. > > My apologies, I misunderstood. > > I can also confirm the patch works and solves the problem. > > > On 28 May 2010 11:26, Fabien Potencier <[email protected]> > wrote: > > On 5/28/10 9:31 AM, Stephen Melrose wrote: > If it was easy as just removing the ID field, I wouldn't have bothered > posting this. > > But a lot of the Propel validators require the ID to be in the values > array to validate against. So if you remove it, they stop working. > > I know that. And Kris proposed a fix for that. My answer was about the > mass-assignment problem and the attr_accessible thing Rails has. > > Fabien > > > > > > On 28 May 2010, at 08:19, Fabien Potencier > <[email protected]> wrote: > > On 5/28/10 9:04 AM, Don Pinkster wrote: > My 2 cents: > > Why don't we use something as attr_accessible in Ruby on Rails? > This way you can specify which attributes may be set with mass > assignment ($form->bind()); and need to be set with explicit setters: > $form->setValue()? > > We don't have mass-assignement problems with symfony, just remove the > fields you don't want the user to modify. > > > Now I write this, isnt this wat $this->useOnly() is meant for? > > Exactly. You can also just unset() fields. > > Fabien > > > -----Original Message----- > From: "Kris Wallsmith"<[email protected]> > Sent: Friday, 28 May, 2010 07:17 > To: "symfony developers"<[email protected]> > Subject: [symfony-devs] Re: Potential Flaw in the Form Framework [1.4] > > I've attached a patch to the ticket for review. Please comment. > http://trac.symfony-project.org/ticket/8639 > > Thanks, > Kris > > On 10 May, 12:08, Stephen Melrose<[email protected]> wrote: > It's not that simple Russ. > > Where do you perform the check that they are allowed to access/save an > object of a certain ID? > > I personally have always checked the object after I've taken it from > the > route and before I've passed it to the form. After I've done that, I > don't > expect the object to magically be transformed into another record, > a.k.a. > something they're not allowed to access, and I bet the vast majority of > symfony developers don't either. > > Your point is valid and one I've agreed with throughout this thread, if > you're restricting what a user can edit, you need to make sure you safe > guard your code properly, and that's something I didn't do purely > because I > didn't expect the scenario I've detailed to occur, and to be honest, > nor > should it. > > The ID is passed as a hidden field (for whatever reason), but I > don't expect > the PK to be changed. How often would you actually edit a PK? > > I'm simply arguing the PK should be read only be default. > > On 10 May 2010 20:01, Russ<[email protected]> wrote: > > > > > > Personally I always check if the user has credentials to edit the > object anyway and I couldn't give a monkeys if they change the id > using Firebug or whatever as long as it's to one they have access to. > If not, they'll get a nice 403 response either way. > > The way I see it, editing the ID using Firebug or some other method > would be just the same as if they opened that object up for editing in > the first place... As long as they are allowed to, then so be it. > > On May 10, 12:16 pm, Stephen Melrose<[email protected]> wrote: > Hi, > > We have discovered what could be a potential flaw in the form > framework. The reason I'm discussing this here is because I'm in > mixed > feelings as to whether this is actually bug or not, or rather poor > implementation on our part. Either way, I'm also saying this flaw > should be safe guarded against. > > We discovered that a malicious user can use the forms generated by > the > form framework to edit content they shouldn't be able to. > > They do this by replacing the primary ID in the hidden form field > with > that of the record they want to edit. When they hit save, the > validation is run, and the Object is updated with the new ID, so when > the save() is called, the other row is updated. > > Now, if we (as in developers) want to restrict editing of content for > certain users, then it is our responsibility to make sure we put safe > guards in place. I'm not arguing this fact. > > The reason I believe this to be a problem is how users will actually > guard their code. Most people (including myself) run all the safe > guard checks before the Object is passed into the Form on > construction. I don't then expect the POST data to override the > primary key of the Object on save. Infact, I can't think of an > instance I would ever want this to happen. > > I therefore propose that some sort of restriction/block is put in > place by default that stops the PK of an Object being altered on > bind(). > > Thoughts? > > Stephen Melrose > > -- > If you want to report a vulnerability issue on symfony, please > send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%2bunsubscr...@google > groups.com> > For more options, visit this group athttp:// > groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send > it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%2bunsubscr...@google > groups.com> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send > it to security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it > to security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
