[symfony-users] Re: Primary Key Forgery Attack?
Would you share your solution? I would suspect one way to go about doing it is keeping the current ID in the session (as a flash variable) and comparing it upon post. On Sep 2, 7:03 pm, Jeremy Thomerson wrote: > Yeah - but it's better to have both kinds of security. The validation that > the same ID is coming back in is simple and can be generically added to all > Propel forms from a single place. That makes securing it with business > logic easier, because you don't have to worry about invalid IDs. I > implemented the ID forge protection in my BasePropelForm last night and it > works great, so now I have both that and the security of verifying that the > record being edited is allowed to be edited by the authenticated user. > > It just seems like this is something that would be built in - just like CSRF > protection. It's a basic web attack strategy that could (and I think > should) easily be defended against by the framework - making it that much > better for the user. And it's not difficult - it only took me a couple > hours to create it. > > Jeremy Thomerson > > On Wed, Sep 2, 2009 at 3:10 AM, Sid Bachtiar wrote: > > > Hi Jeremy, > > > Those Symfony / Propel generated forms are basic with no security. You > > will need to secure them based on the requirements of your project. > > > You don't secure a record from unauthorized access by obscuring the > > ID, you actually have to check to make sure that a user is allowed to > > access particular record when they try to. > > > Sid > > > On Wed, Sep 2, 2009 at 5:55 PM, Jeremy > > Thomerson wrote: > > > > I have a question. In Symfony / Propel forms, when I am editing an > > > object, the primary key is a hidden field. I have verified that by > > > using Tamper Data (or anything of the nature), I can modify a > > > different row in the database (iow, someone else's information) by > > > simply changing the ID value in the HTTP submission. > > > > This is very bad default behavior. Is there a way to turn this off? > > > > I have come up with a way to overcome it - similar to the CSRF > > > protection. But I've hit one snag. Here's the thought: > > > > 1 - In BasePropelForm __construct, I add a field to the form that has > > > a hash of the form class, the primary key value, and some secret > > > internal salt (other things could be added). > > > > 2 - I add a validator to the primary key field of the form that > > > verifies that the value that comes in on submission also hashes out to > > > the hash that was in the form. > > > > This works in my tests. The only snag is that I can't find an > > > automated way of getting the primary key field name. Is there a way? > > > > Thanks, > > > Jeremy Thomerson > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Primary Key Forgery Attack?
Yeah - but it's better to have both kinds of security. The validation that the same ID is coming back in is simple and can be generically added to all Propel forms from a single place. That makes securing it with business logic easier, because you don't have to worry about invalid IDs. I implemented the ID forge protection in my BasePropelForm last night and it works great, so now I have both that and the security of verifying that the record being edited is allowed to be edited by the authenticated user. It just seems like this is something that would be built in - just like CSRF protection. It's a basic web attack strategy that could (and I think should) easily be defended against by the framework - making it that much better for the user. And it's not difficult - it only took me a couple hours to create it. Jeremy Thomerson On Wed, Sep 2, 2009 at 3:10 AM, Sid Bachtiar wrote: > > Hi Jeremy, > > Those Symfony / Propel generated forms are basic with no security. You > will need to secure them based on the requirements of your project. > > You don't secure a record from unauthorized access by obscuring the > ID, you actually have to check to make sure that a user is allowed to > access particular record when they try to. > > Sid > > On Wed, Sep 2, 2009 at 5:55 PM, Jeremy > Thomerson wrote: > > > > I have a question. In Symfony / Propel forms, when I am editing an > > object, the primary key is a hidden field. I have verified that by > > using Tamper Data (or anything of the nature), I can modify a > > different row in the database (iow, someone else's information) by > > simply changing the ID value in the HTTP submission. > > > > This is very bad default behavior. Is there a way to turn this off? > > > > I have come up with a way to overcome it - similar to the CSRF > > protection. But I've hit one snag. Here's the thought: > > > > 1 - In BasePropelForm __construct, I add a field to the form that has > > a hash of the form class, the primary key value, and some secret > > internal salt (other things could be added). > > > > 2 - I add a validator to the primary key field of the form that > > verifies that the value that comes in on submission also hashes out to > > the hash that was in the form. > > > > This works in my tests. The only snag is that I can't find an > > automated way of getting the primary key field name. Is there a way? > > > > Thanks, > > Jeremy Thomerson > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Primary Key Forgery Attack?
Hi Jeremy, Those Symfony / Propel generated forms are basic with no security. You will need to secure them based on the requirements of your project. You don't secure a record from unauthorized access by obscuring the ID, you actually have to check to make sure that a user is allowed to access particular record when they try to. Sid On Wed, Sep 2, 2009 at 5:55 PM, Jeremy Thomerson wrote: > > I have a question. In Symfony / Propel forms, when I am editing an > object, the primary key is a hidden field. I have verified that by > using Tamper Data (or anything of the nature), I can modify a > different row in the database (iow, someone else's information) by > simply changing the ID value in the HTTP submission. > > This is very bad default behavior. Is there a way to turn this off? > > I have come up with a way to overcome it - similar to the CSRF > protection. But I've hit one snag. Here's the thought: > > 1 - In BasePropelForm __construct, I add a field to the form that has > a hash of the form class, the primary key value, and some secret > internal salt (other things could be added). > > 2 - I add a validator to the primary key field of the form that > verifies that the value that comes in on submission also hashes out to > the hash that was in the form. > > This works in my tests. The only snag is that I can't find an > automated way of getting the primary key field name. Is there a way? > > Thanks, > Jeremy Thomerson > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
