[Remember Mailing List] [remember] possible security issue?

[Gray McCord]

Plone 3.2.1 / remember 1.1b1

First, I hope I got this address right.  Its been a while since I used this list.  Apologies if I messed up! 

I use remember to permit self-registration with approval on a series of team sites for my company. Today, we noticed that the memberdata folder is exposed to anonymous users if you know the direct url to it. Of course, google has found it, so when searching for the name of some of the registered members, the memberdata page shows up, along with a portal showing all of the users and their email info. That wasn't horrible, but the search box is available, and while you cannot actually see content, search will show titles / links for much of the site content. 

Does anyone have any ideas about what's going on? I can't find any security settings in the ZMI that seem to affect this. Also, I can't blame this on Remember with 100% certainty, although the memberdata folder seems to be a membrane/remember item, right?

Thanks!

Gray McCord

Adapt, Mutate, Migrate, or Die

                                                          -C. Darwin

--
Archive: http://www.coactivate.org/[…]/1285354925296
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Mike Metcalfe]

On 24 September 2010 21:01, Gray McCord <g...@sangabriel.com> wrote:

I use remember to permit self-registration with approval on a series of team sites for my company. Today, we noticed that the memberdata folder is exposed to anonymous users if you know the direct url to it. Of course, google has found it, so when searching for the name of some of the registered members, the memberdata page shows up, along with a portal showing all of the users and their email info. That wasn't horrible, but the search box is available, and while you cannot actually see content, search will show titles / links for much of the site content. 

What is the state of the members? If they are public, they will appear in the live search. If they are private, they shouldn't.

--
Archive: http://www.coactivate.org/[…]/1285355893826

[ken manheimer]

On Fri, Sep 24, 2010 at 3:01 PM, Gray McCord <g...@sangabriel.com> wrote:

Plone 3.2.1 / remember 1.1b1

First, I hope I got this address right.  Its been a while since I used this list.  Apologies if I messed up! 

I use remember to permit self-registration with approval on a series of team sites for my company. Today, we noticed that the memberdata folder is exposed to anonymous users if you know the direct url to it. Of course, google has found it, so when searching for the name of some of the registered members, the memberdata page shows up, along with a portal showing all of the users and their email info. That wasn't horrible, but the search box is available, and while you cannot actually see content, search will show titles / links for much of the site content. 

i'm not sure about the way you expose the other content on your site, but the default remember configuration/workflow has members as either private or public, depending on what they elect in their profile.  as i recall, public is completely public.  private is private from all visitors (catalog responses take accessibility into account), including other members.

for what it's worth, i developed a remember derivative with some key differences, including the two basic dispositions for member exposure being private (as with standard) remember and "common", where members are visible to other members but not anonymous visitors.  i also included a way for managers to promote members who elect to share their profiles (and so be in the common state) to public visibility, for public-facing members like coordinators and organizers.  (my workflow also doesn't depend on any magic methods in the member object to trigger workflow transitions when members edit their profiles - i instead use content rules, which i find yeilds a lot cleaner member code.)

i have all this working with versions of membrane and remember that run under plone 3 and plone 4, though i haven't yet gotten it working with the recent updates wichert checked in - i'm still blocked by a cataloging problem i mentioned a while back.  i'm about to return to working on that - i'd like to finish and release my implementation, but figure it's a dead end until i can reconcile it with wichert's changes.

Does anyone have any ideas about what's going on? I can't find any security settings in the ZMI that seem to affect this. Also, I can't blame this on Remember with 100% certainty, although the memberdata folder seems to be a membrane/remember item, right?

remember's portal_memberdata can be used as an interface for browsing and visiting members profiles.  it doesn't expose anything that's not otherwise exposed, as you suggest, eg through the catalog.  (in fact, you can make members linkable, so they can be referred to with internal links in the editor - useful in some situations.)  it has minimal interfaces, though, so it requires a bit of extending for things like inclusion in site navigation, etc.  but i don't think it exposes any security leaks.

Thanks!

hope this is helpful...

 

Gray McCord

Adapt, Mutate, Migrate, or Die

                                                          -C. Darwin

--
ken
http://myriadicity.net

--
Archive: http://www.coactivate.org/[…]/1285358549353

[Gray McCord]

One of these days I will learn to try the obvious first. ;-)  Naturally I had the members set to public, which appears to be the issue. Thanks for responding and helping out so quickly. You guys are great!  Sorry for the bother.

Gray

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Gray McCord

Adapt, Mutate, Migrate, or Die

                                                          -C. Darwin

--
Archive: http://www.coactivate.org/[…]/1285362060022

To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.