User's ability to change their own password.

[Patrick Nelson]

First point:

I noticed that when I setup a user with very limited access to the CMS (i.e. only to the file/asset manager), they were not able to view/edit their own profile (by clicking the link for their name) and change their password via this route: "/admin/myprofile". However, it turns out that if they're given "generic CMS permissions" (e.g. only CMSMain or LeftAndMain) then they're able to view/edit their profile and I tracked it down to this code: https://github.com/silverstripe/silverstripe-framework/blob/3/admin/code/CMSProfileController.php#L60

Is there a better way to set this up so that a user who has access to the CMS (who is going to have that link be visible for them) have the ability to actually use that link? Like, maybe referencing the contents of the menu in LeftAndMain and assuming that you can access the CMS at all means you should be able to edit your own profile (since you already know your own password anyway).

Second point:

I realized that if you can already access the "/admin/myprofile" route that there's no point to even asking for the "current password" on the other "/Security/changepassword" route. Unless you're an, shouldn't this profile route be requiring you to confirm your own password before it allows you to reset it? Just seems to make more sense to me from a security standpoint.

- Patrick

[Patrick Nelson]

Correction to typo in last email: "Unless you're an admin, shouldn't..."

Also: I'm noticing that a user can also modify their own "failed login count" which doesn't make much sense since it has no impact anyway (confusing/clutter).

[Ingo Schommer]

First point: I'd recommend that we make the permissions required for editing your profile a YAML configuration (list of codes).

The alternative would be a generic "can access CMS" permission (different from CMS_ACCESS_LEFTANDMAIN which allows access to ALL interfaces).

Which is a more intrusive change to the permission model - basically, all existing implementations would need to decide where to grant this new permission or have things break on a core update.

Second point: Ideally both ways to change your password would be consistent (ask for the current password). This is common practice to avoid exploits (the "sudo" of websites), in addition to the CSRF protections already in place on every CMS form. A bit of a nuisance if you have forgotten your current password, since you'd need to use the "lost password" email functionality to reset. Might be prudent to have this level of security configurable as well, don't see it as a high priority though.

[Patrick Nelson]

On the first point about being able to visit the profile: I think that just having any links at all visible in the menu (signifying I've already got access to something behind the scenes there) would be enough. Or just that I can even login. So, having that enabled by default (maybe too much?) and allowing the ability to disable that via YAML config.

Second point: Are you suggesting having that disabled by default or enabled by default? I'd think maybe enabled by default, since I figure few people will want (or even think) to disable that and so people will be just a little bit more secure.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Ingo Schommer]

On 25 August 2015 at 15:36, Patrick Nelson <p...@catchyour.com> wrote:

On the first point about being able to visit the profile: I think that just having any links at all visible in the menu (signifying I've already got access to something behind the scenes there) would be enough.

I think that'd water down the already too complicated permission model - a permission based on "view state in menu" seems dodgy. What if somebody overrides the CMS menu, e.g. with a grouped version, and now this causes a security issue because non-CMS users can access admin/myprofile and edit data which they usually don't have access to?

Or just that I can even login.

That's not enough of an indication, since SS uses the same login facilities for CMS and (optional) frontend functionality - e.g. on forum logins on ss.org.

So, having that enabled by default (maybe too much?) and allowing the ability to disable that via YAML config.

Second point: Are you suggesting having that disabled by default or enabled by default? I'd think maybe enabled by default, since I figure few people will want (or even think) to disable that and so people will be just a little bit more secure.

I think "secure by default" trumps usability in this case, and we should ask for the current password consistently. I'm not sure of any common attack vectors here though, just going by my experience in other products like Google - before accessing any sensitive areas like profile it usually asks you for a password even if you're logged in. 

On Mon, Aug 24, 2015 at 11:20 PM, Ingo Schommer <in...@silverstripe.com> wrote:

First point: I'd recommend that we make the permissions required for editing your profile a YAML configuration (list of codes).

The alternative would be a generic "can access CMS" permission (different from CMS_ACCESS_LEFTANDMAIN which allows access to ALL interfaces).

Which is a more intrusive change to the permission model - basically, all existing implementations would need to decide where to grant this new permission or have things break on a core update.

Second point: Ideally both ways to change your password would be consistent (ask for the current password). This is common practice to avoid exploits (the "sudo" of websites), in addition to the CSRF protections already in place on every CMS form. A bit of a nuisance if you have forgotten your current password, since you'd need to use the "lost password" email functionality to reset. Might be prudent to have this level of security configurable as well, don't see it as a high priority though.

On Tuesday, August 25, 2015 at 8:10:06 AM UTC+12, Patrick Nelson wrote:

First point:

I noticed that when I setup a user with very limited access to the CMS (i.e. only to the file/asset manager), they were not able to view/edit their own profile (by clicking the link for their name) and change their password via this route: "/admin/myprofile". However, it turns out that if they're given "generic CMS permissions" (e.g. only CMSMain or LeftAndMain) then they're able to view/edit their profile and I tracked it down to this code: https://github.com/silverstripe/silverstripe-framework/blob/3/admin/code/CMSProfileController.php#L60

Is there a better way to set this up so that a user who has access to the CMS (who is going to have that link be visible for them) have the ability to actually use that link? Like, maybe referencing the contents of the menu in LeftAndMain and assuming that you can access the CMS at all means you should be able to edit your own profile (since you already know your own password anyway).

Second point:

I realized that if you can already access the "/admin/myprofile" route that there's no point to even asking for the "current password" on the other "/Security/changepassword" route. Unless you're an, shouldn't this profile route be requiring you to confirm your own password before it allows you to reset it? Just seems to make more sense to me from a security standpoint.

- Patrick

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

[Patrick Nelson]

I agree on all points. Maybe a separate permission (just one) in addition to, or as a consolidation of, the existing permissions to determine if a user can access their profile, such as "CMS_ACCESS_MyProfile" or similar. Anyway -- not saying I'm going to build this, but figured it warranted some discussion since it did relate to some core development :D Thanks for the quick feedback, Ingo!

[Daniel Hensby]

FYI - this has now been fixed in 3.1 branch - https://github.com/silverstripe/silverstripe-framework/pull/4543