🌍
Français
Bonjour,
Je reviens sur ce fil car je me suis à nouveau confronté au problème.
A nouveau car j'ai perdu ma correction lors des mises à jour de Piwigo, et ce sujet m'était sorti de la tête.
Mais cette fois ci, c'est pour deux autres usages que j'ai rencontré le problème :
- les liens présents dans le mail de notification ;
- les liens dans les résultats renvoyés par les API.
J'ai fait une rapide recherche sur le net mais n'ai pas trouvé mon bonheur : est-ce qu'un correctif a été intégré aux releases officielles ?
Cordialement.
Bonjour,
L'utilisation de ces entêtes peut effectivement amener à des vulnérabilités si elles sont employées avec une configuration défaillante des éléments réseaux amont (comme le reverse proxy).
Il convient donc de les utiliser à bon escient. Mais cela est valable pour tout paramétrage d'un applicatif exposé sur un canal de communication public.
J'aurais tendance à penser qu'une personne qui configure un reverse proxy doit avoir une connaissance minimal en matière de sécurité informatique, car ce n'est pas vraiment une notion grand-public.
Cordialement.
Bonjour loutremaline,
J'ai fait un petit point sur Github concernant cette demande. Il existe en effet 2 pull-requests sur ce même sujet, voir https://github.com/Piwigo/Piwigo/pull/483 et https://github.com/Piwigo/Piwigo/pull/914
On a donc la solution technique pour que Piwigo se débrouille bien avec un reverse-proxy en HTTPS. Le débat est sur la manière de régler la question :
1) on adapte le code de la fonction get_absolute_root_url pour utiliser la variable serveur HTTP_X_FORWARDED_PROTO (comme on le fait pour HTTP_X_FORWARDED_HOST, ce qui serait cohérent)
2) l'administrateur ajoute les lignes qui vont bien dans la configuration locale, qui elles-même se basent sur HTTP_X_FORWARDED_PROTO
rvelices est favorable à la solution 2 (et je pense voudrait qu'on retire l'utilisation de HTTP_X_FORWARDED_HOST dans get_absolute_root_url, par cohérence). Sur Piwigo.com, qui fait du reverse-proxy avec du HTTPS, on a d'ailleurs géré ça en config.inc.php.
La question est pour moi : y'a-t-il un danger, d'un point de vue sécurité, à utiliser ces variables dans get_absolute_root_url ?
Bonjour,
Je confirme le constat de cmenness qui date de 2012 et qui n'est pas résolu en 2019 (Piwigo 2.9.5).
Avec un reverse proxy, la génération à la volée des miniatures fonctionne mal : Piwigo lance la création de la miniature (via Ajax) mais quand celle-ci est prête, l'URL pour la récupérer n'est pas la bonne. Le script Ajax utilise l'adresse locale derrière le reverse proxy et non l'adresse publique.
Il s'agit bien d'un bug Piwigo qui ne gère qu'à moitié le cas d'utilisation d'un reverse proxy.
En effet, on peut paramétrer le reverse proxy pour indiquer à Piwigo que l'URL a été "traduite". Au niveau du nom de domaine, mais aussi du port ou du protocole, avec l'ajout des entêtes HTTP X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto.
Malheureusement le code de Piwigo ne gère que l'entête X-Forwarded-Host, ignorant l'indication de traduction de HTTPS vers HTTP et provoquant la création d'une mauvaise URL pour accéder à la miniature.
Pourtant une correction à déjà été partagée à ce sujet en 2016 : https://piwigo.org/forum/viewtopic.php?id=25782 .
Peut-on espérer une correction prochaine qui permettrait d'utiliser Piwigo selon des configurations classiques de sécurisation de SI ?
Pour ma part j'ai effectué un ajout dans la fonction get_absolute_root_url en ajoutant les lignes suivantes, mais je perdrais tout à la prochaine mise à jour... :
if (isset($_SERVER['HTTPS']) &&
((strtolower($_SERVER['HTTPS']) == 'on') or ($_SERVER['HTTPS'] == 1)))
{
$is_https = true;
$url .= 'https://';
}
+ else if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
+ && (strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https'))
+ {
+ $is_https = true;
+ $url .= 'https://';
+ }
else
{
$url .= 'http://';
}
Cordialement.
billporte a écrit:
Je n 'ai pas trouvé de solution pour faire un message privé, mais je pense que dans tous les cas, d'autres pourrait être intéressés.
Tout à fait, même si perso je ne comprend pas le moindre mot de ce jargon :-D
Bonjour lildadou,
Je me permets de rebondire sur c e message, car j'utilise également nginx pour un accès sur mon nas, malheureusement j'ai eu beau traumatiser nginx et piwigo, je n'arrive pas à m'authentifier une fois que je tente de m'authentifier sur mon nas à partir d'internet.
Si cela ne te dérange pas peux-tu zieuter un petit coup cette conf nginx et me dire si quelque chose te chatouille ????
server {
auth_basic "Restricted";
auth_basic_user_file htpasswd-tous;
listen 443;
server_name truc.homedns.org;
location / {
proxy_pass http://etrayz:8000/piwigo/;
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /piwigo/ {
proxy_pass http://etrayz:8000/piwigo/;
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
En parallèle, pour l'instant dans la conf piwigo, le site est paramétré sur $conf['gallery_url']=http://etrayz:80000/piwigo
Je n 'ai pas trouvé de solution pour faire un message privé, mais je pense que dans tous les cas, d'autres pourrait être intéressé
Merci de ton temps passé.
Bonjour,
je me permet de taper l'incruste car j'utilise Piwigo derrière un reverse-proxy nginx qui attaque le cluster PHP sur un descripteur de socket (meilleures perfs). J'ai pas eu de manip particulières à réaliser excepté sur la gestion des permissions. Essayez de vérifier ce point.
Voici ma config nginx:
###### Piwigo ######
### Astuce pour utiliser le cache du navigateur
location ~* ^/piwigo/.+\.(avi|mpg|mp4|swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
rewrite ^(/piwigo/.*)$ $1 break;
expires max;
}
### Proxy pour les pages PHP
### /!\ Socket Piwigo
location ~* ^/piwigo/.+\.php$ {
include fastcgi_params;
# Assuming php-fpm is running on a local socket
fastcgi_pass unix:/tmp/php-piwigo.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_connect_timeout 3;
fastcgi_send_timeout 7;
fastcgi_read_timeout 86400;
fastcgi_buffer_size 32k;
fastcgi_buffers 64 32k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
}cmenness a écrit:
Pour moi, la solution idéale est que l'application lise l'URL avec laquelle elle est accédée et lors de la ré-écriture d'URL à destination du navigateur, elle utilise le même serveur (et port). L'utilisation d'URL relative devrait même suffire. Je pense que la majeure partie des applications web fonctionne de cette manière.
c'est bien de cette maniere que piwigo fonctionne
cmenness a écrit:
Je pense que tous les autres écrans de PW fonctionnent déjà de cette manière. J'en veux pour preuve que nul-part dans l'application, j'ai paramétré l'URL externe et interne. Et ils fonctionnent tous (sauf la mise à jour de la miniature après génération). Donc pour moi, c'est un bug.
je persiste a dire que vous n'avez pas vu tous les problemes (par exemple emails envoyes par piwigo, flux rss ou services web ...)
cmenness a écrit:
Ensuite, quant à modifier la fonction get_absolute_root_url, je ne pense pas en avoir les compétences. Si vous voulez me passer le code pour que je vous dise si cela corrige le problème, je veux bien essayer pour vous aider.
Un lien "externe" vers ton site stp ?
Pour moi, la solution idéale est que l'application lise l'URL avec laquelle elle est accédée et lors de la ré-écriture d'URL à destination du navigateur, elle utilise le même serveur (et port). L'utilisation d'URL relative devrait même suffire. Je pense que la majeure partie des applications web fonctionne de cette manière.
Je pense que tous les autres écrans de PW fonctionnent déjà de cette manière. J'en veux pour preuve que nul-part dans l'application, j'ai paramétré l'URL externe et interne. Et ils fonctionnent tous (sauf la mise à jour de la miniature après génération). Donc pour moi, c'est un bug.
Ensuite, quant à modifier la fonction get_absolute_root_url, je ne pense pas en avoir les compétences. Si vous voulez me passer le code pour que je vous dise si cela corrige le problème, je veux bien essayer pour vous aider.
PS : Pour résoudre mon problème, est-il possible de retrouver la fonction de génération des miniatures qui existait en version 2.1.x ? C'est comme cela que je fonctionnais avant l'upgrade en 2.4.x.
Merci de votre aide.
cmenness a écrit:
C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?
Ca ne peut pas etre du parametrage si vous devez acceder a votre site de deux manieres differentes...
- par exemple piwigo.org/showcase/ et fr.piwigo.org/showcase/ sont la meme installation et heuresement nous n'avons pas ce parametre car sinon ca ne marchera pas. ca sera pareil dans votre cas ...
- ensuite pour les emails /flux rss/services web , il faut une adresse differente selon que vous l'accedez en externe ou en interne ...
je repete la seule solution est que vous detectez si c'est le proxy qui attaque piwigo et changer HOST/PORT dans ce cas la seulement ...
cmenness a écrit:
C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?
Oui :-/
Mais essayez de voir si effectivement ca solutionne votre problème. Il sera temps par la suite de voir comment rendre cette adaptation durable.
C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?
Si le chemin d'acces est identique en mode externe et interne (cad que seulement le serveur/port change), vous pouvez modifier a la main la fonction get_absolute_root_url (dans le fichier include/functions_url.inc.php)
Cela ne fonctionne pas. J'ai mis l'adresse externe mais le comportement est le même. J'ai l'impression qu'il existe un autre paramètre qqpart ou le nom du serveur est modifiable (qui doit contenir le nom interne et qui devrait contenir le nom externe). Mais je ne trouve pas.
Existe-t-il d'autre paramètres ?
Sur la même page, sur le coté droit, vous pouvez consulter le contenu du fichier initial lequel contient les explications (en Anglais) des divers paramètres.
Le lien se nomme Afficher le fichier "config_default.inc.php"
Vous ne copiez que ce que vous allez modifier. Ne copiez pas tout !
Le partie qui vous concerne :
// gallery_url : you can set a specific URL for the home page of your
// gallery. This is for very specific use and you don't need to change this
// setting when move your gallery to a new directory or a new domain name.
$conf['gallery_url'] = null;