Internet fraud costs victims millions of dollars each year. Protect yourself with Escrow.com!
Mon petit doigt me dit que cette entreprise va avoir un peu de mal à développer son activité sur les marchés francophones… Pourtant, elle a des atouts indéniables :
Il reste comme un malaise, non ?
Je n’ai pas trop l’habitude de présenter le « tout dernier service web qui va révolutionner la planète », d’autres le font bien mieux que moi et vous savez peut-être ce que j’en pense.
Je fais une exception avec CrazyEgg parce que je trouve l’idée simple et utile, le genre de truc qui facilite la vie. CrazyEgg analyse le comportement des visiteurs de votre site web. Vous me direz, le marché de l’analyse d’audience est loin d’être nouveau. Oui, mais ici, les résultats sautent aux yeux ! Ils permettent vraiment de travailler l’ergonomie de votre interface.
Là où les autres outils se contentent de dresser une vue globale des comportements (pages vues, pages populaires, pages d’entrée et de sortie, chemins de visites, etc.), CrazyEgg vous en donne le détail. La démonstration parle d’elle-même.
Dans son blog Actulligence, Frédéric Martinet nous donne un excellent exemple de la puissance de Google. Son article Trouver des fichiers multimédias avec Google contient une requête permettant de trouver tous les fichiers sonores (MP3 et WMA) contenant le terme nirvana. Résultat fort démonstratif qui peut être appliqué dans un contexte de veille active (par exemple, recherche de documents sensibles ou de copies illicites).
J’aime bien cet exemple parce qu’il exploite un défaut de configuration des serveurs web. En effet, si on effectue une requête sur un dossier qui ne contient pas de page index, le serveur web va (trop souvent) nous en montrer le contenu. C’est le cas pour toutes les pages trouvées par la requête de Frédéric Martinet. « Et alors, quel est le problème ? C’est un site web public ! » Oui, sauf que je connais beaucoup de gens pressés qui placent des contenus privés dans des dossiers publics en se disant : « qui va deviner que je place ce fichier à cet endroit ? »
Google le saura.
Vous me prenez pour un parano, hein ? Alors voici un exemple. WordPress, le moteur de blog que j’utilise, place tous les fichiers que je lui envoie, dans le dossier wp-content/uploads/. Celui-ci n’étant pas interdit d’accès (configuration par défaut de la majorité des serveurs mutualisés), on peut obtenir la liste de tous les médias de mon blog. A priori, ce sont les médias qui illustrent mes articles, donc pas de soucis. Et pourtant, il y en a un énorme : les fichiers des articles privés ou en cours de rédaction sont visibles par n’importe qui ! Si vous placez des rapports, documents, images et autres fichiers rien que pour vous ou vos proches, tout le monde en profitera, sachez-le !
On peut appeler ça une faille de sécurité, non ? Et comme je suis très joueur, un fichier appartenant à un article privé est placé dans mes médias. Je donne 72h à Google pour le trouver. Vous pouvez essayer aussi.
Mise à jour : Je suis parano ! Google n’a pas trouvé mon fichier. Son robot d’indexation est pourtant passé à plusieurs reprises, sans prendre en compte le dossier wp-content/uploads/. Vu le nombre de blogs tournant sous WordPress, Google a peut-être pris l’initiative de ne jamais indexer ce dossier-là. Par contre, d’autres « visiteurs » moins sympathiques m’obligent à protéger mon dossier wp-content/ : visiblement la liste de extensions installées (wp-content/plugins/) semblaient beaucoup leur plaire… La récréation est finie !
Et vous ? Avez-vous constaté des comportements étranges ou des attaques directes sur votre blog ? Comment le protégez-vous ?
Un internaute est un être précieux… mais volatile. Il suffit d’un détail pour que votre site passe aux oubliettes.
Dans la « top list » des petits trucs qui agacent : l’obligation d’entrer « www. » dans la barre d’adresse du navigateur pour accéder à un site. Quatre caractères qui n’apportent aucune information particulière, sauf celle de définir un site web (ce que l’on sait déjà puisqu’on utilise le protocole HTTP). Heureusement, la plupart des sites propose un accès via leur domaine seul (exemple.com) ou avec l’adresse complète (www.exemple.com).
Cependant, aux yeux des moteurs d’indexation, il s’agit de deux sites différents. Votre contenu sera donc diluer dans les index des moteurs de recherche. De même, les liens vers votre site ou son clone diminueront le « poids » de vos pages web (le fameux « page rank » de Google, par exemple).
Pour conserver l’avantage d’une adresse courte et éviter le double référencement, il suffit de placer ces lignes dans le fichier .htaccess situé à la racine du site :
Flux RSS des articles
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteRule (.*) http://www.exemple.com/$1 [QSA,R=301,L]
Cette règle de réécriture permettra au serveur de rediriger les visiteurs (et les moteurs d’indexation) vers l’adresse complète (www.exemple.com).
Pourquoi ne pas en profiter pour faire l’inverse, à savoir simplifier l’adresse en redirigeant vers le domaine seul ? Parce que la norme impose de garder « www » comme adresse principale d’un site web. Internet et les noms de domaines existaient bien avant le web (les premiers domaines en « .com » ont été achetés en 1985, cinq ans avant la naissance du web) et servent à d’autres services internet (messagerie, transferts de fichiers, surveillance réseau).
Google, Yahoo et Microsoft, frères ennemis ? Pas toujours ! Ils savent aussi travailler ensemble quand cela favorise leurs intérêts respectifs. Un exemple : le protocole Sitemap, initié par Google, fait maintenant l’objet d’un site dédié (sitemaps.org) et d’une licence Creative Commons pour favoriser son adoption. Autant dire de suite que Sitemap sera LE standard d’indexation du contenu des sites web.
Avec Sitemap, le webmaster reprend la main sur l’indexation de son site : il peut en décrire la hiérarchie, favoriser l’importance d’une page ou indiquer la régularité des mises à jour. Ces données sont stockées dans un ou plusieurs fichiers XML soumis directement aux moteurs d’indexation.
C’est toujours mieux que le simple fichier robots.txt, mais ce n’est pas encore la panacée. Sitemap est parfait quand la structure du site évolue peu. Par contre, lorsqu’à l’occasion d’une refonte, des contenus changent de rubriques, sont fusionnés ou éclatés, changent de domaine, Sitemap ne sait pas décrire ces changements. Certes, les codes de statut HTTP peuvent y remédier, notamment les 301, 302, 303 et 307, mais ils sont souvent mal exploités (quand ils le sont…) par les systèmes de gestion de contenu et sont plutôt destinés aux navigateurs web qu’aux moteurs d’indexation.
La bonne idée serait donc d’ajouter quelques balises dans les fichiers XML Sitemap pour indiquer les changements de structuration du contenu (suppression, déplacement, fusion, éclatement, pages liées, etc.). On pourrait alors se passer du fichiers robots.txt et de quelques balises META dans le code HTML de chaque page. On pourrait même imaginer se passer des codes de statut HTTP si le navigateur web savait exploiter les fichiers XML Sitemap. Il me reste à contacter les frères ennemis pour mettre tout cela en place !
|