Hi, 2010/5/10 Stephen Melrose <[email protected]>: > 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?
I create a methods like newCommon() or editCommon() with all safe checks and call them from new/create, edit/update. The main reason for this is that you _always_ _need_ to perform the same checks in new and create as well in edit and update. Why? For example - user want to create a comment to blog post - new method is called - all safe checks pass well - form is rendered - user write his comment - other user delete his blog post - user tries to write his comment If you wont do the same check in create method you failed :) IMHO it's a security vulnerability, but it's not symfony fault. And BTW. CSRF protection should do the trick for form protection > > Stephen Melrose > Regards, Michal -- 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
