Protection des fichiers image et texte et bande passante

All contributions published for previous SPIP versions

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.

updated on 3 August 2009

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

    Reply to this 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

    Reply to this message

Comment on this article

Who are you?
  • [Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom