edito-cinnk-magazine-sept-2015

Joomla! les 10 ans

Et oui, c'est la rentrée ! Mais pas question de reprendre le chemin de l'école ou du bureau sans notre dose mensuelle de Joomla!

Autopsie d'un crime en binaire

Quand un fantôme prend le contrôle ...

Je me flatte d'être plutôt attentif et conscient des problèmes de sécurité, étant tombé très tôt dans ce genre de soucis (Une attaque d'un réseau TSS (Time Sharing System) pour DPS 8 dans les années 80, les plus anciens apprécieront !), mais il faut bien reconnaître que sur ce coup-là je n'ai rien vu venir et ai été particulièrement long à réagir et à trouver une réelle et efficace parade. Je pense que mon expérience, toute récente, n'en sera que plus profitable à un grand nombre.

Autopsie d'un crime en binaire

La recherche des indices ...

Je gère un site personnel pour une communauté de joueurs français passionnés par un MMORPG américain. Une petite centaine de connexions journalières avec quelques pointes aux environs de 200 les jours où l'actualité communautaire est riche, c'est le lot quotidien du site. N'ayant rien à vendre, je n'examine pas Google Analytics très régulièrement, d'autant que j'ai placé côté administration un composant qui me fournit une information visuelle sur le trafic du site vue par Google.

Ceci étant campé, j'ai vu, il y a quelques semaines arriver dans la liste des top referrers (les sites ayant des liens activés vers mes pages) de nouveaux sites inconnus. Toujours flatteur à considérer. Sauf que, ces sites en question avaient un nom qui ne me disait rien qui vaille :

admin backend

floating-share-buttons.com, yourserverisdown.com, contextualyield.com, Get-Free-Traffic-Now.com etc., etc. et des tas d'autres de ce type, car la liste répertoriée est très, très longue (Cf. liste actuelle en fin d'article). Si vous n'utilisez pas ce composant backend, vous pouvez bien entendu accéder aux même informations via Google Analytics en sélectionnant pour une vue donnée : Acquisition > Tout le trafic > Site référents.

Je n'ai évidemment pas attendu qu'il y ait autant de clics activés pour agir. J'ai très rapidement utilisé ma suite de sécurité préférée pour bloquer les urls référentes concernées (Pour information il s'agit de la fonction 2.9 de Nono) puis j'ai oublié très vite l'incident... pas longtemps puisque les chiffres des clics vers mon site ont continué à grimper de manière excessivement flatteuse, très rapidement en quelques jours cela a culminé à 625 liens activés par l'url la plus active sur une durée de 30 jours Google Analytics fournissant ses rapports sur une période par défaut de 30 jours glissants.

L'enquête...

Le logiciel de sécurité ne réussissant pas à bloquer les fautifs en tant que sites référents, la démarche suivante a été de tenter de les bloquer à partir de leur adresse IP. Si pour une raison ou une autre l'interception du nom de référent dysfonctionne, le blocage par l'adresse IP, bien connu et bien maîtrisé ne peut que fonctionner, lui, non ?

Non : aucun effet, le nombre de clics continue de monter, le nombre de site 'étrange' aussi. Chou blanc sur toute la ligne ...

Un bon enquêteur ne s'avoue jamais vaincu. Puisque c'est ainsi, cherchons un autre moyen, retournons à la base : le log des activités HTTP fournit par tout bon hébergeur.

Rien. Pas une trace, aucune trame HTTP ne passe sous les IP concernées, ni pour les referrers renseignés.

Par où sont-ils passés ?

Le mystère de la chambre jaune ...

Pas de trame HTTP dans le journal du site, aucun moyen de bloquer ni l'IP ni le référent et pourtant, pourtant il y a bien une trace de main ensanglantée derrière la porte fermée de l'intérieur ! Au secours Gaston Leroux, à l'aide Rouletabille .... J'ai bien un crime sur mon site, mais il était totalement impossible de le commettre.

Comme dans tout bon roman policier, la lumière vient (juste au dernier chapitre) lorsque l'on prend les problèmes par le bon bout de la raison si cher à Rouletabille ou comme le dirait Hercule Poirot, lorsque toutes les autres options sont éliminées, la seule qui reste, aussi étrange que cela puisse paraître ne peut être que l'expression de la vérité.

Et comme il a raison le cher Hercule, si l'on part du principe que ce n'est pas mon site qui est hacké, mais Google Analytics lui-même, alors tout s'explique et tout s'éclaire.

La vérité vraie ...

La vérité toute simple, toute nue, est que quoi qu'on puisse en penser, les bases de données de Google Analytics ne sont pas hors de portée des petits futés, c'est même extrêmement simple d'y envoyer des données en s'appuyant sur l'API publiée par Google soi-même. Lorsque vous abonnez votre site auprès de Google Analytics vous obtenez un code javascript faisant référence à une librairie de programme et ressemblant à quelque chose comme ceci :

	(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
	  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
		m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
		  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
      ga('create', 'UA-12345678-1', 'www.sitedemo.fr');
      ga('require', 'displayfeatures');
      ga('send', 'pageview');
      setTimeout("_gaq.push(['_trackEvent', '20_seconds', 'read'])", 20000);
  

Code que vous devez intégrer à chacune des pages de votre site. Quand un visiteur (légal celui-ci) affiche une de vos pages, quelle qu'elle soit, le code ci-dessus s'exécute et envoie une requête HTTP à Google Analytics contenant un certain nombre d'informations, très grossièrement celles-ci sont :

  •  v=nn (la version Google Analytic)
  • &tid=UA-12345678-1 (votre identifiant API Key Google Analytic)
  • &cid=nnn (client ID Anonyme : 555)
  • &t=Pageview (Type  de traitement : Pageview, event, ...)
  • &dh=sitedemo.fr (document hostname, donc le referrer)
  • &dp=pagename (nom de la page visionnée)
  • &dt=pagetitle (titre de la page visionnée)

Le code javascript ci-dessus (fonction anonyme avec les paramètres (i, s, o, g, r, a, m)) émet une requête de type POST HTTP qui met à jour les données de votre site dans les bases de données de Google Analytics. Les données sont faciles à remplir dans ce mode de fonctionnement et sont prises directement dans le header HTTP préparé par Joomla!.

Quand  on connait l'adresse du site cible du POST, que l'on sait que les variables &cid et &dh ne sont pas contrôlées que les variables &dp et &dt sont des données, cela devient presque à la portée du premier imbécile venu de leurrer le roi Google ! Le code javascript contenu dans le fichier analytics.js est compact, mais pas impossible à décoder pour un informaticien normalement compétent.

Mais, me direz-vous la variable &tid n'est connue que de mon site et il faut passer par l'index.php de mon template pour espérer le connaître, dans ce cas je devrais voir un accès dans mes logs HTTP et je devrais pouvoir bloquer les méchants ?

Même pas ! Il suffit de générer les clés UA-xxxxxxxx-1 à la volée pour finir par tomber sur des clés valides, les autres passent à la trappe sans dommage. Pas beau ça ? Le crime parfait, pas de trace sur votre site, pas d'effraction constatée, seul Google Analytics est bombardé de données erronées et sans valeur, mais il s'en moque éperdument, ce ne sont pas ses données !

Mais alors où est le crime ?

C'est la beauté de la chose, il faudrait déjà prouver qu'il y a crime !

Votre site ne risque rien, pas de hack, pas de données dérobées, pas de code déposé, le hacker n'y passe même pas et ne sait probablement même pas qu'il existe, la seule chose qu'il connaît c'est votre code Google Analytics et il n'a aucun moyen de le relier à votre site, d'ailleurs il s'en moque son  but est ailleurs. Alors, pourquoi fait-il cela ? Le vieil adage policier : "Cherchez à qui le crime profite", nous enseigne que les crimes gratuits et qui ne rapportent rien sont plutôt rares ...

En fait, si comme moi, par curiosité vous allez voir ce qu'il y a sur un ou plusieurs des sites qui infectent vos données analytiques, funeste erreur, vous les aidez à vivre et probablement quelque part à gagner de l'argent. Leur seul but est de générer du trafic et occasionnellement vous rediriger vers un site commercial ou vous faire cliquer sur une bannière publicitaire ou encore profiter d'une pratique telle que celle proposée par des sites comme AliExpress Affilition. Imaginez les milliers (les millions ?) de POST qu'ils envoient journalièrement vers Google Analytics, si 1% des victimes vient sur leur site...

Site vide qui, soit dit en passant ne leur coûte quasiment rien, le premier de ma liste d'agresseur personnel, est hébergé chez 1and1.com au prix d'abonnement le plus bas.

La boutique

Trucs @ Astuces Joomla! 3Le livre 100 Trucs & Astuces pour Joomla! 3
vous permet de faire les bons choix parmi ceux qui s'offrent à vous lors de la création de votre site web ou lors de l'ajout de fonctionnalités ou d'extension grâce à de simple conseils, de vous simplifier la tâche grâce à des astuces et des mini-tutoriels pour gagner du temps dans la gestion de votre site Joomla!, ainsi que dans l'organisation de sa sécurité, son référencement, ses performances, et bien plus encore.

Si je ne risque rien, alors je m'en fiche...?

Oui... et non, Si vous avez un site commercial à gérer, il est probable que Google Analytics est une de vos premières sources d'informations, il est probablement vital pour vous de savoir par où passent les internautes qui arrivent sur votre site, quelles pages les attirent le plus, comment ils se décident à acheter tel ou tel produit, combien de temps ils passent sur telle ou telle page, ce qu'il vous faut corriger ou cibler. Comme la copie d'écran ci-dessous vous en convaincra facilement, ces petits malins démolissent totalement votre nombre de visites bien sûr, mais font aussi monter en flèche votre taux de rebond, puisque, nous l'avons vu, ils ne naviguent pas sur votre site (par définition ils n'y passent même pas), votre taux moyen de connexion chute drastiquement et la durée d'affichage moyen d'une page également.

 ga referent

 Alors, comment dois-je faire pour assainir mes données ?

Pour être tout à fait honnête il y a plusieurs solutions qui fleurissent sur le net ces temps-ci, je vais vous expliquer pourquoi elles ne me semblent pas correctes tout de suite, mais avant cela, il faut encore bien préciser à quelle type de menace vous avez à faire. En effet trois variantes successives de cette attaque ont fleuri ces derniers temps :

  • popov A Vitaly
  • spam referrer (semalt et autres)
  • ghost referrals (la dernière génération : les référents fantômes)

Popov A Vitaly

C'est l'auteur du principe de base, russe d'origine et très fier de son travail, il s'est exprimé dans de nombreux forums en expliquant que dans son pays ce genre de code est considéré comme une forme de commerce libérale et est encouragée (tu m'étonnes !). Démarré en décembre 2014 son code a commencé à infester les sites web, pas aussi efficace que les dernières moutures, il doit passer d'abord par votre site et peut donc être totalement bloqué par un filtrage des referrers dans votre .htaccess.

avitaly

 Spam referrer

Vieux comme l'internet, ils ont dû inspirer Vitaly pour son code d'attaque de Google Analytics, les codes s'appuyant sur ce principe sont bien plus anciens et s'ils utilisent un principe un peu similaire, ils passent en fait par votre site sans attaquer directement Google Analytics, c'est votre code analytics dans votre page qui envoie les données, de ce fait leur interception via un codage approprié de votre fichier .htaccess est bien suffisant dans la plupart des cas. Les plus célèbres sont semalt, darodar, il en existe des dizaines et ils sévissent toujours !

 Ghost referrals

Les plus vicieux de tous puisqu'ils ne s'occupent même pas de votre site et attaque directement Google Analytics comme nous l'avons vu dans l'enquête ci-dessus. Des solutions pour se débarrasser du problème fleurissent un peu partout en ce moment. Pour vous assurer tout de même qu'il s'agit bien de ghost referrals dont vous êtes victime, une simple petite modification provisoire du tableau de bord présentant la liste des référents, vous apportera une certitude. Il suffit en effet de rajouter une seconde dimension au tableau concerné : Dimension secondaire, puis  ouvrir Comportement et choisir "nom d'hôtes" pour ajouter cette colonne à l'affichage :

controle referent

L'absence de nom d'hôte est caractéristique d'une attaque de ghost referrals.

Parmi les solutions en vogue, les plus fréquemment proposées, on trouve :

  • blocage par le .htaccess
  • filtrage par exclusion dans Google Analytics
  • filtrage par segmentation dans Google Analytics

Aucune de ces trois solutions n'est parfaitement viable à mon sens.

 Blocage du .htaccess

Nous n'allons pas nous étendre sur cette solution, elle est ineffice dans le cadre des ghost referrals puisque, comme nous l'avons vu, les méchants ne passent pas par votre site. Toutefois, je vous conseille tout de même de placer une exclusion sur le champ HTTP_REFERER car ce sont exactement les mêmes noms de hôtes qui servent dans le cadre du spam referrer et des ghosts referrals. Le code à inscrire dans une section de votre .htaccess ressemble alors à quelque chose comme ceci :

htaccess

 Filtrage par exclusion dans Google Analytics

Sur le principe cela à l'air parfaitement viable et efficace, il s'agit dans Google Analytics de fournir la liste des noms de hôtes indésirables et de demander leur suppression des entrées dans la base de données. il n'y a que deux problèmes ! D'abord, l'exclusion n'est pas rétroactive et les données déjà existantes demeurent dans vos tableaux de bord et analyses diverses. Ensuite, si la saisie est assez facile et explicite, elle n'a pas tout à fait l'effet désiré, car, si Google Analytics parle d'exclusion, ce n'est pas dans le but d'enlever des gêneurs, mais de gérer des cas de figure telle que vous en rencontrez sur les sites commerciaux. Prenons un exemple, un visiteur achète un objet quelconque sur votre site et passe par le site Paypal pour exécuter son paiement. Vous ne tenez naturellement pas à voir le site Paypal comme un site référençant le vôtre, ce n'est pas votre intérêt, dans ce cas la solution est d'exclure Paypal de la liste des noms de hôtes référents et bien entendu de garder la trace de la visite et du temps passé sur votre page. C'est ce que fait (très exactement) l'exclusion de référent, en modifiant la visite en visite directe :

exclusion

Que ce soit au niveau du compte ou au niveau de chaque vue, exclure le référent de Google Analytics n'est pas une bonne solution dans le cas de spam constaté, car la visite (fictive) n'est  retirée ni de la liste des visites ni de la base de données.

Filtrage par segmentation dans Google Analytics

Compte tenu des problèmes liés à ce qui a été dit ci-dessus et du fait que les exclusions de référents ne correspondent pas tout à fait à la stratégie souhaitée pour le cas du spam, de petits malins ont trouvé qu'il valait mieux appliquer ce que Google Analytics présente sous le nom de segments.

C'est quoi ça un segment ? En fait c'est simplement une facilité donnée par Google Analytics pour filtrer à posteriori les données de vos tableaux et de vos rapports. Les données sont toujours présentes dans vos bases de données, mais vous signalez que vous ne voulez pas en tenir compte. Comme il s'agit d'un filtre à posteriori, cela semble magnifiquement s'adapter à notre cas et éliminer les données indésirables de vos tableaux. C'est vrai d'ailleurs, il faut le reconnaître, mais ...

Mais... moi j'appelle ça : "cacher la m... au chat". Si Google Analytics met ce moyen  à votre disposition c'est juste pour éliminer sciemment certaines données de la vue que vous souhaitez dans le but tout à fait louable de masquer certains détails d'un affichage trop lourd ou trop riche, pas de masquer le spam qui non seulement est toujours présent et va alourdir vos tables et traitements mais pourra également ressortir dès que l'on analysera les données brutes de votre site. Et rien n'empêche de penser que Google lui-même regarde ces données pour affiner votre ranking ou tout autre chose à sa convenance. En outre, créer un segment n'est pas si simple et ne s'applique qu'au niveau de la vue courante, il vous faut donc répéter votre paramétrage pour chacune des vues existantes sous peine de retrouver vos données falsifiées par les référents de type pourriels :

segmentation 

Ma solution pour régler le problème

Alors, quoi ? Comment peut-on se débarasser durablement du souci causé par les ghost referrals. Comme souvent le remède est simplissime, plutôt que d'exclure les données des référents spammeurs, il suffit de retourner leur arme contre eux-mêmes et pusiqu'ils ignorent tout de votre site, n'y passant même pas, il suffit d'utiliser les bases Google Analytics pour cette fois-ci placer un filtre au niveau du compte (donc une seule fois par site) et de filtrer non pas par exclusion, mais par inclusion en n'autorisant l'entrée de données que celles connues de votre site et des sites autorisées (Paypal par exemple).

L'opération s'effectue très facilement :

monsiteseulement

S'agissant d'un filtre vous pouvez ne l'appliquez que sur une des vues de votre site (pratique vous pouvez garder une vue sans la filtrer pour comparer les résultats) ou sur l'ensemble du site. Dans ce cas n'oubliez pas de sélectionner les vues sur lesquelles le filtre doit s'appliquer, dans le cas contraire : c'est raté !

Après il vous reste à faire preuve de patience, ce filtre, comme les filtres d'exclusion, n'est pas rétroactif, il vous faudra 30 jours, en moyenne, pour vous débarrasser définitivement des fauteurs de trouble. Si vous utilisez les filtres par vue (ce que je vous encourage à faire au moins en test), vous aurez la possibilité de cliquer sur un bouton de contrôle qui vous dira combien de sites auraient été exclus de vos données au cours des sept derniers jours. Pratique et instructif !

verification

Cela fait maintenant une dizaine de jours que cette méthode est appliquée sur mon site et en restreignant l'échantillonnage sur cette période, j'ai zéro ghost referral dans mes données analytiques, en outre et cela fait plaisir, cette méthode est recommandée dans un article paru le 2 Août (en même temps que je commençais la phase finale de mon enquête) sur le site moz.com, donc une référence dans le domaine!

 La liste des criminels !

La liste la plus exhaustive possible à ce jour des référents pourriels générant du ghost referral se trouve ci-dessous :

100dollars-seo.com generalporn.org semalt.semalt.com 
4webmasters.org get-free-social-traffic.com semaltmedia.com
76brighton.co.uk get-free-traffic-now.com seoairport.com
7makemoneyonline.com gobongo.info seoexperimenty.ru
adcash.com googlsucks.com seokicks.de
addons.mozilla.org guardlink.org serw.clicksor.com
adviceforum.info howtostopreferralspam.eu sharebutton.net
alienpayday hulfingtonpost.com sharebutton.org
amanda-porn.ga humanorightswatch.org similarpages.com
anticrawler.org ilovevitaly.co simple-share-buttons.com
artobox ilovevitaly.com floating-share-buttons.com
axisalternativementalhealth ilovevitaly.ru site12.social-buttons.com
baixar-musicas-gratis.com Iskalko.ru sitevaluation.org
best-seo-offer.com kambasoft.com slftsdybbg.ru
best-seo-solution.com lomb.co social-buttons.com
bestsub.com lombia.com socialseet.ru
bestwebsitesawards.com lumb.co sq01
blackhatworth.com luxup.ru success-seo.com
buttons-for-website.com make-money-online.7makemoneyonline.com superiends.org
buttons-for-your-website.com medispainstitute tasteidea.com
buy-cheap-online.info meendo-free-traffic.ga theguardlan.com
casinobonustips.com myftpupload.com torontoplumbinggroup.com
cenokos.ru netvibes.com torture.ml
cenoval.ru offers.bycontext.com traffic2money.com
chinese-amezon.com o-o-6-o-o.com trafficmonetizer.org
cityadspix.com o-o-8-o-o.com videos-for-your-business.com
civilwartheater.com paparazzistudios.com.au vitaly rules google
co.lumb pops.foundation vodkoved.ru
co.lumb.co powitania.pl webmaster-traffic.com
cukwiki.com priceg.com webmonetizer.net
cyprusbuyproperties.com prodvigator.ua website-errors-scanner.com
dailyrank.net ranksonic.info websites-reviews.com
darodar.com ranksonic.org websocial.me
depositfiles-porn.ga rapidgator-porn.ga webstatsdomain.org
descargar-musica-gratis.net resellerclub.com wpsecuritycheck.co.uk
e-buyeasy.com s.click.aliexpress.com wpthemedetector.co.uk
econom.co sanjosestartups.com www.event-tracking.com
edakgfvwql.ru satellite.maps.ilovevitaly.com www.Get-Free-Traffic-Now.com
entourank.com savetubevideo.info www1.social-buttons.com
erot.co screentoolkit.com ykecwqlixx.ru
forum20.smailik.org securesuite.co.uk ymlp.com
forum69.info securesuite.net youporn-forum.ga
free-floating-buttons.com see-your-website-here.com непереводимая.рф
free-share-buttons.com semalt.com  

 

La liste est à jour des dernières nouveautés connues, elle ne le sera probablement plus demain (peut être même déjà ?). Dans cette liste, j'ai été victime d'environ une quinzaine de ces spammeurs, j'espère ne plus en voir d'autres. Tant qu'ils ne trouveront pas le moyen de mettre mon nom de site en tant que nom d'hôte, la méthode que je vous ai proposé ci-dessus fonctionnera correctement. Vous remarquerez que la liste (triée dans l'ordre alphabétique) propose des urls non-cliquables, étant entendu que c'est de notre naïveté qu'ils vivent, nous n'allons plus leur faire ce plaisir, n'est-ce pas ?

Au passage, notez l'humour du petit malin qui a référencé parmi ces sites celui-ci : howtostopreferralspam.eu soit en bon français "Commentstopperlespamdereferrer.eu"

Notez cet article:
5
What Joomla! will look like in ten years
Quoi de neuf ce mois-ci ?

Commentaires 5

 
Guest - informaticien51 le mardi 1 septembre 2015 15:23

c est un bon exemple qui me permet de dire "il vaut mieux utiliser une extension interne" telle que extrawatch pour regarder et avoir une analyse de ce qui se passe sur son site.

Cela rejoint une problematique voisine a savoir, l utilisation de scripts externes a joomla.
Quand vous utilisez une ressource externe et que celle ci est indisponible, cela conduit directement à un plantage de celui ci sans solution autre que d attendre que la ressource soit a nouveau disponible..
Et la aussi les degats peuvent etre severe en matire de referencement....

c est un bon exemple qui me permet de dire "il vaut mieux utiliser une extension interne" telle que extrawatch pour regarder et avoir une analyse de ce qui se passe sur son site. Cela rejoint une problematique voisine a savoir, l utilisation de scripts externes a joomla. Quand vous utilisez une ressource externe et que celle ci est indisponible, cela conduit directement à un plantage de celui ci sans solution autre que d attendre que la ressource soit a nouveau disponible.. Et la aussi les degats peuvent etre severe en matire de referencement....
PieceOfCake le mercredi 2 septembre 2015 06:53

Quand vous utilisez une ressource externe et que celle ci est indisponible, cela conduit directement à un plantage de celui ci sans solution autre que d attendre que la ressource soit a nouveau disponible..


Dans l'absolu, c'est vrai, mais en l'occurrence sans rapport, le composant Google Analytics est désynchronisé et n'est absolument pas lié au site Joomla! qui l'utilise. Un visiteur légal qui visite un site l'utilisant, envoie des données via un POST HTTP comme je l'ai signalé dans l'article. Dans le cas où Google Analytiics est inaccessible (maintenance, plantage etc.), la requête envoie en retour un code erreur 404 ou un autre code en tout cas pas un code 200 (HTTP OK) qui ne peut avoir aucune influence sur les metrics du site concerné et en tout cas aucune en terme de référencement.... enfin je ne vois pas où se trouverait le risque.
Par contre les ghosts referals et autre hacks tels qeue ceux dénoncés dans l'article eux perturbent gravement l'analyse organique des visites sur le site au cas où l'on n'y prendrait pas garde

[quote]Quand vous utilisez une ressource externe et que celle ci est indisponible, cela conduit directement à un plantage de celui ci sans solution autre que d attendre que la ressource soit a nouveau disponible..[/quote] Dans l'absolu, c'est vrai, mais en l'occurrence sans rapport, le composant Google Analytics est désynchronisé et n'est absolument pas lié au site Joomla! qui l'utilise. Un visiteur légal qui visite un site l'utilisant, envoie des données via un POST HTTP comme je l'ai signalé dans l'article. Dans le cas où Google Analytiics est inaccessible (maintenance, plantage etc.), la requête envoie en retour un code erreur 404 ou un autre code en tout cas pas un code 200 (HTTP OK) qui ne peut avoir aucune influence sur les metrics du site concerné et en tout cas aucune en terme de référencement.... enfin je ne vois pas où se trouverait le risque. Par contre les ghosts referals et autre hacks tels qeue ceux dénoncés dans l'article eux perturbent gravement l'analyse organique des visites sur le site au cas où l'on n'y prendrait pas garde
informaticien51 le mercredi 2 septembre 2015 07:54

c est voisin:
dans les deux cas il s agit de l'utilisation d'une ressource externe au site.

Ce que je voulais dire, c est que ce soit GA ou toute autre ressource externe au site, il faut au maximum éviter de les utiliser sous peine de problèmes...

un autre exemple que je peut te donner, c est un module crée avec la version de jquery 1.8 et qui plantes du jour au lendemain l 'affichage d'un site.

Pourquoi ?
tout simplement car la version de jquery courante étant la version 1.11, le module utilisant des fonctions jquery dépréciées et supprimées, le script plantes...
Un autre danger des ressources externes.
Et trouver ce genre de dysfonctionnement ne peut pas être fait par un novice....

Même si celui que j évoques est différent du tien, dans les deux cas, il s agit d une fortune pour les marchands d aspirine, donc autant eviter de les enrichir. ^^

Et aussi merci pour ton article, c est une bonne source de réflexion...

Quand a Google j ai pris le parti de m adresser aux moteurs de recherches en général et non spécifiquement a lui....
Orienter son site vers Google est une erreur selon moi... Mais c est une discussion qui n as pas sa place dans ce fil de commentaires.

c est voisin: dans les deux cas il s agit de l'utilisation d'une ressource externe au site. Ce que je voulais dire, c est que ce soit GA ou toute autre ressource externe au site, il faut au maximum éviter de les utiliser sous peine de problèmes... un autre exemple que je peut te donner, c est un module crée avec la version de jquery 1.8 et qui plantes du jour au lendemain l 'affichage d'un site. Pourquoi ? tout simplement car la version de jquery courante étant la version 1.11, le module utilisant des fonctions jquery dépréciées et supprimées, le script plantes... Un autre danger des ressources externes. Et trouver ce genre de dysfonctionnement ne peut pas être fait par un novice.... Même si celui que j évoques est différent du tien, dans les deux cas, il s agit d une fortune pour les marchands d aspirine, donc autant eviter de les enrichir. ^^ Et aussi merci pour ton article, c est une bonne source de réflexion... Quand a Google j ai pris le parti de m adresser aux moteurs de recherches en général et non spécifiquement a lui.... Orienter son site vers Google est une erreur selon moi... Mais c est une discussion qui n as pas sa place dans ce fil de commentaires.
HdCms le lundi 12 octobre 2015 21:03

Bonsoir,
Ok le crime est là mais que d’énergie dépensé !?
Il y a peut-être une autre piste pour se déplacer de ces importuns
Le principal concurrent libre (comme jooomla)
http://piwik.org/
et n'ayant pas la taille critique pour attirer les pirates si des fois il ne verrouillait pas mieux sa base (que l'on gère)

Bonsoir, Ok le crime est là mais que d’énergie dépensé !? Il y a peut-être une autre piste pour se déplacer de ces importuns Le principal concurrent libre (comme jooomla) http://piwik.org/ et n'ayant pas la taille critique pour attirer les pirates si des fois il ne verrouillait pas mieux sa base (que l'on gère)
PieceOfCake le vendredi 16 octobre 2015 18:54

Pour ce que je sais de piwik, la base de données fait partie de ton site et est plutôt gourmande en bande passante ainsi qu'en volumétrie (espace disque).
L'intérêt de mettre une base de données telle que celle considérée chez un prestataire comme Google est de se défausser de la partie sécurité (en l'occurrence c'est raté, sauf à appliquer les remèdes proposés dans l'article). Si ta base piwik est piratée il y a de bonnes chances que ton site l'ait été aussi, donc tu as effectivement un énorme avantage avec piwik, en cas de hack tu perds sur tous les tableaux (cette réflexion est bien entendu à prendre au deuxième degré ... au moins).
Je veux juste rappeler ici un des principes de base généralement considéré comme bon : ne pas installer de plugins dans Joomla! si vous pouvez faire autrement. Google Analytics répond parfaitement à ce critère et en plus fournit un service appréciable et assez complet (gratuitement qui plus est), donc de l'énergie dépensée oui, mais à bon escient (enfin il me semble)

Pour ce que je sais de piwik, la base de données fait partie de ton site et est plutôt gourmande en bande passante ainsi qu'en volumétrie (espace disque). L'intérêt de mettre une base de données telle que celle considérée chez un prestataire comme Google est de se défausser de la partie sécurité (en l'occurrence c'est raté, sauf à appliquer les remèdes proposés dans l'article). Si ta base piwik est piratée il y a de bonnes chances que ton site l'ait été aussi, donc tu as effectivement un énorme avantage avec piwik, en cas de hack tu perds sur tous les tableaux (cette réflexion est bien entendu à prendre au deuxième degré ... au moins). Je veux juste rappeler ici un des principes de base généralement considéré comme bon : ne pas installer de plugins dans Joomla! si vous pouvez faire autrement. Google Analytics répond parfaitement à ce critère et en plus fournit un service appréciable et assez complet (gratuitement qui plus est), donc de l'énergie dépensée oui, mais à bon escient (enfin il me semble)
Déjà inscrit ? Connectez-vous ici
Guest
jeudi 5 décembre 2019
Si vous souhaitez vous inscrire, veuillez saisir un nom d'utilisateur, mot de passe et nom.

Image Captcha

Sur ce site, nous utilisons des cookies.