Hi, I know this has been discussed many times but I am mostly seeking help, not requesting a project feature.
I use piwigo exclusively as a private photo gallery so I'm looking to protect the user privacy as much as possible. I have managed to setup user permissions and server so the photos and the directory structure is inaccessible outside of piwigo, the only problem that remains are thumbnails (sizes) when accessed through i.php
As far as I know these thumbnails are considered public by piwigo itself and its team, relying on either server access control (via http auth) or hashing of the filenames. This has been considered sufficient and has been discussed multiple times in the past. I note that I believe that only hashing is insufficient and opens a lot of MITM attack surfaces which can expose photo privacy (xl thumbnail is basically identical to the full version from photo subject's privacy standpoint) while http auth is very user unfriendly and imo redundatn when using the inbuild privacy controls. As far as I understand the current position of development team is that checking user privileges for each thumbnail would be too much of a resource drain which I can understand and am therefore not advocating changing this position but only looking to implement my own version which choses a different path. As I am not alone in this, I am looking for help from the community with how to acchieve total thumbnail privacy.
Going by this topic some progress has been made by user benhup but the code is two years old and in contrast wih developer's suggestions ("do all the checks in I.php and always use it instead of action.php"). So I am looking for a version of i.php which actually checks the user permissions. I can try to code something myself but any community pointers would be welcome at this point as I am not certain of my ability not to screw something up and with permission management mistakes can be costly. Are there any code examples of such i.php I describe?
The only thing you can do is to block invalid referrers and search engine bots. See http://piwigo.org/forum/viewtopic.php?p … 98#p162898 for my best-as-possible lock-down config without adding http basic auth on top of it. Block invalid referrers, block bots, block as much as possible while "keeping it public".
Other than that, http basic auth in front of all is your only solution to really protect your images, including derivatives.
i.php can be bypassed easily, if you know the uri of any image. So it's just a matter of "how much protection you really need". Full protection? Use basic auth.The privacy feature "hides" stuff, it doesn't really protect it (well it does, by obscuring it)
Last edited by teekay (2016-10-28 00:12:32)
Offline
Yes, thank you for the fast reply, I've forgotten to mention your config in the previous post, it has certainly helped me in securing my install although an additional apache recommendation would also come in handy. I also actively monitor traffic and maintain extensive blacklists server wide. But still as far as I understand even your solution is not bullet proof for thumbnail privacy (spoofed UA can still access a thumb through i.php as far as I can tell if the name is known while direct file access can be prevented through server conf).
I also think public thumbnail access through i.php is significant exposure (see also first post). Any past connections log capture on one client machine essentially makes a high quality thumbnail of the private image world-viewable and linkable, indefinitely or at least until thumbnails regenerate. Regular thumbnail regeneration maintains at least some forward privacy but that also puts a strain on the server resources (which in my case would be at least comparable or even more straining than i.php permission check).
Sorry for lengthy posts but I really cannot see how such a compromise is acceptable. Anyways the trend of the discussion in past topics keeps coming back to "secure the server access and accept public thumbnail links" while a lot of people are (specifically) looking for a direct way to prevent the thumbnail access and are constantly dismissed. As I've said I am not looking to convince anyone but merely for a way to implement this if possible as i.php is the only exposure surface I can find in my implementation and is also something a key dev suggested as a way to achieve this.
If original versions of images can be made accessible only through the action.php and such an option is included in the config, I see no argument (aside from performance) that can support this decision while arguing high quality thumbs of same images have no need for the same level of protection. And while performance is an important compromise and filename obscuring is at least something, I am only seeking help in taking this further and preventing public calls through i.php which I find the last (but a major) privacy issue with my gallery.
I did a quick hack by adding a check whether a valid PHP session cookie exists at the start of i.php
(the script which takes care of generating and serving derivatives):
... define('PHPWG_ROOT_PATH','./'); // fast bootstrap - no db connection include(PHPWG_ROOT_PATH . 'include/config_default.inc.php'); @include(PHPWG_ROOT_PATH. 'local/config/config.inc.php'); // ADDED - START global $conf; $session_name = $conf['session_name'] or 'pwg_id'; if ( !isset($_COOKIE[$session_name]) || empty($_COOKIE[$session_name]) ) { // Instead of 403 Forbidden, issue a more protective 404 (not found) when user is nog logged in http_response_code(404); echo("Not found"); exit(); } // ADDED - END defined('PWG_LOCAL_DIR') or define('PWG_LOCAL_DIR', 'local/'); defined('PWG_DERIVATIVE_DIR') or define('PWG_DERIVATIVE_DIR', $conf['data_location'].'i/'); ...
This way, any request without PHP session (user not logged in) will get a 404 Not Found message when they try to fetch derivatives. I find it safer than emitting a 403 Forbidden response since it implies that the resource exists (which you may want to prevent inferring).
This could be further refined by checking the `user_id`and the assorted permissions, but in my use case that is not really required.
Last edited by shutterfreak (2024-09-17 15:14:14)
Offline