Etude de Cas - Alerte Hameçonnage Google Chrome.. Réflexion

[Mehdi]

J'aimerais avoir vos avis et retours d'expériences sur cette fameuse page rouge de chrome qui apparaît inévitablement sur nos domaines après un certain volume sur des LPs un peu borderline (principalement antivirus et sweepstakes)..

C'est relativement simple à fixer, un changement de domaine, voir même juste de dossier suffisent en général, le problème est la détection, vu que le ctr% ne passe pas à un 0% tout rond, c'est pas évident de s'en rendre compte au milieu de plusieurs campagnes.

Sachant que cette alerte est liée à Google Chrome, une simple analyze en file_get des LPs ne fonctionnera pas...

Des idées ?



Mehdi

PS : Visuel de l'erreur

 

[ChristopheReflexcash]

On a eu ce soucis chez Reflex avec un nom de domaine : on l'a changé.
Après pour s'en rendre compte, a moins de surveiller une baisse drastique du CTR j'en ai pas la moindre idée.
Programmer peut être un système d'alertes si le CTR passe en dessous d'un certain seuil ?

 

[analchik]

Ca demandera forcément un peu de dév de le détecter automatiquement mais par exemple tu peux faire passer le visiteur par une page avant la landing page qui va créer un id unique, le mettre en bdd et rediriger vers la landing page en le passant en GET, sur la landing page afficher une image 1x1 avec en paramètre cet id, le script passant au status "affiché" l'id en bdd. Comme je suppose que chrome empêche l'affichage de la page quand cette alerte apparait il suffit d'avoir une tache cron qui vérifie chaque minute le % d'id non "affiché" dans la bdd sur les 50 derniers enregistrements et si il dépasse XX alors ca t'envoi un mail.

Le process doit même pouvoir être simplifié en faisant le check de l'id direct en php sur la LP, à voir comment chrome fonctionne..

 

[Mehdi]

ChristopheReflexcash oui effectivement changer le ndd règle le soucis.

Surveiller le ctr% via un script qui le choppe depuis le tracker est une des idées, mais pas applicable partout car certaines campagnes ont des ctr% "normaux" à 20% tandis que pr d'autres campagnes la normal est à 1% .. ça complique.

analchik faudrait voir comment faire pour tester ça sur un tout petit % du traffic de la campagne, sinon rajouter un redirect dans la chaîne sur une campagne mobile par exemple ça peut tuer le ROI.. mais oui c'est une idée en effet



Mehdi

 

[Mehdi]

J'ai aussi exploré les services comme virustotal et autres qui permettent de checker si une url est flaguée sur différents organismes (antivirus, chrome, etc ..), le problème est qu'ils communiquent toutes les urls testées à ces mêmes organismes... ce qui reviendrait à s'auto-dénoncer à chaque test



Mehdi

 

[analchik]

Pourquoi ca pourrait tuer le ROI, ca rame une redirection sur mobile?

analchik faudrait voir comment faire pour tester ça sur un tout petit % du traffic de la campagne, sinon rajouter un redirect dans la chaîne sur une campagne mobile par exemple ça peut tuer le ROI.. mais oui c'est une idée en effet

Mehdi

 

[Mehdi]

Pourquoi ca pourrait tuer le ROI, ca rame une redirection sur mobile?

Oui, y'a généralement une redirection juste pour le double meta refresh, plus le click loss entre la source de trafic et la LP, en rajoutant une autre redirection juste pour ça ça affectera inévitablement le ROI de façon négative.. la vitesse de chargement de la LP en particulier sur le mobile est vitale.

Après ça n'empêche pas que l'idée est bonne, ça marcherait bien sur des campagnes à gros volume, à coup de 1M de view/jour c'est possible de l'appliquer à seulement 5% du trafic par exemple tout en ayant un résultat significatif.


Mehdi

 

[pol]

J'ai l'impression que Edge et son "Microsoft SmartScreen" ils sont encore plus au taquet que Chrome.
Il m'avait bloqué mon domaine pas mal de temps avant chrome et je tombe sur pas mal de pop up redirigeant vers l' "alerte hameçonnage" quand je vais sur des sites de stream depuis la xbox one ou on est obligé de se farcir Edge .

Si vous en avez , vérifier de temps en temps votre traff venant de Edge/internet explorer voir si quelque chose cloche. Vu que c'est un navigateur minoritaire , on peut ne pas forcément le remarquer sur les stats globals

 

[Olaf]

Google safe browsing a une API doit donc y avoir un moyen de vérifier ses LP quotidiennement.
Si la page ne contient pas d'autodownload avec un fichier reconnu comme virus, je ne vois pas pourquoi google la concidererait comme dangereuse.
Google Safe Browsing | Google Developers

J'ai été confronté au problème pour la première fois il y a 3 jours. Juste l'url et le simple fait de changer le nom du html était suffisant. C’était pour du TRIAL CC et je supposes donc un ajout manuel a la base par un visiteur.

 

[Mehdi]

J'ai l'impression que Edge et son "Microsoft SmartScreen" ils sont encore plus au taquet que Chrome.
Il m'avait bloqué mon domaine pas mal de temps avant chrome et je tombe sur pas mal de pop up redirigeant vers l' "alerte hameçonnage" quand je vais sur des sites de stream depuis la xbox one ou on est obligé de se farcir Edge .

Si vous en avez , vérifier de temps en temps votre traff venant de Edge/internet explorer voir si quelque chose cloche. Vu que c'est un navigateur minoritaire , on peut ne pas forcément le remarquer sur les stats globals

C'est clair que c'est un petit pourcentage qui passerait totalement inaperçu! Good tip

Google safe browsing a une API doit donc y avoir un moyen de vérifier ses LP quotidiennement.
Si la page ne contient pas d'autodownload avec un fichier reconnu comme virus, je ne vois pas pourquoi google la concidererait comme dangereuse.
Google Safe Browsing | Google Developers

J'ai été confronté au problème pour la première fois il y a 3 jours. Juste l'url et le simple fait de changer le nom du html était suffisant. C’était pour du TRIAL CC et je supposes donc un ajout manuel a la base par un visiteur.

Justement je pense que checker sur google safe browsing ou autres bases du genre déclenche des tests et peut donc entrainer un flag plus rapide

Des infos que j'ai eu sur STM aussi, même des offres flaggés dans le funnel peuvent conduire au flag de la LP et/ou domaine.



Mehdi

 

[william]

Justement je pense que checker sur google safe browsing ou autres bases du genre déclenche des tests et peut donc entrainer un flag plus rapide

Je ne pense franchement pas et si c'était le cas ça serait un gros problème, n'apporte qui pourrait checker ses concurrents et donc les flagger plus rapidement...

 

[Mehdi]

Je ne pense franchement pas et si c'était le cas ça serait un gros problème, n'apporte qui pourrait checker ses concurrents et donc les flagger plus rapidement...

Logiquement oui, pourtant c'est bien le meme principe sur lequel repose le negative seo il me semble ..

C'est quitte ou double en gros, et si personne sur STM n'evoque cette solution c'est bien que les gens ont peur de tester, sinon pinger une API pour se simplifier la vie et economiser des milliers de $... Il y'aurait meme des services qui proposent ca directement ^^


Mehdi

 

[william]

Logiquement oui, pourtant c'est bien le meme principe sur lequel repose le negative seo il me semble ..

C'est quitte ou double en gros, et si personne sur STM n'evoque cette solution c'est bien que les gens ont peur de tester, sinon pinger une API pour se simplifier la vie et economiser des milliers de $... Il y'aurait meme des services qui proposent ca directement ^^


Mehdi

Oui en effet! Il y a l'API VirusTotal (FAQ - VirusTotal) je vais tester ça couplé à un script d'alerte par email...

 

[Will]

cela peut peut-être répondre à votre demande ce type de service: Safe Browsing Tool | WOT (Web of Trust)

 

[Olorin]

J'ai été confronté à cette problématique ce printemps alors que j'étais sur une grosse campagne (plusieurs millions pops/jours).
Le seul moyen que j'ai trouvé à l'époque était de changer le sous-domaine des LPs quelques fois durant la journée et de changer de domaine 2-3 fois par semaine.

Sur STM j'avais vu passer une annonce pour un service de détection qui envoi un SMS: Traffic Protector | Get notified when something is wrong
Mais jamais testé.

 

[Mehdi]

J'ai été confronté à cette problématique ce printemps alors que j'étais sur une grosse campagne (plusieurs millions pops/jours).
Le seul moyen que j'ai trouvé à l'époque était de changer le sous-domaine des LPs quelques fois durant la journée et de changer de domaine 2-3 fois par semaine.

Oui c'est ce que tout le monde fait je pense, en essayant de mettre en place des système/process pour pouvoir switcher de ndd rapidement, le plus chiant étant les modifcations bulks à faire sur Voluum mais ils sont en passe d'implémenter la fonctionnalité, ça en réjouira plus d'un je suis sûr

Sur STM j'avais vu passer une annonce pour un service de détection qui envoi un SMS: Traffic Protector | Get notified when something is wrong
Mais jamais testé.

Intéressant, à voir comment ils détectent le browser flagging, si c'est une techno propre qui fait pas appel à virustotal ou l'api google, car sinon $99/mois pour un bête appel API (risqué qui plus est) ça vaut pas la peine.


Mehdi

 

[Mehdi]

Comme je l'ai dit sur STM, une des solutions pourrait être une page "monitor" qui récupère la liste des LPs actives depuis l'API de voluum (ou autre tracker) et les affiche sous forme de thumbs wall dans des petits blocs iframe 300x250, pour pouvoir spotter directement les petits carrés rouges.

C'est à tester, car pas impossible que l'alerte surgisse sur la page monitor en entier rendant impossible de savoir quelle iframe a généré l'alerte..


Mehdi

 

[Mehdi]

Résolu !!

Safe Browsing Update API (v4)

Google fournit une base de données d'URLs à checker localement, qui utilise des HASH au lieu des urls et il ne peut donc (théoriquement) jamais voir les urls checkées.

"At no point does Google learn about the URLs you are examining. Google does learn the hash prefixes of URLs, but the hash prefixes don’t provide much information about the actual URLs."

FR : A aucun moment Google n'obtient d'informations sur les URLs que vous examinez. Google reçoit le hash prefix de l'URL, mais le hash prefix ne fournit pas (trop) d'informations sur l'URL en elle même.

Comment mettre ça en place :

A moins que vous ne soyez développeur, en ayez un disponible, ou impatient, je vais faire développer ça et le fournir en tant que tool téléchargeable et instalable sur votre propre serveur pour que personne d'autre que vous ne puisse voir vos URLs de LPs.

EDD : fin Août



Mehdi

 

[paul]

Du coup Google fournit une solution clé en main pour savoir si un NDD a été blacklisté ou pas ?

C'est un peu comme si la police donnait à tout le monde la liste entière des gens qu'elle recherche non ? lol

 

[Linuxma]

Il y a une solution mais en passant par ZenoPoster : Simuler le user agent Chrome et lancer un check chaque heure par exemple ou moins. C'est simple et facile à mettre en place.