web-dev-qa-db-fra.com

Les faux utilisateurs ont-ils été créés sans utiliser le formulaire d'enregistrement du site, mais en utilisant des substitutions?

Je travaille avec un site Joomla 3.7.5. Le schéma d'enregistrement a toujours été l'activation de l'administrateur depuis le début. À l'heure actuelle, il y a un déluge constant de faux comptes d'utilisateurs russes. Ils ne sont pas activés, mais l'administrateur est spammé par les notifications.

Je sais que cela semble familier, mais c'est différent de l'autre Q/As que j'ai vu ici. J'ai aussi vu cet article de VEL mais cela n'explique pas ma situation.

Je remplace les classes principales UsersModelRegistration et JMail. Le remplacement JMail est utilisé pour acheminer tous les courriels du système via notre service de relais de messagerie. Le remplacement UsersModelRegistration est littéralement une copie de l'original avec une ligne ajoutée. Au sommet de la fonction register, je reviens tout de suite, au lieu de permettre à la fonction de s'exécuter. La raison en est que notre enregistrement est maintenant effectué via un composant personnalisé. Avec cette modification, l'enregistrement devrait être désactivé de la manière habituelle de Joomla. En plus de cela, j'ai ajouté une modification au contrôleur com_users afin qu'il redirige la vue de registre vers le composant d'enregistrement personnalisé. Mise à jour: j'ai vérifié une deuxième fois et voici comment nous traitons la redirection, ainsi qu'une substitution:

public function onAfterRoute() {
        $app = JFactory::getApplication();
        $option = $app->input->get('option', '');
        if ($app->isSite() && ($option == 'com_users' || $option == 'com_jsn')) {
            $task = $app->input->get('task', '');
            $acceptableTasks = array('registration.activate', 'user.login', 'user.logout');
            if (!in_array($task, $acceptableTasks)) {
                $db = JFactory::getDbo();
                $menusql = "SELECT id FROM #__menu WHERE link LIKE '%com_my_custom_component&view=account%'";
                $db->SetQuery($menusql);
                $menuItem = $db->loadObject();
                $menuitemid = (!empty($menuItem)) ? $menuItem->id : 0;
                $regLink = JRoute::_('index.php?option=com_my_custom_component&view=account&Itemid=' . $menuitemid);
                $app->redirect($regLink);
            }
        }
    }

Pourtant, les utilisateurs sont toujours créés sans utiliser le formulaire personnalisé. Je peux le dire assez facilement, car chaque inscription sur notre formulaire créera des enregistrements augmentés dans une autre table de base de données. Ces utilisateurs de spam sont tous les utilisateurs Joomla les plus élémentaires. Note latérale: littéralement, chacun de ces utilisateurs que j'ai consultés a une adresse IP russe.) Ils créent en quelque sorte un utilisateur. Étant donné que l'administrateur reçoit des courriers électroniques pour ces utilisateurs, ils doivent également créer l'URL qui vérifie leur courrier électronique, bien que cela doive inclure un jeton de hachage et comment l'obtient-il? Si quelqu'un était capable de télécharger un script de création d'utilisateur, pourquoi serait-il contrecarré par le processus d'activation de l'administrateur? Auraient-ils juste continuer et obtenir plus d'accès? Cette démarche est ennuyeuse, mais elle n’est ni rentable ni productive pour un polluposteur ou un pirate informatique.

Est-ce que quelqu'un d'autre a vécu quelque chose comme ça?

3
claywhipkey

Existe-t-il une régularité dans les courriels utilisés? Par exemple, ces courriels ont-ils un certain tld à la fin? Si tel est le cas, vous pouvez ajouter une expression régulière au modèle bloquant ces courriels.

Remarque: si votre site Web ne profite que du trafic américain, vous pouvez bloquer le trafic des pays vers lesquels nous ne voulons pas. De nos jours, la plupart des hôtes peuvent le faire pour vous. Cela vous fera gagner du temps et réduira les attaques sur votre site. Si vous bénéficiez du trafic international, je vous déconseille de le faire.

Une autre remarque: une bonne idée pour comprendre et (tenter de) prévenir les attaques serait de vérifier les journaux de votre serveur.

1
itoctopus