I have a project where there is Log in/out functionality, and authenticated users can upload, download and delete files they own.
My question is: is it enough security for the files part of my project to escape
file names with htmlentities() and to prevent users from opening the directory where files are located with
<Directorymatch /cloud/>
Order deny,allow
Deny from all
</Directorymatch>
This means that if a .php file is uploaded, it cannot be run on my server by a user. Also if the file name contains scripts / html then it does not un.
What else am i missing in terms of security? I probably will be the only user of this bootleg "google drive", but i want to take security seriously. What am i missing?
You will need to ensure that your uploaded file are well sanitized and validated before being uploaded.
finfo_* library would be good but it will work with php >= 5.3.0 versions. The Stackoverflow link below has the
best solution on how to validate and secure your file upload using the best security measures.
Source Link
Again you may need to turn off php engine in the upload directory. so you can create a php.ini file and enter this
line of code
engine = off
Updated section
You might use shell_exec() and exec() for testing things locally but you have to disable them
in production because an attacker can use those shell command to obtain your system or files informations which might lead
to compromise of your entire network.
For Instance take a look at the shell_exec() code below
<?php
// Use ls command to shell_exec
// function
$output = shell_exec('ls');
// Display the list of all file
// and directory
echo "<pre>$output</pre>";
?>
Output:
transaction.php
index.html
moneyupdate.php
Now take a look at Exec() Code below
<?php
// (on a system with the "iamexecfunction" executable in the path)
echo exec('iamexecfunction');
?>
Output:
transaction.php
So in a nutshell its up to you to decide. If you are on share hosting please you will need to disable them because your
hosting neighbor might inter-fer but if you are in a VPS or Dedicated, you might try it out on your own
Related
Suppose that our web-hosting is linux and php is installed:
1- What could be the worst that happens when a php code can be uploaded instead of an image.
2- Can the intruder somehow retrieve my database password ? suppose that the directory on which images get stored has 777 file permissions.
3- What if when the image directory has 644 permission?
The answer to my question can be combined with the ones given to these two: Security: How to validate image file uploads? and Security issues in accepting image uploads
What could be the worst that happens when a php code can be uploaded instead of an image.
Worst case: Intruder can execute arbitrary PHP code, maybe even arbitrary code on the server. If the attacker is clever enough while the sysadmins aren't, he might even own the whole server/subnet/network/...
Can the intruder somehow retrieve my database password ? suppose that the directory on which images get stored has 777 file permissions.
If the attacker can execute PHP code (which of course depends on your security measures), he can definitely read files from the current user, so the answer is most probably yes.
What if when the image directory has 644 permission?
Unless you use PHP in CGI mode, the execute bit shouldn't be necessary for the webserver to execute a script, so that alone doesn't help.
Of course those are not the questions you should ask. The question you should ask is how to prevent an attacker from uploading an executable PHP file in the first place. My answer to that is that you should check the file extension against a white list and drop everything else, for example:
$pattern = "/\.(jpe?g|gif|png)$/iD";
if (!preg_match($pattern, $filename))
die("Please don't.");
You should make sure you don't allow parsing of php files in your image directory, since I'm assuming it's going to be open to the public.
You could do this in the /images/.htaccess file with
RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
That way if they try to go to domain.com/images/hackdatabase.php it'll just return their code and not the file.
But you should check to make sure its' an image in the first place.
I'm just wanting to confirm that what I'm doing is actually secure.
Firstly, I have a GoDaddy shared hosting account, but I do have a dedicated IP address.
Let's call my server path /path.
My site's files are located in /path/mysite
When a user uploads a file, I move it to /path/uploads/file_name.
It is impossible for someone to reach that folder via a URL.
To add, I have a .htaccess file in /path/uploads with the following:
order deny,allow
deny from all
allow from 1.1.1.1 #let's say 1.1.1.1 is my server's IP address.
And then to actually initiate a download of the file, my users will follow a link to mysite.com/file.php?q=[file_id]
And in file.php, I download like so:
$mime = mime_content_type($location);
header('Content-disposition: attachment; filename='.$name);
header('Content-type: '.$mime);
readfile($location);
As far as I know, it's not possible for anyone's uploaded files to run on my server, but I may be wrong.
Are there any security gaps that I need to take care of?
First, you don't need the allow from 1.1.1.1 as this will allow you to access this directory via Apache services. No, you will only ever access this directory from an executing program / script.
Second, this is a pretty standard template to address this type of problem. So its well worth looking and widely used packages such as MediaWiki or BB engines such as phpBB approach this and mirror some of their security checks.
My third suggestion picks up the point made by Marc B, you need to think about constraints on the file name and file types that you want to allow / support, and the possibilities of other attacks. One approach is simply to store files with the filename and ascending ID and keep the ID/user filename as a map in a DB table. You also need to think not only about attacks on your server, but that malicious users could use this upload facility to implement XSS and other attacks.
You can disable the PHP interpreter for that directory completely with
php_flag engine off
in your .htaccess. This should give you a good degree of protection against stuff running in that directory.
However, you didn't show your upload code, so it's hard to tell what you are doing there: you really want to check you are not vulnerable to path traversals as that would completely void your protection here.
The download code, too, might be vulnerable: if you are actually using the snippet you posted, the attacker can download any file on your application by simply using "../../whatever.php" as a filename (again, path traversal). Or use that script as a praxy and more - hence you want to make sure you validate the filename value.
I have read the following tutorial "Uploading Files To the Server Using PHP"
and have several questions related to the topics.
Q1> The tutorial mentions that
"Note that PHP must have write access
to $uploadDir or else the upload will
fail"
For me, I only allow the user to upload the file after the user has login to the website.
If we set that $uploadDir permission as 777, then everyone can have written permission to that folder. How to avoid this problems?
Also I am using WAMP as my testing bed, can I simulate the same case as a real web server?
Q2> In order to prevent Preventing direct access, the tutorial mentions:
"A better approach is to move the
upload directory away from your web
root. For example, the web root for
this site is:
/home/arman198/public_html/ to prevent
direct listing i can set the upload
directory to /home/arman198/upload/."
Now my problem is that how can I display the uploaded images on other website pages. Since, the upload is not accessible directly anymore? I need to display the uploaded image save personal headshot dynamically on other website page. Is it possible?
Thank you
It's a common problem.
All modern computers have a temporary files directory. On Linux/Unix it's /tmp, on Windows it's usually c:\temp. The OS install will have set permissions on that directory so that anyone can write files there but only privileged users can delete files that don't belong to them. This is where PHP will want to put an uploaded file; your application then has to move it elsewhere (this is the purpose of the move_uploaded_file() function). PHP under Windows may need upload_tmp_dir actually set in the php.ini file.
Once you have an uploaded file, you can shift it whereever you like, including to where the webserver can read it to serve it. The biggest problem with that it is awfully easy to put this directory inside your codebase. Don't do that. As soon as you do anything beyond editing the files inside the directory they are served from, it will be problematic. Trust me: I've dealt with a few times this in code I've inherited. It's easy to let your webserver load files from a location outside your codebase.
The other alternative is to produce a download script. That way the file need not be servable by the webserver at all. One disadvantage is that you don't get to leverage the web server's MIME translation, but then, that lets you control which types of image files are permitted.
For the second question, you can use a PHP script intead of direct access to the directory. Lets name it image.php. Lets assume that it can take a parameter id, like image.php?id=image_id. In that file you can get the id using superglobal array $_GET. Then you can search for images with that Id and just send it as response.
First one I'm not sure, but maybe play with .htaccess file.
And for the first question, try setting your permissions to 775. That should allow PHP to write the file to the directory without giving the general public write access.
On the current website I'm working on, I've got a directory of files for users to download which would be really nice to have some security method other than obscurity ;)
I was wondering if there's any way to supply login information via PHP to htaccess as though a user were entering it.
Alternately, if anyone knows a better way to secure user downloads using PHP, that's also acceptable. All of my googling turns up "just use htaccess" which isn't really helpful, as from the non-savvy user's point of view, they have to log in twice every time they use the website.
My best guess at doing it exclusively with PHP is to store files above the web root, then copy them to a web accessible folder temporarily, but this seems highly inefficient and I couldn't think up any way to remove them after the download has finished.
Note: I don't own the server this is running on and don't have ssh access to it.
If files are not too big (Gb) you can always use readfile for file's download. In this mode you can check user's auth before, and if it's ok output file contents to user, otherwise send him to login page.
With this method you can put your files in protected (with .htaccess) directory so you can be sure that nobody who isn't authenticated can access them.
I think I would either store them in a folder outside of the web root, or in a folder protected by .htaccess and then have a php script that checked if the user was logged in and allowed to download a file asked for. If he was, then just pass the file through to the user.
Example from linked page at php.net:
Example #1 Using fpassthru() with binary files
<?php
// open the file in a binary mode
$name = './img/ok.png';
$fp = fopen($name, 'rb');
// send the right headers
header("Content-Type: image/png");
header("Content-Length: " . filesize($name));
// dump the picture and stop the script
fpassthru($fp);
exit;
?>
Someone else made a comment about having to report the correct content-type, which is true. Often, in my own experience, I already know it, or can use the file extension pretty easily. Otherwise you can always try to have a look at finfo_file. On that page there are also some comments about what you could do especially for images as well.
you should use a php script to control the access.
create a dir outside the webroot or inside the webroot with a .htaccess where you location the download files.
outsite the webroot is better.
you have to make sure that no one can access those files if they are located inside.
then take from the pear class lib. the class http_download.
using this class has many advantages.
Ranges (partial downloads and resuming)
Basic caching capabilities
Basic throttling mechanism
On-the-fly gzip-compression
Delivery of on-the-fly generated archives through Archive_Tar and Archive_Zip
Sending of PgSQL LOBs without the need to read all data in prior to sending
you should not use readfile oder any forwarding filepointer because you have to set the headers yourself and the don't support http "range".
for the access restrictions you can use you session-manager, password, framework, forum etc.
pear - http_download http://pear.php.net/package/HTTP_Download
you need to copy the url, because SO encodes it to url-encoded string (which is correct), but PEAR-homepage doesn't like that.
Why reinvent the wheel? Take a look at File Thingy, which is pretty easy to install and customise. If nothing else, you can study the source to learn how to perform the authentication step.
You could use MySQL to store uploaded files, rather than storing them in a file, better and more secure, in my opinion. Just Google "MySQL upload php" for example.
You could create the htaccess file using a PHP script, from your users table, each time a user accesses that folder, very troublesome.
I think the first option is better.
Use X-SendFile! There's extensions for Apache, Lighty and Nginx so there's a good chance there's one for your webserver.
Once you have the extension installed, you can authenticate the user using your PHP script, and then add the header:
header('X-SendFile','/path/to/file');
When your PHP script is done, it will trigger the webserver to stream the file for you. This is especially efficient if you use PHP along with for example FastCGI, because it frees up the PHP process for other work.
Evert
I'm trying to develop a file uploading module on our new site that allows you to upload any file to our servers. The uploaded file is uploaded to /files, in which the following .htaccess to prevent users from executing i.e a .php file:
<Files *.*>
ForceType applicaton/octet-stream
</Files>
This triggers the browsers download window (at least in FF and Safari), but is it safe to assume the file won't be run on the server using this method? If not, how would you implement such a solution?
I think the safest thing is to restrict 100% web access to the directory, and have a script like download.php through which you pass a file id that then fetches the appropiate file and outputs it to the browser. However, I am pretty sure that what you have will work and is safe.
is it safe to assume the file won't be run on the server using this method?
Kind of, but it depends on what other directives are present in your config; maybe there are other rules set up to allow PHP files to run. If the only way you're enabling PHP is by keying the PHP handler on file type, that should stop PHP executing.
However, stopping PHP executing is just one of your worries. If people upload files that contain active content, such as HTML or Flash — even if the filetype says it's an innocent image — they can gain control of other users' sessions on your site through cross-site scripting (XSS). See Stop people uploading malicious PHP files via forms for some discussion of this.
A ‘download.php’ interface that uses Content-Disposition to always trigger the download box, coupled with storing the files under non-user-supplied filenames like ‘1234.dat’, is much safer.
I think you actually want this:
<Directory /path/to/files>
SetHandler default-handler
</Directory>
What you have might work in practice, because the server is configured by default not to execute anything unless specifically told to do so, but it doesn't really guarantee that nothing will be executed. ForceType just sets the content type for static files (I'm not sure, but I doubt that it affects executable scripts).
Seconding Paolo's answer, move your files directory out of the accessible path. You can then write the download.php script using PEAR's HTTP_Download module to serve the files.
I agree with Paolo, his way is more secure. There is always the issue of someone exploiting your PHP files to execute an uploaded one. Bad Example:
include_once("/modules/".$_GET["module"].".php");
Where someone passed in module=../Files/exploit
For maximum security, you shuold have the folder containing the uploaded files be mounted from a separate partition with the no-exec flag.