Alban JAMESSE

Alban JAMESSE
Responsable E-commerce

#ecommerce, #internet &Co

   

Tombé dans le commerce tout petit, puis dans l'internet un peu plus grand;
Je fais du e-commerce activement depuis… trop longtemps.

Écoutez moi tous les matins sur Goood Morning Web

Contactez moi  
+33(0) 687.007.697


Votre message a bien été envoyé.

Votre message N'A PAS été envoyé.
Un problème est survenu. N'hesitez pas à me contacter par un autre moyen.

#Ecommerce

Quand Secure 3D dépouille le consommateur : 10 ans après

Quand Secure 3D dépouille le consommateur : 10 ans après

Il y a presque 10 ans, en novembre 2008, je publiais un article sur mon blog de l’époque (retrouvé à l’aide d’archive.org) où je disais tout le mal que je pensais du 3D Secure.

Mais je dénonçais surtout le transfert de la responsabilité en cas d’utilisation frauduleuse d’un moyen de paiement de la banque au client :

Et, cette fois ci, vous êtes totalement responsable en cas d’utilisation frauduleuse de votre carte.

[…]

Donc, un beau croche-pied à la protection du consommateur : avant vous étiez remboursé en cas d’utilisation frauduleuse de votre CB, aujourd’hui, si vous avez le malheur de vous plaindre à la suite d’une telle utilisation, la banque peut vous appliquer des sanctions supplémentaires en vertu du non-respect des moyens de sécurisation mis en votre possession.

Je viens de tomber* sur un arrêté de la cour de cassation qui porte toute la faute sur client : Phishing : négligence fautive du client de la banque

La faute à qui ?
À la petite carte dont je parlais dans mon article de 2008 !

Quand on fait des prédictions, on est souvent fiert et content quand ça tombe juste des années après.
Dans ce cas, je ne le suis pas. Au contraire.

* Suite à un tweet de @Korben

Proactivité

Proactivité

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é.

Nouvelle technique de spam

Nouvelle technique de spam

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 :

  1. de bloquer tous les emails vers des adresses emails en .ru, qui sont les cibles de cette campagne de SPAM
  2. 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é :

· 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.

 

· Naviguez ·
« Articles plus anciens · Articles plus récents »