well the UUIDs do help for his problem of "being able to guess" the url i like UUIDs as you dont tell how many items have been added (this can be important in some cases)
but of course it has nothing to do with CSRF delele should NEVER be done by a GET-Request anyway GET never alters the database content! A small link "posted" to the delete url whould be more appropriate but even a normal POST is not secure anymore these days at least it helps to prevent basic "attacks" or simple unintential changes and is good enough for most cases On 4 Jan., 04:21, "j0n4s.h4rtm...@googlemail.com" <j0n4s.h4rtm...@googlemail.com> wrote: > Well using UUIDs would result into /users/view/LONG-UU-ID-HERE > > Which would not resolve Cross Site Request Forgery. > Use SecurityComponent and use form buttons that use method = post. > That way "destructive" links get caught if no form security token was > found. > > I do it like > this:http://github.com/ionas/sna/blob/master/www/app/app_controller.php#L11http://github.com/ionas/sna/blob/master/www/app/controllers/messages_...http://github.com/ionas/sna/blob/master/www/app/views/helpers/secure.php > > <?=$secure->link(__('Restore', true), array('action' => 'restore', > $message['Message']['id']), array('class' => 'messageRestore'))?> > <?=$secure->link(__('Remove', true), array('action' => 'remove', > $message['Message']['id']), array('class' => 'messageRemove'), __('Are > you sure you want to remove', true).' "' . $message['Message'] > ['subject'] . '" > permanently?')?>http://github.com/ionas/sna/blob/master/www/app/views/messages/mailbo... > > Which generates "destructive" form buttons in an almost same way that > normal html links are being generated. You can even style those > buttons to look similar to normal text links (but I recommend you NOT > to do this, data creating or modifying "links" should be html buttons, > data searching/reading/fetching links should be html links, this is a > good paradigma for/from the user point of view). > > You can read more about this topic > here:http://www.ad7six.com/read/67-Generic-capability-based-security-(CSRF...)http://teknoid.wordpress.com/2008/11/05/make-your-cakephp-forms-a-lot...http://teknoid.wordpress.com/2008/11/06/clearing-up-some-confusion-re... > > The other way you could go would be to serialize and unserialize the > complete request url. I recommend not to do that (bad for bookmarks > for instance) > > King regards > ionas82 > > On Jan 3, 6:45 pm, euromark <dereurom...@googlemail.com> wrote: > > > just use UUIDs > > that "feature" comes with it automatically > > > On 3 Jan., 08:41, Walther <waltherl...@gmail.com> wrote: > > > > Not really possible afaik. > > > > But, security through obscurity is not the solution. You should rather > > > spend the time writing code that will make sure that the user/referer > > > has permissions to perform that action. > > > > On Jan 1, 9:54 pm, anka <andreas.katz...@gmail.com> wrote: > > > > > Hi @all, > > > > > I have a (almost) simple question! Is it possible to make all cake php > > > > REST URLs unreadable? What I mean is, that a given REST URL like ".../ > > > > user/delete/10" is very simple to read for a human and it is very > > > > simple to guess that I can call this URL with any ID i want. So it > > > > would be very helpful, to generate URLs like ".../ > > > > aasdf080234ljasdflk234" or something like that so no human can modify > > > > the URL within the browser and to avoid anoying side effects within > > > > the system. > > > > > Thanks and best regards, > > > > Andreas Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
