Hmm, created these: apps/test/modules/sfGuardUser/config/security.yml apps/test/modules/sfGuardGroup/config/security.yml apps/test/modules/sfGuardPermission/config/security.yml
Then: symfony cc then I logged out, then I logged back in. The dummy account I'm using, which has no privileges (sf_guard_user_permission has a permission of 2 for this user - normal), but I still manage to log in and edit user accounts at URLs like: index.php/sf_guard_user/3/edit.html On Aug 23, 11:15 am, Tom Boutell <t...@punkave.com> wrote: > Jake Barnes says: > > "I created a test user account with no privileges. I log in as this > test user. I point my brownser here: > test_dev.php/sf_guard_user > I now see listed all of the users, and I can edit any of them. So I > open: > plugins/sfGuardPlugin/modules/sfGuardAuth/config/security.yml > And I add in: ..." > > Three things: > > 1. Don't edit directly in a plugin folder unless you are the author. > Your changes will get smooshed when you update the plugin. And you > will update the plugin, because bugs and security holes are bound to > be found over time in anything (not knocking sfGuard here, it's true > for pretty much anything). > > Symfony provides for modules to be overridden at the application > level. This is the correct way to change plugin behavior for your > particular application. > > 2. Look at that URL: > > test_dev.php/sf_guard_user > > sf_guard_user, not sf_guard_auth. You're locking down the wrong > module. There are several modules in sfGuardPlugin. > > sfGuardAuth is the one you DON'T want to secure, because it is the one > that allows you to log in. > > You want to lock down sfGuardUser, sfGuardGroup, and sfGuardPermission. > > Do it here: > > apps/frontend/modules/sfGuardUser/config/security.yml > apps/frontend/modules/sfGuardGroup/config/security.yml > apps/frontend/modules/sfGuardPermission/config/security.yml > > These can be really simple, as you noted: > > default: > is_secure: on > credentials: admin > > Then symfony cc and you're good to go. > > 3. You might very reasonably ask why these modules are not secured by > default. I'd like to know that too. As acceptance of Symfony grows, > exploits for common holes like this will probably become common. I > guess it might be a bit awkward to override if you wanted to set up > security differently, but I'm pretty sure it's doable. > > In our own applications we never enable sfGuardUser, sfGuardGroup and > sfGuardPermission. Since these are simple admin generator modules, > we've copied them to pkToolkitPlugin, themed them and enabled security > by default. For sfGuardGroup and sfGuardPermission we choose to > require superadmin status, because the set of groups and permissions > that are actually implemented in a project typically shouldn't be > changed by our clients; these modules are used only in the event we > make a design change. For sfGuardUser we remove the user-by-user > setting of permissions, keeping only groups (guest, editor, admin) to > simplify things for client admins. > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
