Pour le site des jolis poussins, j’ai fais un thème perso pour WordPress comme d’habitude.
Vient le moment d’ajouter un formulaire ContactForm7 (Je n’aime pas utiliser de plugin, mais bon… parfois ça simplifie la vie des gens qui bossent avec moi.).
Et ça marche pas.
Le shortcode était en lieu et place du formulaire.
Après avoir cherché à droite et à gauche, j’ai compris que mon appel au contenu n’était pas le bon.
Par soucis pratique pour ce projet j’ai appelé le contenu de mes pages via get_the_content(), et pour la petite info, get_the_content() n’interprète pas les shortcodes et vous les redonne en brut.
Vous devez obligatoirement passer par l’affichage direct de the_content() pour avoir une interprétation des shortcodes.
Comme j’utilise très peu de shortcodes, j’ai créé une page-ID.php dans mon template ou j’intègre the_content() en lieu et place de mon get_the_content() juste pour les pages de contact.
N’oubliez pas que le tableau de hiérarchie des pages pour WordPress est vachement bien fait.
C’est l’histoire d’un client qui était certain d’avoir raison en commandant sa pièce détachée A, alors qu’on lui disait qu’il avait besoin de la B.
Le lendemain de sa commande, on s’est dit qu’on allait pas le laisser tomber, et qu’il serait surement trop fier pour nous dire qu’il s’était trompé, on lui a donc envoyé la pièce B sans rien lui dire.
Le jour de la réception de la pièce A… Comme attendu, pas de nouvelle.
Le lendemain, il nous a contacté, plus que ravi, pour nous remercier plus que chaudement, et pour nous dire qu’il était désolé.
Ces dernières heures chez Jardiforet.com, nous avons été sous le coup d’une attaque de spammeurs utilisant notre nom de domaine.
Pourtant;
Notre domaine d’expédition est relativement protégé, avec des DKIM et des SPF configurés correctement.
Notre serveur d’hébergement ne peut pas envoyer d’email.
Tous nos emails sont envoyés via Mandrill (je vous en parlerais un jour dans la catégrie #Mes outils), et nos clés API sont safe.
Notre site ne peut envoyer qu’un nombre très restreint d’emails différents.
Les attaquants ont utilisé une technique que je ne connaissait pas !
Une technique se jouant de toutes les sécurités mise en place sur les noms de domaines.
Une technique relativement compliquée à contrecarrer si elle etait utilisé à grande échelle.
Les attaquants créent à tour de bras des comptes sur notre site, avec l’adresse de leur cible en remplacent le nom et prénom par leur message à transmettre.
Le « Bonjour Alban JAMESSE », se transforme en
« Bonjour MESSAGE DE SPAM POUR T’ENVOYER SUR UN SITE RUSSE ».
Comment contrer cette attaque ?
Bloquer les création de compte de ces bots ?
Les logs de notre site indique que les comptes sont créés par des IP françaises à chaque fois différentes, sur tous les FAI (botnet ?).
Diminuer la taille autorisée des champs nom et prénom ou modifier l’email?
Solution préventive oui, mais ça ne règle pas le souci du botnet qui continu à envoyer des emails.
Empêcher l’envoi d’emails ?
Solution temporaire de secours, mais pas cool pour les vrais clients.
Donnez vos idées !
La solution que j’ai réussi à mettre en place
Par chance nos spammeurs ne spamment que des adresses emails russes (pour le moment ?).
Surement pour jouer sur le fait que les lecteurs lisent le cyrillique et fassent abstraction du romain.
Nous avons donc créé une règle dans mandrill qui bloque tous les emails à expédier vers des adresses en .ru .
Cette solution tient le coup depuis une heure maintenant.
Mais quid de quand ils vont attaquer d’autres extensions ?
· Mise à jour ·
· 28/02/2018 ·
Nos règles de blocages sur Mandrill nous permettent :
- de bloquer tous les emails vers des adresses emails en .ru, qui sont les cibles de cette campagne de SPAM
- de bloquer tous les emails qui contiennent « http », ou « www » dans les objets
Mandrill nous a bloqué plus de 4000 emails (en date) répondant à l’une de ces deux règles, sans impacter nos véritables clients.
En raison de la vétusté de notre Magento, nous n’aurions pas réussi à contrecarrer cette campagne de SPAM sans Mandrill.
· Mise à jour ·
· 02/03/2018 ·
L’attaque a cessé.
En résumé :
- 10 jours d’attaque;
- 6000 messages envoyés;
- 5500 messages bloqués;
- Mandrill nous a bien sauvé le cul.
· Mise à jour ·
· 23/03/2020 ·
Depuis début 2019 l’attaque à reprise de manière continue et cible, comme le je craignais des adresses Gmail, Ouloook et tout plein d’autres domaines hors de Russie.
Le volume quotidien est d’environ 50 à 100 création de faux comptes par jours.
Nos règles Mandrill nous ont permis de ne pas envoyer 42.000 emails depuis début 2019.
Nous avons adaptés nos emails également.
Aujourd’hui tous les emails pré-commande, contiennent obligatoirement un {Prénom} {NOM} dans l’objet
Nous n’avons plus que deux règles de blocage qui se déclenchent avec la présence de « *http* » ou de « */* » dans les objets.
Et Mandrill nous sauve une nouvelle fois le cul avec une autre faille insoupçonnée qui concerne notre formulaire de contact.
