I am creating a website creation service where users can upload files in an FTP browser interface. I also want them to be able to create real directories, but I was worried that if they uploaded scripts, that hey could reek havoc on the server.
I am using PHP, and the mkdir() function. Would it be a good idea to use mode 0664 when making directories, to prevent:
Malicious files from being executed.
Prevent just anyone from writing or executing those files.
Is this a good idea?
No, it does not make sense to use 0664 on directories.
You very likely need the X flag on them because you want to be able to get a directory listing. "Executing" a directory has nothing in common with executing a program. Disabling the X-flag on a directory will not affect execution of programs stored inside.
You have identify yourself which account is actually involved with file access. This account might be the owner of some files, and the owner of the directories of these files. Anything PHP does will be done as this user. So it does not matter if you restrict access to the file for the group or the world (aka 0700). On the other hand, your FTP access might not be the same user, but only sharing a group. In this case it is an annoying idea to restrict this group to not having access to the files, because you cannot read, write or delete them.
If you allow users to use an upload facility to your server, and you cannot guarantee that these files will never be executed, you probably shouldn't offer this service. Using access flags will not improve the situation, because PHP does not need the X flag, it only needs the file to be readable. So if the FTP site should be of any use, being able to read the files is a must, otherwise why uploading them?
Note that the usual FTP upload/download service separates uploads from downloads. An upload is a one-way operation that places the file on the server but without being accessible. An administrator has to check the upload and move it into the download area where it is read-only. Nobody can trigger the execution of any file because the server will ignore any executable flags and simply send the bytes of such a file back.
You cannot even open files in a directory without an executable permission. But you can access files in a directory without a read permission. A read permission is needed to list directory contents.
0644 directories are inaccessible except by root.
Examples
Inaccessible:
dir/ = drw-rw-r-- (0644) -- effectively the same as d--------- (0000)
So file_get_contents ('dir/file.txt') will always fail.
Accessible, but no listing possible:
dir/ = d-wx-wx--x (0331)
So file_get_contents ('dir/file.txt') will work if dir/file.txt exists. But opendir ('dir') will not.
Fully accessible:
dir/ = drwxrwxr-x (0775)
file_get_contents ('dir/file.txt') will work if dir/file.txt exists. And opendir ('dir') will return the contents of the directory.
Related
I am using Jasperreports for generating the reports. When I am generating the new reports it will be own by root with permission of 644. So other users dont have permission to view this report.I want to change the ownership of the file or change the permission.So everyone can view or download the reports.
I tried below php functions
chmod($item, 0777);
chown($path, 'www-data');
It gives
error: dont have permission to do this
. Because its own by root and current user is www-data.
Anyone please help me,
Actually, based on what you're saying, all users have permissions to view that file. 644 means owner can read and write, and group and others can only read. If your script is getting an error reading that file, it might be because of the permissions of the directories in is path, but not the file itself.
If you could change the owner or permissions of a file owned by root like that, it would subvert the whole concept of unix file permissions. Think about it.
You can always change the user running these reports though, or add logic on the report generation side to move or change the permissions on the file as the user who owns it.
As an aside, chmod 777 is an ugly kludge used only by those who have little knowledge of unix permissions . Professionals don't do it. You should bump your understanding of unix file permissions to the next level:
https://www.tutorialspoint.com/unix/unix-file-permission.htm looks promising.
According to the manual, the owner and the supersuer have the right to do this.
And you only chage the file mod or owner, will not do. You have also to change the path.
chown
Attempts to change the owner of the file filename to user user. Only
the superuser may change the owner of a file.
Note: This function will not work on remote files as the file to be examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or directories being operated upon have the same UID (owner) as the
script that is being executed.
chmod
Attempts to change the mode of the specified file to that given in
mode. Note: The current user is the user under which PHP runs. It is
probably not the same user you use for normal shell or FTP access. The
mode can be changed only by user who owns the file on most systems.
Note: This function will not work on remote files as the file to be
examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed. In addition, you cannot set the
SUID, SGID and sticky bits.
Not a specific coding problem but every thread I search where people talk about 777 server files involves server related questions not php.
I realize I shouldn't be setting 777 file permissions on my server due to security concerns. Is there a safer way to use php file writting code such as file_put_contents()? If I don't set file persmissions on my server, code doesn't work and I get errors.
Generally you should only give the minimum amount of permissions required.
For files that need to be executable directories are commonly be set to 755 (drwxr-xr-x) or 750, and files 644 (-rw-r--r--). That's not to say that some environments don't have permissions that are often set much lower — it's dependent on which user and group owns the files or directories.
Upload directories sometimes need to be set at 777, although you really shouldn't be executing scripts from the same directory as where items are uploaded. The reason is that it can open a floodgate of possible attack vectors. If you need to execute something that might be uploaded, then you might consider mv or cp it into another directory, then execute it.
I just started working with uploading files via php.
From my understanding you need to set the properties of the folder to 777 so anyone can upload to that location.
That's fine and i only obviously keep information there that is not sensitive, its basically images which are displayed back to the public.
However can someone not just run a delete statement if they know the image name to my server folder or is that only possible if the php file is on my server?
i.e delete myimage.png
Basically my question is other than the normal security precautions like limiting the upload of only .png, using basename etc do i need to take additional security measures to prevent someone deleting files in that folder or can that only be done from a script on my webserver?
I wont be using any post methods to delete images or anything like that but i'm just not sure if its possible to take advantage of a folder with 777 permission and do unauthorized stuff since i gave full access to the folder.
By 777 you're actually giving the read/write/execute access to all the user of the machine where your server lives. Note that this does not mean even website visitors can read/write/execute directly. Its always your webserver (Apache) that does it.
However can someone not just run a delete statement if they know the image name to my server folder or is that only possible if the php file is on my server
If you're PHP scripts have holes then, yes. If your webserver has holes then, yes :)
do i need additional protection on a 777 folder
Yes, you can do with a more restrictive permission. Make the owner of the public upload folder to be apache (mostly www-data), set permissions of just 755, or may be 775 in case even the group wants to write to it.
you can change folder permission 777 to 755 or 744.
I think this question should be something easy but after searching all over the web I couldnt find an answer, so I decided to ask here.
I have a file uploader in my website that works with php. The folder where files are being uploaded has 777 chmod. I also have a php script to list the files in that folder. What I need is to allow php to upload and browse files on that folder, but dont allow people to do it. The only solution I imagined is to chown that folder to another user different than default, so I could later chmod in filezilla and allow only owner to do it, so people will see the files trough the output of the php script, but not if they navigate to that folder.
Im using Debian, apache2. Id like to know what could I do.
To make it shor, my aim: allow php to upload, read, write and execute files in that folder, but not clients unless they use my php script.
Thanks in advance
Put all the files you're talking about in their own directory. Add a .htaccess file to that directory. The contents of the .htaccess should be deny from all.
This will prevent any user from manually accessing the files as access will be blocked off. Your PHP script can still browse the contents of the file and serve it up as an attachment with the correct content type.
For more info on how to serve a file for download in PHP, read this: https://serverfault.com/questions/316814/php-serve-a-file-for-download-without-providing-the-direct-link
All services including web servers run in a security context which is an account in the OS, for example apache starts using apache user in apache group. It is enough to change mode and change owner to this user and group. Never chmod a directory to 777 until there is a good explanation for that. Using this trick, web service process only can read, write and execute in that directory.
As well, if you want the browser clients not to see(read) the contents of that directory, you should deny listing on that directory. I think it is disabled for default.
I am working on a PHP based website. In the admin there is a section that checks a form field and based on the field looks for a folder on the server. This folder will be in a sub-directory. If it does not exist it needs to be created. After that, previously existing or not, PHP will write file to the folder.
These folders will hold images and PDF files that will be viewed and/or downloaded on the main site.
Here is an example directory structure: merchants/east/user123
In the above merchants and east would definitely exist and user123 may exist or otherwise be created.
Given that info my questions are about folder permissions.
What should folders be set to for the best security.
Should I open them up wider during operations then chmod them (in PHP) after I'm done to something more secure?
What should upper level folders be set to?
770 would be a safe bet for the files. Setting it to that would disallow any public access. I would implement some sort of document delivery system in PHP. PHP will be able to access the non-public files and then send them to the user.
The upper level folders could be set to the same.
Update
As others have said, you can easily chmod them to 600 without any issues. That's the more secure way of handling it (prevents other users on the system from accessing the files). It also omits "execute", which isn't needed for file reading anyway. It's my personal practice to leave the extras in unless there's a defined reason not to.
The upper level folder would need to have read, write and execute permissions for the apache user., the top level folder could be owned by apache, and have permissions like 755 to allow the the webserver to read, write and list files.
You might think about permissions 750 or 700 if you are particularly concerned about other local users or services on the web server from seeing the files in this directory.
For file permissions: 644 or 600 as conventionally they do not need execute permission.
A nice compromise might be to use 750 for directories and 640 for files with owner set to apache, and change the group (chgrp) so that the group for the file allows access to the user that you normally edit the website files with.
I can't think of any significant advantage of the php script increasing and then reducing the permissions.
I think you should consider #chunk's comment about keeping the uploaded files own of the public html directory completely, and serving them back via an file delivery script. Otherwise you would need some careful validation of the content of the files and to tightening up the apache configuration for that particular directory - perhaps using some mimetype checking to make sure that the files really are docs and pdfs.