Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

[svimic]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Bonjour,
c'est a toi d'expliquer qu'en terme de Cms (Joomla ou un autre) il faut suivre a minima les mises a jour qui comble les failles potentielles et apportent souvent des fonctionnalités supplémentaires. Tu peux ainsi mettre en place un contrat de maintenance.

C'est une bonne idée à laquelle je pense depuis l'été lorsqu'un des sites a été hacké et bloqué par l'hébergeur. Je n'ai rien facturé mais commencé à préparer un message aux clients leur expliquant tout ça…

[RobertG]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Récemment, pour trois sites sur lesquels nous avions bossé il y a environ un an avec un collègue, le couple propriétaire des trois sites ayant refusé toute maintenance, nous avons été alertés par des inscriptions indésirables. Un petit mail aux dits propriétaires leur expliquant que sans intervention de mise à jour ils risquaient de perdre leurs sites a suffi pour les convaincre que le contrat de maintenance que le collègue leur avait proposé se justifiait. Le tout était de saisir l'occasion...

[svimic]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

le contrat de maintenance que le collègue leur avait proposé se justifiait...

En effet, la question étant comment chiffrer un contrat de maintenance pour un site Joomla ?En volume d'heures, combien cela peut-il représenter par année ? quelqu'un a une idée à partager sur la question ?

[svimic]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Lecture trop rapide ;-)

Oui, désolé :-(
En général je suis les discussions en même temps que mille autres choses. Aussi pour répondre du tac au tac. Mais il faudrait lire et relire attentivement toutes ces contributions.

[PhilJ]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Concernant les formulaires de contact, j'utilise BreezingForms et n'ai pas mis de Captcha pour la raison évidente que les visiteurs ne vont pas l'utiliser s'il doivent s'escrimer à entrer un code souvent illisible :-) Sans rire c'est un véritable frein mais peut-être la seule solution pour éviter le spam. Ou ne pas mettre de formulaire et seulement un contact par email.

Sécuriser un formulaire (de contact, d'inscription..., peu importe) est une chose, le sécuriser à l'aide d'un captcha en est une autre. Les captchas sont une solution, mais il existe des sécurisations sans captcha (plugins dits « captchaless »). Avantage évident : étant totalement invisibles, ils ne nécessitent aucun effort particulier de l'utilisateur. Le formulaire est défendu bien qu'il paraisse sans défenses.

Le premier principe de ces solutions repose sur un constat simple : l'origine de l'utilisation frauduleuse / malveillante des formulaires est très rarement humaine au sens d'un internaute indélicat. Dans presque tous les cas (peut-être 99% des cas), l'usage malveillant du formulaire est le (mé-)fait d'un robot. Or, un robot agit aussi rapidement qu'il le peut... beaucoup plus rapidement qu'un internaute, beaucoup trop rapidement donc. => Si le formulaire est entièrement complété en (par exemple) moins de 5 secondes, alors l'origine ne peut pas être un internaute mais un robot, et il est aussitôt bloqué.

En outre, les spambots sont souvent les mêmes : en cas de doute, ces plugins captchaless sont capables d'interroger des bases de données en ligne (DNS-based Blackhole Lists, DNSBL) telles que dnsbl.manitu.net, sorbs.net, projecthoneypot.org, sorbs.net, stopforumspam.com, spambusted.com, spamcop.net... afin de déterminer si l'origine de la requête est ou non connue pour provenir de robots malveillants.

Technique complémentaire : les honeypots (littéralement « pots de miel »). Il s'agit de pièges destinés à attirer les robots. Concrètement, un champ caché, dissimulé aux yeux des internautes par Javascript ou CSS, mais visible dans le code source est ajouté au formulaire. S'il est complété d'une manière ou d'une autre, alors l'activation du formulaire est nécessairement le fait d'un robot.

____________________

Deux plugins captchaless pour Joomla 3 : 'Aimy Captcha-Less Guard', dont il existe une version gratuite et généralement suffisante (http://www.aimy-extensions.com/jooml...orm-guard.html), ou encore 'SpambotCheck', qui est gratuit (http://www.vi-solutions.de/en/joomla...lgspambotcheck).

A noter aussi : le générateur de formulaires 'Visforms' embarque déjà nativement 'SpambotCheck' : http://www.vi-solutions.de/en/joomla...nsion-visforms.

[RobertG]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

En effet, la question étant comment chiffrer un contrat de maintenance pour un site Joomla ?En volume d'heures, combien cela peut-il représenter par année ? quelqu'un a une idée à partager sur la question ?

Il faut arriver à estimer le temps à y passer en fonction de l'implication du client et des extensions installées. Il est bien entendu que si le site n'embarque aucune extension ou seulement quelques unes légères, on n'y passera pas autant d'heures que s'il y a des extensions comme un forum ou une boutique de vente en ligne.
Ceci dit, avec la simplification des mises à jour, depuis quelques temps, on a moins de temps à y consacrer. Ensuite, il faut voir si on se contente de gérer ces mises à jour ou si le client peut avoir besoin d'une assistance à la gestion de son site ou pas.
Bref, ce n'est pas toujours facile à estimer.

[svimic]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Merci pour cette piste très intéressante que je ne connaissais pas
Dès que j'ai un peu de temps libre, je vais voir cela et probablement changer mes formulaires.

[daneel]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Technique complémentaire : les honeypots (littéralement « pots de miel »). Il s'agit de pièges destinés à attirer les robots. Concrètement, un champ caché, dissimulé aux yeux des internautes par Javascript ou CSS, mais visible dans le code source est ajouté au formulaire. S'il est complété d'une manière ou d'une autre, alors l'activation du formulaire est nécessairement le fait d'un robot.

Bonjour Stéphane,

Pour compléter l'explication de philJ. Il y a la technique de pot de miel, le projet honeypot et ses variantes. Cela fait déjà une première barrière contre les robots spammeurs. En fait le projet honeypot collecte les ip, mail de spammeurs, ce qui permet de les bloquer avant même la saisie !



J'utilise cela sur les formulaires y compris sur les formulaires d'inscriptions. J'instaure également un délai entre chaque soumission avec la même ip. Vous pouvez utiliser l'un des captchaless recommandés par philJ

Je combine avec des protections au niveau du serveur (firewall avec détection xss et autres), certaines règles dans le fichier htaccess (que l'on peut obtenir également via des outils comme aesecure), cloudflare (qui inclus gratuitement à la fois sécurité, optimisation et cdn) et certificat ssl sur serveur.

Pour la petite histoire, le projet Honeypot fut lancé en 2004 par ceux qui ont monté ensuite Cloudflare en 2010...

https://fr.wikipedia.org/wiki/CloudFlare

J'utilise rarement un "captcha" mais celui de Google est plutôt réussi. D'autres sont assez intéressants sur le plan marketing ou pour monétiser l'action. https://www.funcaptcha.com/setup/#tab-1440462321654-8-9
(voir en bas de page : https://www.funcaptcha.com/2015/08/3...joomla-drupal/ )

En résumé, cloudflare, honeypot & captchaless, modifications dans le fichier htaccess...
Cela fonctionne comme ça avec succès depuis plusieurs années

[svimic]

Re : Utilisateur (bidon) créé malgré l'enregistrement utilisateur désactivé

Merci encore à tous. Je suis gâté par vos réponses et j'ai de quoi potasser pendant la pause de fin d'année !
Et du pain sur la planche

N'ayant pas fourni d'URL puisqu'il s'agit de plusieurs sites, je vous donne quand même celle du mien: 128k.ch

Stéphane