posts gallery tricks traps
Posted on: January 30, 2018
Gallery Tricks and Traps (How to Prologue)
Every now and then, but more often than not, a web developer is asked to deliver a gallery application for uploading and displaying images on the client's website. Now it depends on the client's wishes how exactly to approach the task ahead. One option is to search for galleries online and see, if anything comes close to what is needed. Quite often you will find what you're looking for and perhaps even as an open source project that you'll be able to use for other projects. However, you or your client may find the gallery settings confusing or even overwhelming, if only a basic upload and delete function is required. Of course, the deal will cover other non-technical specifications such as how exactly the gallery will look like, how big the images are going to be and whether or not libraries such as lightbox are necessary.
That's often the deal on the surface. What comes behind the scene is entirely up to you but the general rule is that security and performance are expected as a default feature of the application. So here is where things can get complicated, especially when using someone else's gallery which might also be an open source and avaliable to anyone willing to take a look at the source code. In case you're wondering why I'm saying this is because many sites that get compromised are exploited via open source gallery applications that allow file uploads. This is why you have to be careful when it comes to using free and/or open source gallery scripts. What you need to ask yourself is the following:
Another aspect to consider here is whether or not to use a database. While it is neat and extremely handy to have all the info about the images stored in database you need to know that each query will be slowing down performance and could be a potential security hole in the application. Even if you've made sure to escape and encode all the queries and inputs, there is still a threat that a malware encoded in the image could potentialy be uploaded to the database. The problem with this is that, unlike on server, there is nothing left to prevent its execution. So whenever using a database for gallery, do NOT store files in the database. Rather than that, just store information about the files in the database while the files should be called from the folder that they were first uploaded in. Why? Because the folder or folders, on the server, can be instructed to deny access to certain type of files or prevent their execution. Basically these folders should behave like a quarantine. Nothing comes in or out and what's there is under strict rules.
Regarding performance of the application, beside trying to optimize your code, one of the best solutions is the creation of thumbnails because loading the full images with reduced width and height won't help and the gallery will have a lag. And the more images per page, the bigger the lag will be which is basically unacceptable these days. Another thing you could consider is compressing the images upon upload. It's about the size of the files on the server that clients are making HTTP requests to when viewing the gallery that also defines how good a performance is going to be. Having a good connection to the internet helps so having a decent server will improve the performance and so will having a good conection as a client but since you cannot influence on what kind of connection does a client have, we can only make sure that the server is in good health.
Processing files
In case you were not familiar with all this already, you may want to take a moment to evaluate options before making a choice on how to proceed with your own project. In the meantime, let's try to answer the questions above. How does the script process files? Well, there is plenty of space for manuvering and making conditions how to inspect a file and figure it out whether or not the file is an image and that it's safe. But none of these conditions will ever make the application completely safe because certain techniques exist that can bypass them all and potentially execute the malware hidden inside upon upload. So the safest way is to create an image from the original file on the server and then delete the original file permanently while storing the newly created image to the desired folder. This way copying the potential malware hidden inside is minimal because the image is re-created using the library functions instead.
It has to be said though that even if chances are minimal, this too could fail. So another break we can pull on the malware is disabling access to certain type of files inside the upload folder. This can be done by configuring the server correctly or even by just adding a few lines to .htaccess file. For example on linux running Apache, one way to block execution of files is to add the following to newly created .htaccess in the uploads/ folder:
Order Allow,Deny
Deny from all
<FilesMatch "\jpg|JPG|jpeg|JPEG|png|PNG|gif|GIF\$">
Allow from all
</FilesMatch>
This will prevent anyone accessing files with extension any other than what is allowed. Aditionally, double extensions can be blocked with:
<FilesMatch "\\.([^.]*)\\.([^.]*)$">
Order Deny,Allow
Deny from all
</FilesMatch>
Note that this will also block images that have . sign or signs in the name so make sure that's not the case, if this is used or these images won't be displayed. Another thing to mention here is that .htaccess could potentially be uploaded to overwrite the existing one but if the script is set to re-create the image, as mentioned above, then there is no worry about this. File type condition check that allows image type files only, would also negate uploading .htaccess.
Folder permissions
One other thing to be mindful of is the file permissions of the folder. In order to upload files, at least the owner of the folder needs 7 which means reading, writing and executing files at will. Just make sure that www-data is the owner, else the script won't work properly. All other users should be using 5 which means reading and executing. So the most optimal solution for these folders is 755. You could execute the following commands to make the case:
sudo chown -R www-data:www-data /full/path/to/uploads
sudo chmod 755 /full/path/to/uploads
By no means 777 should be set for this folder or all users could read, write and execute which is not just a massive secuirty hole but more likely a disaster waiting to happen.
Deleting files
As for the final set of questions, a check needs to be made to make sure that the unlink() function doesn't delete critical files on the server. Consider this:
// A file with the name passwd is being uploaded to the uploads/ folder
$uploadedfile = 'passwd' ;
if (file_exists($uploadedfile )) {unlink($uploadedfile );}
So the file_exists() checks whether a file or directory with the given name exists. If the command "locate passwd" is run on the terminal, it would give us similar to the following output:
/etc/passwd
/etc/passwd-
/etc/cron.daily/passwd
/etc/init/passwd.conf
/etc/pam.d/chpasswd
/etc/pam.d/passwd
/var/www/html/uploads/passwd
The unlink function in this case could potentialy delete 4 files since it doesn't care about the path and because of deleting the /etc/passwd file, the server would break apart. Of course this example wouldn't go through because it needs root privileges but could delete files that don't or, in worst case scenario, the www-data owner, for example, is added to sudoers to require no password when executing the script with unlink() function. Although highly unlikely to be the case, a caution is never superfluous. Which is why it is recommended to check the full path of the file before deleting any files on the server.
These were just some of the basics that you need to consider whenever using a gallery on your sites. If you wish to add more tricks and traps or have any other questions or thoughts, please leave a comment below.
