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:

      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

        Gliffy Diagrams

          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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda added a comment -

          yet another useless setting...

          Show
          Petr Skoda 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: