Moodle
  1. Moodle
  2. MDL-39503

Avoid telling Google that site allows signup

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4, 2.5, 2.6
    • Fix Version/s: 2.5.1
    • Component/s: Authentication
    • Labels:
    • Rank:
      50173

      Description

      My site is open to all and allows e-mail reg account creation. Despite Captcha mode, I was plagued until recently with bogus accounts being opened on a daily basis. I stopped them dead by simply renaming 'signup.php' and assoc. form file to something meaningless and linking from login.php.

      Although my open site is still 1.9, I assume the same applies to 2.x and changing the filename would stop MOST opportunistic abuse. My solution also includes a security question based on the open site text content. Most casual spammers would be too bored to bother chasing this up whereas genuine visitors will probably have frehly read the info.

      Related posts - https://moodle.org/mod/forum/discuss.php?d=227637

      Regards

      Alan Hess

        Activity

        Hide
        Michael de Raadt added a comment -

        How do you think accounts were being created with the Captcha in place? Do you think people were automatically creating the accounts somehow?

        Why do you think renaming the signup.php file had an impact?

        Show
        Michael de Raadt added a comment - How do you think accounts were being created with the Captcha in place? Do you think people were automatically creating the accounts somehow? Why do you think renaming the signup.php file had an impact?
        Hide
        Alan Hess added a comment -

        Hi

        Looking at previous logs, the bogus accounts were always created out of thin air. The IP would create the account and view details but nothing more. Since renaming 'signup.php' seven days ago the account creation has stopped completely!

        My open content site allows search bots in and I assume that files such as 'login', 'signup' are being searched for and a person enters the 'captcha'.

        Show
        Alan Hess added a comment - Hi Looking at previous logs, the bogus accounts were always created out of thin air. The IP would create the account and view details but nothing more. Since renaming 'signup.php' seven days ago the account creation has stopped completely! My open content site allows search bots in and I assume that files such as 'login', 'signup' are being searched for and a person enters the 'captcha'.
        Hide
        Michael de Raadt added a comment -

        Hi, Alan.

        It is possible, but I'm not sure a file rename would do the trick. I wonder if you will start getting bogus accounts created after a while. If bots are finding a file but then a person enters the captcha, then it would be simple for a person to find the file.

        Renaming it to something random, or even something that shifts randomly, could overcome problems in the short-term, but it could break a lot of links. Perhaps it could be done optionally.

        Adding further security seems like a better approach. Perhaps people could suggest other measures also.

        While this is an annoyance, I don't think it is a security issue, unless our account creation mechanisms are being automatically circumvented.

        Show
        Michael de Raadt added a comment - Hi, Alan. It is possible, but I'm not sure a file rename would do the trick. I wonder if you will start getting bogus accounts created after a while. If bots are finding a file but then a person enters the captcha, then it would be simple for a person to find the file. Renaming it to something random, or even something that shifts randomly, could overcome problems in the short-term, but it could break a lot of links. Perhaps it could be done optionally. Adding further security seems like a better approach. Perhaps people could suggest other measures also. While this is an annoyance, I don't think it is a security issue, unless our account creation mechanisms are being automatically circumvented.
        Hide
        Petr Škoda added a comment -

        I suppose we can try to prevent indexing of login/ folder. Workaround migth be to put it into robots.txt

        Show
        Petr Škoda added a comment - I suppose we can try to prevent indexing of login/ folder. Workaround migth be to put it into robots.txt
        Hide
        Alan Hess added a comment -

        Hi
        Thanks for the feedback. Looking back through logs, one particular email address has been used several times to create bogus accounts, so I think it is just some opportunist trying many Moodle or PHPbased sites going directly for signup.php.

        I'm still bogus account free at the moment and I'll try a robots.txt file in the login directory for extra security too.

        If of interest, my site address is on my profile page.

        Regards

        Show
        Alan Hess added a comment - Hi Thanks for the feedback. Looking back through logs, one particular email address has been used several times to create bogus accounts, so I think it is just some opportunist trying many Moodle or PHPbased sites going directly for signup.php. I'm still bogus account free at the moment and I'll try a robots.txt file in the login directory for extra security too. If of interest, my site address is on my profile page. Regards
        Hide
        Alan Hess added a comment -

        Hi

        For info. Since I renamed the 'signup.php' file to something meaningless and modified the MoodleCode to link the 'create new account' button via a security question, the bogus account creation has completely stopped! ! ! Even though the answer to the security question is in a linked '.js' file.

        It has worked for me, but a more secure version would be nice. I guess someone has been searching for signup forms, entering the captcha and then forwarding the account links for spamming. They obviously don't take the time to look at the account page in detail.
        Alan

        Show
        Alan Hess added a comment - Hi For info. Since I renamed the 'signup.php' file to something meaningless and modified the MoodleCode to link the 'create new account' button via a security question, the bogus account creation has completely stopped! ! ! Even though the answer to the security question is in a linked '.js' file. It has worked for me, but a more secure version would be nice. I guess someone has been searching for signup forms, entering the captcha and then forwarding the account links for spamming. They obviously don't take the time to look at the account page in detail. Alan
        Hide
        Petr Škoda added a comment -

        I have created a patch that should help with this at least partially, it add noidex meta tag to the login and signup page which should prevent google from indexing these pages - I suppose that was the way how spammers look for sites that allow signup. Please note you can not use signup block because it would disclose the existence of signup page, but maybe they will not find out...

        Thanks for the report.

        Show
        Petr Škoda added a comment - I have created a patch that should help with this at least partially, it add noidex meta tag to the login and signup page which should prevent google from indexing these pages - I suppose that was the way how spammers look for sites that allow signup. Please note you can not use signup block because it would disclose the existence of signup page, but maybe they will not find out... Thanks for the report.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Hi, isn't this somehow a bit a "dirty hack" ?

        I find it a bit abusing of the $CFG->additionalhtmlhead setting and also arbitrary to be introduced this way.

        What if I don't want my site to "hide" those pages or what if I want to protect another ones? Or what if I've another, conflicting, definitions in the robots.txt, or in the $CFG->additionalhtmlhead setting or in sitemaps sent to crawlers?

        Uhm... IMO or this is controlled externally (robots.txt), or implemented in another way... not 100% sure... asking other integrators...

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - Hi, isn't this somehow a bit a "dirty hack" ? I find it a bit abusing of the $CFG->additionalhtmlhead setting and also arbitrary to be introduced this way. What if I don't want my site to "hide" those pages or what if I want to protect another ones? Or what if I've another, conflicting, definitions in the robots.txt, or in the $CFG->additionalhtmlhead setting or in sitemaps sent to crawlers? Uhm... IMO or this is controlled externally (robots.txt), or implemented in another way... not 100% sure... asking other integrators... Ciao
        Hide
        Petr Škoda added a comment -

        1/ robots.txt works in server root only, we do not control that
        2/ $CFG->additionalhtmlhead is the only supported way to add more to page header, it is a hack, but standardised

        The point is to prevent search engine indexing of login and signup page, that is all. The patch does that.

        Show
        Petr Škoda added a comment - 1/ robots.txt works in server root only, we do not control that 2/ $CFG->additionalhtmlhead is the only supported way to add more to page header, it is a hack, but standardised The point is to prevent search engine indexing of login and signup page, that is all. The patch does that.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        I understand the point/goals, really.

        Just think it's not the best implementation, as said (although I can ignore that extreme).

        AND/BUT the thing that struggles me more is that it can break (well, no "break", you know, just being cleaned from the indexes) sites expecting their login pages to be specifically indexed/linked for any (good) reason. Sort of "sudden/unexpected" behavior change.

        So my vote goes to control that via setting so can land to all versions, or do it only for 2.6, documenting the behavioral change.

        Or perhaps I'm over-thinking/reacting... hence others opinions are welcome.

        Show
        Eloy Lafuente (stronk7) added a comment - I understand the point/goals, really. Just think it's not the best implementation, as said (although I can ignore that extreme). AND/BUT the thing that struggles me more is that it can break (well, no "break", you know, just being cleaned from the indexes) sites expecting their login pages to be specifically indexed/linked for any (good) reason. Sort of "sudden/unexpected" behavior change. So my vote goes to control that via setting so can land to all versions, or do it only for 2.6, documenting the behavioral change. Or perhaps I'm over-thinking/reacting... hence others opinions are welcome.
        Hide
        Petr Škoda added a comment -

        yet another useless setting...

        Show
        Petr Škoda added a comment - yet another useless setting...
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Integrated (25 & master only), thanks!

        Note: I've not sent it to older branches because I'm not entirely sold to the change in behavior, as commented above.

        Show
        Eloy Lafuente (stronk7) added a comment - Integrated (25 & master only), thanks! Note: I've not sent it to older branches because I'm not entirely sold to the change in behavior, as commented above.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Passing, verified the meta-robots is now added to both the login and signup pages.

        Show
        Eloy Lafuente (stronk7) added a comment - Passing, verified the meta-robots is now added to both the login and signup pages.
        Hide
        Dan Poltawski added a comment -
        Feature: Thanks to our superb contributors
          In order to make Moodle better
          As an integrator
          I need to thank all our contributors
        
          Scenario: Dan thanks you all
            Given I log in as "dan"
            And I see "lots of fixed issues"
            When I follow "Close integrated issues"
            Then I should see "Lots of thanks to all our contributors"
        

        Your changes are upstream

        Show
        Dan Poltawski added a comment - Feature: Thanks to our superb contributors In order to make Moodle better As an integrator I need to thank all our contributors Scenario: Dan thanks you all Given I log in as "dan" And I see "lots of fixed issues" When I follow "Close integrated issues" Then I should see "Lots of thanks to all our contributors" Your changes are upstream

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: