ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Urgent /member/memberlist security issue!

October 08, 2009 7:08pm

Subscribe [5]
  • #1 / Oct 08, 2009 7:08pm

    Paul_B

    86 posts

    Hi - I’ve just had it brought to my attention that if you add /member/memberlist to an EE site url it will return a list of all site members. If you use google to check how many sites are being indexed with member/memberlist in the url it returns 259,000 results of what looks like mostly EE sites, listing all users (albeit some only have one, and some will realise that they’re publishing this list - ee is the first, but interestingly codeigniter.com is a few pages in and I don’t think their user list should b public)

    I didn’t realise that this was publicly available information and have just had to add a load of redirect rules to many .htaccess files to lock down sites - on some sites I’ve used email_as_username, and so these sites were just returning long lists of email addresses.

    The friend that brought this to my attention realised what was happening when he was scrutinizing his logs and saw that google was indexing his memberlist (which he did’t know was there). We’re now trying to figure out how Google knows to do this when there are no references to the memberlist from any of the site pages…

    Is there a way in the control panel to manage this (ie switch it off)?

  • #2 / Oct 08, 2009 7:14pm

    Lisa Wess

    20502 posts

    Go to Admin -> Members & Groups -> Edit the Guest Member Group and set “Can View Public Profiles” to no.

    Then find any links to the memberlist and protect it with conditionals.

  • #3 / Oct 09, 2009 3:12am

    Paul_B

    86 posts

    Thanks Lisa - that does seem to do the trick.  It’s quite an obscure way of closing what feels like a big open hole, and it means that anyone who registers will be able to view the complete member list.

    In the spirit of general discussion, it also leaves (what feel like) some important and valid questions

    1) All of this is ‘on’ by default
    Shouldn’t this at least be an option during installation (would you like member data open?) At the very least it’s quite an easy way to see the administrator’s login name and email address if they don’t know to switch this section off to the public

    2) How are google returning 259,000 results of /member/memberlist sites?
    There are no public links to these pages within the site pages, but it looks like the robot journey goes like this:
    /member/forgot_password/
    /member/login/
    /member/register/
    /member/memberlist/
    This would make sense except that the member/register page doesn’t contain any links to the memberlist - so how are they making the jump?

  • #4 / Oct 09, 2009 11:37am

    ak4mc

    429 posts

    At the very least it’s quite an easy way to see the administrator’s login name and email address if they don’t know to switch this section off to the public

    I just looked at the memberlist that’s available through the frontend on my site and email addresses aren’t displayed; there’s a button on the list and on the member’s profile page but it works through EE’s email console so the visitor’s browser never accesses the address directly. Addresses are visible only to an author with access to the Member module through the control panel.

    This would make sense except that the member/register page doesn’t contain any links to the memberlist - so how are they making the jump?

    My best guess would be that these robots are programmed to expect certain things, so “memberlist” is a reasonable next step on an EE site with a registration page.

    FWIW, I have changed the trigger word that tells EE to open member pages, and I’ve never seen any of my site’s membership pages in Google results, even though the different word is available in every login tag on my site.

    It’s not an easy change to make as there are multiple places it has to be made in the system (and don’t ask me where they are; I’ve long since forgotten), but if it’s enough to have stopped robots from indexing those pages on my site, it might be worth it.

  • #5 / Oct 09, 2009 11:42am

    Ingmar

    29245 posts

    Thanks Lisa - that does seem to do the trick.  It’s quite an obscure way of closing what feels like a big open hole, and it means that anyone who registers will be able to view the complete member list.

    Unless, of course, you take those rights away from your regular members as well.

    At the very least it’s quite an easy way to see the administrator’s login name and email address if they don’t know to switch this section off to the public

    Actually, all you’d be seeing is the screen name, which is distinctive from the actual user name.

    I just looked at the memberlist that’s available through the frontend on my site and email addresses aren’t displayed;

    I think he was using mail addresses as user (and scren) names ...

    My best guess would be that these robots are programmed to expect certain things, so “memberlist” is a reasonable next step on an EE site with a registration page.

    I don’t think Google makes up links, but the member list is linked to from various places, most notably the forums.

  • #6 / Oct 09, 2009 11:47am

    Paul_B

    86 posts

    I don’t think Google makes up links, but the member list is linked to from various places, most notably the forums.

    What if you’re not running a forum? I just don’t get how a robot makes the jump from the member login/forgot password screens to the list, as there isn’t a link there. Weird.

    I’ll make sure my future installations are a bit more secure (disabling public profiles, renaming member keyword etc) - especially if using email_as_username; I still think this is something that should be opted-in to, not out of.

  • #7 / Oct 09, 2009 11:51am

    Ingmar

    29245 posts

    I’ll make sure my future installations are a bit more secure (disabling public profiles, renaming member keyword etc) - especially if using email_as_username;

    Even if you do use email as a user name (something that I personally discourage from a security point of view, but which may be required in some cases), you certainly shouldn’t use it as a screen name—and only that would be publicly visible.

    I still think this is something that should be opted-in to, not out of.

    It’s a valid point of view to take. Consider making in an FR.

  • #8 / Nov 30, 2009 6:12am

    Susan

    81 posts

    Go to Admin -> Members & Groups -> Edit the Guest Member Group and set “Can View Public Profiles” to no.

    Then find any links to the memberlist and protect it with conditionals.

    Hmm.. decided to do a check to see what links to the /member/something url string, and see this old, old standard item.

    Posted by <a href="http://{profile_path=member/index}">{author}</a> in {categories}

    Which leads to /member/1/ This isn’t particularly helpful.

    I think it’s time I create a better page for my own bio/listing than the default one, especially as that’s now forbidden from view for basic site visitors. Or just take out the link.

  • #9 / Nov 30, 2009 12:26pm

    Lisa Wess

    20502 posts

    Susan - I’m not following your comments.  Did you need help with something?

  • #10 / Nov 30, 2009 4:13pm

    Susan

    81 posts

    Do I need help? No, not especially.

    I was pointing out what I discovered when I looked up links to the member list from various templates on my site, and discovered that I’d rendered a somewhat murky linked result (on a single-author site, who’s going to look up my posts from my member profile area?) to be now-downright unfriendly if I perpetuate that link to the profile area and not allow non-logged in members to view it.

    [I’m clamping down on the whole member thing due to the amount of spam that’s shown up from people joining the site and posting links to places in member profiles.]

  • #11 / Mar 31, 2010 9:48am

    Emily Heath

    197 posts

    I’ve just discovered, to my surprise and embarrassment, that - like Paul - a client’s site’s members list has been available for anyone to see for some time, via this URL index.php/member/memberlist/

    I’ve found Robin’s answer on another thread which quickly fixed the problem, but I’m surprised that it isn’t made very clear in the documentation that when you allow members, these members list/profile pages will automatically exist online (I didn’t specifically upload a member template folder) and that they will be visible to ‘guests’.

    In fact, why is the default for Member Account Privileges ‘Can view public profiles’ not ‘No’ for guests? (I’ve added my vote to this as a Feature Request here, please add yours!)

    The member’s area of my site is a private and invite only, where even members aren’t invited to view the members list. I’m using members to create a password protected section of the website but they don’t have any posting/editing/communicating privileges. Or at least I thought they didn’t because I didn’t provide them a way to access the member’s pages.  I would expect that this is quite common usage and I’m surprised that other people haven’t, or perhaps they do and don’t know it, encountered this problem.

    I should add that I do have a forum on my website - is that what makes these pages appear? I checked on another client’s site which has members and I can’t find the /member/memberlist/ but then I am using Solspace’s User module on that one and I do allow members to see a (custom templated) member’s list so perhaps this overrides the default ones?

    Fortunately, only screennames (which on this site usually = username) and the members’ WWW links were on show, but this is still exposing the members privacy in some way, and weakens security since a hacker has half the information they need to try and log into the site. Not the control panel, but they could still go have a sniff around in my members area which I don’t want.

    An aside: some might be interested to know how my client discovered this potential security issue: They discovered that there was traffic coming to their website from thumpergooga1.posterous.com This website (and associated twitter profile twitter.com/thumpergooga1) looks like it might be a hacker’s directory of websites with exposed profile pages?

  • #12 / Apr 07, 2010 11:26am

    Danny T.

    426 posts

    There was a post over at EE Insider about this recently. I’m in the camp that, by default, this should be disabled since not all sites require it. ExpressionEngine seems to lock down features by default unless otherwise needed.

    To remedy this, change the member trigger word into something obfuscated and then manually disable all the memberlist option per each group in the member preferences.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases