[Cookies] Empécher affichage images par url directe, juste par <img

[Galak`]

J'ai pas encore fait le tour de toutes les possibilités, mais pour un futur site d'e-commerce, j'aurais besoin d'empécher l'affichage des images de certains dossiers lorsqu'on saisi directement l'url de celles-ci. En gros, il y a des visuels soumis par des graphistes, et certains sont retenus pour la vente. A partir de l'url d'un de ces visuels en vente, on peut facilement trouver l'url d'autres visuels normalement inaccessible. Le vendeur souhaiterait évidemment que la concurrence ne puisse pas accéder aux visuels qui n'ont pas encore été mis en vente pour éviter tout vol.

Il y a plusieurs solutions :

- La protection par .htaccess basée sur le referer, protection déjà en place mais qui n'est pas activée lorsqu'il n'y a pas de referer. Ca fonctionnerait en refusant aussi l'accès quand il n'y a pas de referer, mais pas mal d'outils masquent ce référer, donc pas bon

Code :

1
2
3
4
 
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^/]*)domain.tld/?.*$ [NC]
RewriteRule .*\.(jpe?g|gif|png|bmp)$ - [F,NC,L]

- Par url-rewriting, une redirection des adresses des images vers un script php qui vérifie le droit d'accès à cette image et la renvoi via des headers et un readfile. Le problème est que dans mon cas, cette solution ne peut marcher qu'en effectuant au moins une requête pour vérifier si le visuel fait parti de ceux qu'on peut afficher, ce qui commence à faire lourd en plus de l'envoi "manuel" du "contenu" de l'image, d'autant plus qu'il peut y avoir pas mal de ces visuels sur certaines pages.

Code :

1
2
3
 
RewriteEngine On
RewriteRule .*\.(jpe?g|gif|png|bmp)$ /secureimg.php [NC,L]

- On peut aussi remplacer les liens vers les images par l'appel d'un script qui fait plus ou moins la même chose que celui de l'exemple précédent, en ajoutant un .htaccess deny from all. Mais bon, si le lien direct ne passe plus, on peut sans problème afficher l'image depuis l'url du script, sauf si-celui ci effectue aussi une requête pour vérifier le droit d'affichage de l'image. Et la ca n'a plus vraiment d'interêt par rapport à la solution précédente qui est plus transparente (on désactive l'htaccess, et ca supprime la protection, sans avoir a modifier quoi que ce soit dans les sources html/php)

- Pour essayer d'économiser toute requête sql, on peut envisager la solution précédente en ajoutant par exemple le timestamp actuel en paramêtre, le script ne retournant l'image que si ce timestamp n'est pas dépassé de plus de X secondes. Mais il faut que X soit suffisamment grand pour que ca couvre l'écart entre la génération de la page et le début du chargement de la dernière image dans le cas ou ca rame. Et ca n'empeche en rien l'affichage depuis l'url si le "concurrent" est assez futé pour saisir à la main un bon timestamp dans l'url.

Finalement :

En clair, je me demande s'il y a une solution permettant d'éviter toute requête.
Plutot que faire des vérifications sur les droits, la solution recherchée serait plutot de déterminer si l'image est appelée directement depuis la barre d'adresse ou par l'intermédiaire d'une balise <img>, mais sauf erreur de ma part (à 6h du mat j'ai plus toute ma tête :p), les navigateurs récupèrent l'image de la même facon dans les 2 cas, sans différence d'header, et donc sans moyen de détecter ca de facon générique.

Si quelqu'un a de quoi confirmer ou infirmer cela, le temps que je fasse quelques recherches de plus, qu'il n'hésite pas à user son clavier dans le coin

PS : Je poste dans la rubrique PHP parce que la plupart des solutions possibles, et celle qui sera probablement retenue, font fortement appel à PHP, meme si une éventuelle (mais peu probable) solution permettant de déterminer si l'appel se fait par la balise <img> ne fera probablement pas appel directement à php

[M4x]

Question intéressante, dont je ne détiens pas la réponse mais je suis aussi assez intéressé. Je me serai contenté de l'.htaccess qui bloquerait quand même une majorité d'utilisateurs (je suppose que tu fais références à des proxys voire firewalls pour ce qui est de fausser les referers).

[Galak`]

Oui par exemple.

Pour l'instant, je vais surement partir sur la solution des urls vers les images renvoyées via url-rewiting vers le script php, qui va effectuer une requête pour vérifier si on affiche ou non le visuel, en mettant cette requête en cache. Avec possibilité de le désactiver depuis l'interface admin du site. Je pense qu'une requête en cache + le retour de l'image via readfile (avec gestion du cache du navigateur, donc pas envoi systématique) ne devrait pas être eccessivement lourd sur le frontend ou il n'y aura en général que 1 à 8 visuels maxi.

L'inconvénient, c'est que cette solution prend en compte tous les appels depuis la balise <img>, et donc risque d'être un peu lourde dans les pages listant pas mal de visuels dans l'interface admin (sans compter la création multiple de fichiers cache sql dans le dossier de cache).
Mais il n'y a pas vraiment de solution pour autoriser les balises <img> dans l'interface admin tout en interdisant l'accès direct (sinon ca répondrait à la question principale du post, et la solution de la redirection vers un script php n'aurait plus lieu d'être)

[Mr N.]

Pourquoi ne sortirais-tu pas tes images de l'espace web, ainsi elle ne sont pas visible par apache (donc pas visible par aucun navigateur web), et tu ecris un script php qui 1) vérifie les droits 2) affiche l'image :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<?php
 
$image = get_image_from_request();
 
if (user_can_see_image($image)) {
   header('Content-type: image/png');
   readfile('/path/to/restricted/images/'.$image);
} else {
   header('Content-type: image/gif');
   readfile('forbidden.gif');
}
?>

Code :

<img src="getimage.php?id=42335" />

[Galak`]

Qu'il y ait un acces restraint par htaccess ou que les images soient en dehors de l'espace web ne change rien au problème, qui réside plus dans la fiabilisation et l'allègement et la vérification du droit d'affichage.

Je vais voir ce que ca donne à l'usage en mettant en session un tableau avec pour clés tous les visuels affichés sur la page (et sur toutes les pages de la session, pour qu'il n'y ait pas de merde lors du chargement de 2 pages en même temps).
Le script php vers lequel est redirigé l'appel d'une image se contentera de vérifier l'existance de l'id de l'image dans les clés du tableau.
Pour fiabiliser le bon suivi de la session en cas de refus des cookies par exemple, je l'ajoute dans les liens des images, genre img/items/item_5.jpg?PHPSESSID=ba91ef2657da4e9bef46aac4a268b0d8

Vu le relatif faible nombre de visuels sur la plupart des pages (quoique sur certains ca peut monter), ca devrait ête assez léger, et de toute facon désactivable si ca devient trop lourd avec le temps.

[Mr N.]

Envoyé par Galak`

Qu'il y ait un acces restraint par htaccess ou que les images soient en dehors de l'espace web ne change rien au problème, qui réside plus dans la fiabilisation et l'allègement et la vérification du droit d'affichage.

Oui, c'est juste que je me sens plus rassuré d'avoir un espace à part qu'un .htaccess. Un oubli d'upload, un effacement par erreur, une erreur dans ce fichier .htaccess est c'est foutu. Alors que pour autoriser l'accès à un répertoire autre que www, il faut le faire exprès.

[Galak`]

D'une part l'.htaccess ne bougera pas, d'autre part il faut pouvoir désactiver cette sécurisation dans le cas ou l'affichage finirait par etre trop lourd par readfile (ou que le cache du navigateur serait finalement mal géré)

[ripat]

L'arme absolue: mod_security pour Apache. Toutes les requêtes http sont filtrées à l'entrée. Et pas seulement l'uri, mais également son contenu (le body d'un POST par exemple).

Ce filtrage se passe avant que le serveur http ne "serve" les requêtes.

Les règles de filtrage et les actions subséquentes (allow, deny, status, redirect, log...) fonctionnent un peu comme iptables. Il est aussi possible de filtrer les sorties! Une sorte de router/firewall pour Apache.

Tu devrais certainement trouver de quoi faire!
http://www.modsecurity.org/

[Galak`]

Hum, ca fait un peu extreme pour ca, ca consomme des ressources et necessite un peu de config pour que ca ne foute pas le boxon ailleurs. Puis je ne vois pas trop non plus comment il pourrait faire la différence entre un appel direct par l'url ou depuis une balise <img>

[Mr N.]

Envoyé par Galak`

Puis je ne vois pas trop non plus comment il pourrait faire la différence entre un appel direct par l'url ou depuis une balise <img>

tu veux bloquer les images si on tape leur url dans le navigateur ? Et si l'utilisateur fait un document html et met l'url de ton image dans une balise img ?

[Galak`]

Ca c'est déja bloqué par la protection des images sur le referer. Apres la solution de la session que j'ai testée marche bien, mais il y a un problème avec le cache. Puis bon en pratique c'est assez lourd et ajouter un id aléatoire dans le nom des images sera plus simple si je dois mettre en place une telle protection