Protection des fichiers image et texte et bande passante

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Description de solutions possibles pour proteger textes, images, et bande passante.

Par KMacleod
Article publié en intégralité sur webntic.

Plusieurs phénomènes peuvent griser le moral d’un Webmaster heureux, voir que ses images et logos sont copiés dans des forums, des blogs et autres sites internet ; voir que ses textes et autres publications alimentent par des copiés collés innocents des discussions de forums ; voir enfin que régulièrement la bande passante est utilisée par des aspirateurs et non des visiteurs. Heureusement, des solutions sont là.

Ici, ne seront traitèes que les solutions PHP / apache et sur Webtnic pour les aspects protection des fichiers par javascript.

La protection des images.

Quel est le problème ?
L’internaute fait un copier coller de l’image ou de l’url de l’image pour copier le tout dans un forum, un blog ou un autre site web. A chaque visite de ce site, l’image est affichée et consomme la bande passante du site hébergeur ; pour peu que l’internaute indelicat ait choisi comme avatar une image de votre serveur et que celui ci ait une grande popularité sur son forum ; voila votre bande passante utilisée à vos depends.

-  Contre la copie de l’url ou un lien direct vers une image, un fichier :
Directement il n’est pas possible de faire quoi que se soit.
Indirectement, il est cependant possible d’empécher que l’image, le fichier soit disponible

-  Explications :
Comment faire pour éviter que des sites externes fassent des liens sur vos fichiers au détriment de votre bande passante.

-  Le principe :
Il s’agit de détecter l’origine du visiteur, pour une certaine catégorie de fichiers identifiés par leur extension, puis d’interdire l’acces pur et simple

-  Coté methode :
C’est par le fichier .htaccess avec le mode rewrite du serveur apache actif que cette interdiction pourra être mise en place, ce qui signifie que les webmasters n’ayant pas accés à ce fichier ou ce mode rewrite au niveau du serveur, doivent utiliser une autre technique

-  Coté technique :
Il s’agira simplement de renseigner dans le fichier .htaccess, le mode rewrite et ensuite d’interdire l’acces selon la syntaxe suivante

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://votresite.tld
ReWriteRule .*\.(gif|png|jpe?g)$ - [F]

Ce qui se traduit en langage naturel par :
• Pour tout referent non vide (cas d’un visiteur direct) et pour un referent different de votre nom de domaine,
• Les fichiers de type gif ou png ou jpg ou jpeg sont interdits.
D’autres extensions peuvent être rajoutées selon vos besoins (pdf, mpeg, mp3, mid, swf ...)

Pour plus d’infos sur cette technique, voyez l’article consacré au
fichier .htaccess - et la mise en place de l’url rewriting
-  Les limites :
Cette technique, si elle ne protège correctement votre bande passante, n’interdit pas pourtant les accés au serveur et générent tout de même un acces fichier.
De plus, dans le cadre des fichiers images, le visiteur qui fait un lien sur votre fichier a, au préalable, visité la page où se trouve le fichier en question. Il a donc votre fichier image dans le cache de son navigateur. Lorsque il publie, par exemple dans un forum, le fichier image par un lien de type

il verra bien l’image dans son post donc ne sait pas que cette image ne s’affichera pas. Les autres visiteurs qui liront le message ne verront eux que la croix rouge caractéristique d’une image inaccessible.

Cette protection par le .htaccess peut donc être insuffisante, il serait plus judicieux de mettre sur ses pages d’images, un avertissement.

La protection de la bande passante

Dernier volet pour le webmaster désirant protéger son contenu, la protection par rapport aux aspirateurs de site ou robot indélicats.
-  Quel est le problème :
Face à la montée en charge anormale du traffic de son site, parce qu’un visiteur indélicat utilise un programme aspirateur de site, que peut faire le webmaster. Plusieurs solutions :
-  Un fichier de configuration empêchant l’accés à certains robots avec le fichier robots.txt. (Ce fichier robots.txt est un fichier texte, qui se trouve de manière unique à la racine du site, et dans lequel se trouve des informations à destination des robots d’indexation).
L’inconvenient est de devoir connaître ces robots aspirateur par leur nom d’agent et de maintenir à jour cette liste
-  Un fichier de contrôle d’acces des aspirateurs interdisant l’acces avec le fichier .htaccess.

L’inconvenient tient également au fait que cette programmation n’est pas générique et nécessite de maintenir à jour la liste des robots.
Et dans ces cas où le robot ou le programme aspirateur passe outre ces deux barrières, il ne reste rien d’autre que le fichier script.

-  Le script anti aspirateur :

C’est ce que nous propose ce script anti aspirateur.
Son principe est de déterminer le nombre de pages visitées en une minute, au delà d’un certain nombre de pages, ce n’est pas un visiteur normal, mais un logiciel ; dans ce cas alors le visiteur est bloqué, plus aucune nouvelle page ne lui est délivrée.
Du coté des moteurs de recherche, le script fonctionne également et un moteur trop gourmand qui indexe tout le site trop rapidement se vera également bloqué.

-  Mais l’indexation par les moteurs de recherche ?
Ce script fonctionne très bien avec les grands moteurs de recherche qui ont comme règle de respecter le trafic et la bande passante des serveurs qu’ils indexent.

-  Et coté technique ?
Ce script anti aspirateur est écrit en php et utilise deux tables en base de donnée Mysql. Il peut se mettre aisement dans un fichier header pour couvrir tout le site

-  Implémentation sous SPIP
Le script anti aspirateur de site a été implémenté dans un site sous SPIP en local puis testé en ordre de marche normal et en mode dégradé.
Installation
Le script a été rajouté dans le fichier inc-public.php3 avec la ligne suivante :
include($DOCUMENT_ROOT.« /trace_ip.php ») ;
Les tests
Deux tests ont été menés
Les tests ont consisté a faire tourner un robot /aspirateur de site en jouant sur le nombre de pages aspirées par minute.
La valeur mini correspond à une seule page lue à la fois, la valeur maxi était 100 pages lues en même temps.
Dans le permier cas toutes les pages ont été accédées (valeur mini), dans l’autre cas quelques pages ont été lues (valeur maxi) et le script anti aspirateur a interdit la suite de l’aspiration en bloquant l’adresse IP.
Une analyse du fichier log apache a permis de vérifier que seules les pages du caches ont été lues, il n’y a pas eu de recalcul de pages.

Ces techniques proposent des modes de protection differents. La protection concernant la bande passante est un problème serieux pour un webmaster, car elle interesse non plus le contenu du site mais le serveur, avec des caractéristiques sensibles. Le script anti aspirateur étant générique, il peut apporter une solution interessante, adaptable à la problèmatique propre d’un site.

Discussion

2 discussions

  • Quelques questions concernant ce script :

    . est-il adaptable à la version SPIP 1.8 ?

    . pour l’accès à la base de données, pourquoi ne pas laisser faire SPIP et transformer le fichier trace_ip.php (passer à trace_ip.php3 ?) de manière à include_ecrire(inc_version...), etc.. : l’accès à la bdd est automatique. On pourrait aussi remplacer les mysql_query par des spip_query.. Seule l’instruction mysql_close serait à affiner ?

    . enfin, les structures des tables sql ip et ip_bl pourraient être intégrées à inc_base (et ses auxiliaires) directement dans SPIP ?

    . idem enfin pour l’adresse d’envoi, qui peut être #EMAIL_WEBMASTER.

    Tout ceci à voir..

    Répondre à ce message

  • 1

    Bonjour,

    J’ai implanté trace_ip sur SPIP en :
    1. Configurant trace_ip
    2. en mettant include($DOCUMENT_ROOT.« /trace_ip.php ») ;
    dans le fichier inc_public en deuxième ligne juste après le code

    <?php. 
    
    J'obtiens le message d'erreur suivant :
    Warning: mysql_query(): Access denied for user: 'apache@localhost' (Using password: NO) in /home/botanique/domains/botanique.org/public_html/ecrire/inc_db_mysql.php3 on line 25
    
    Savez-vous d'où cela peut venir ?
    Merci par avance,
    VIncent
    
    A priori, j'ai défini correctement les bonnes variables suivantes :
    $dbhost = "localhost";
    $dbuname = "mon_login";
    $dbpass = "mon_mot_de_passe";
    $dbname = "mon_nom_de_base_db";
    
    
    
    • Arnaud Dupin de Beyssat

      J’ai exactement le meme pb.
      Ya quelque chose qui cloche.
      ADB

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom