I'm working on a little project with a few friends, and have set up a pretty simple PHP upload script that only certain users can access. I am not worried about any type of attacks against the server, since this is for fun, but I do have a question.
I've made a subdomain (static.foo.bar) where the uploaded files are moved to. This subdomain had mod_php turned off, to prevent malicious upload and execution of php scripts. The script also checks for file extensions and mime content types, but I assume those can easily be bypassed/spoofed.
However, a user could easily upload an .html file and have it redirect somewhere else. Likewise, they could upload an image file instead and have it display an image in the browser, instead of being asked to download the image.
I assume this is the behavior of the browser, but I've also noticed that when uploading a file to sendspace (or any other service), even if the file is .html (and valid html) it will ask the user to download it instead of displaying it on the website.
I am running Apache on CentOS.
How do I accomplish this?
ForceType is probably what you're looking for.
# In your .htaccess file
<Location /uploads_directory>
ForceType application/octet-stream
</Location>
You want to set all files' mime type to application/octet-stream so the browser will download them instead of trying to show the content.
Related
I know similar questions have been asked, but none of it guided me to the right solution.
What I want to do
Use .htaccess in a /uploads folder to ensure that only file with appropriate extension can be uploaded. (e.g. jpg, png)
What I have done
modify /etc/httpd/conf/httpd.conf
to allow overwrite of .htaccess file
create .htaccess file in /uploads folder
To test if .htaccess has been read, I have tried to put garbage in .htaccess file and access it from the browser. Corresponding error has been generated, therefore, .htaccess file is working properly.
Problem
The following script has been added to .htaccess
order deny,allow
deny from all
However, I am still able to upload files with any extensions to /uploads folder.
I have tried different suggestions from similar posts with no luck. Looking for new directions from you guys.
Thanks.
The name of the uploaded file is part of the body of the POST request the browser is making to the server, thus the .htaccess rules can't be enforced in your situation. Unless you are using some uploading schema, like creating a placeholder on the server and then submitting the file to that placeholder.
if you are using a GET method with base64 encoded string in your url, you can use .htaccess to redirect to an upload script base on the mime-type of that string. however I guess this is not what you trynna achieve. .htaccess is not appropriate in your case. if you need to control the extension of an uploaded file, you should make the process directly in your uploading script (php, python, whatever).
I've created (using a script and some help from Stack and some help from friends; I know very little about PHP) a simple page for a local non-profit publication where people can upload photos.
I'm not great with security (from a basis of ignorance, not deliberate negligence) but I've taken the following steps to protect this page:
• the PHP script is set to only accept .jpg, .png and .tif files for upload;
• the subfolder that it saves the form content to has permissions set at 700, and the subfolder it saves uploaded photos to has permissions set at 700;
• according to documentation, my host has the following configuration to ensure that only .php files run as .php:
<FilesMatch \.php$>
SetHandler php52-fcgi
</FilesMatch>
• I’ve put an .htaccess file in the relevant (main and saved content) folders:
RemoveHandler .php
RemoveHandler .inc
RemoveHandler .pl
RemoveHandler .cgi
RemoveHandler .py
RemoveHandler .fcgi
Overnight, however, somebody found this test page and submitted what seems to be a perfectly benign test message and small .jpg. This is a private test page with a non-intuitive URL that only I and about three other people know about; none of the others sent this test.
This obviously has me worried that there's something hinky going on, and I'm worried that I don't know enough about security to make sure this page is safe.
Is there something obvious that I'm missing?
When dealing with uploaded you should keep in mind that all the data you can find in the $_FILES array can be faked. It's traveling through HTTP so it's pretty easy to give the image/jpg mime to an executable file for exemple.
1- Check the true mime
PHP come with some function to check the real mime of a file. For that you should use fileinfo
$finfo = new finfo(FILEINFO_MIME, "/usr/share/misc/magic");
$filename = "/var/tmp/afile.jpg";
echo $finfo->file($filename);
2- Check the image's properties
You apparently want to upload only image , so the received file must have a width and a height :
Use getImageSize() to get all the required information about the image. If it return false , the file is probably not an image and you can delete it.
getImageSize can also give you a mime type , but i don't know if it can be trusted.
2.5- Reprocess image
As suggested by user628405 , reprocessing the image with GD is probably the more secure thing to do.
$img = imagecreatefrompng('vulnerable.png');
imagepng($img, 'safe.png');
Obviously it has to be adapted according to the image type. See all the imagecreatefrom* in php documentation.
3- Upload folder
In addition of what you have already done :
Make sure your upload folder is not available from the web. Validate the uploaded file then move it to an other folder if needed and rename the file.
It will prevent hacker from executing a malicious file (can't execute it if it can't be reached by an url).
Further reading : https://www.owasp.org/index.php/Unrestricted_File_Upload
Don't rely on any data from the client, including content type!
Don't save uploaded files in the web root. Uploaded files should be only accessible via your scripts, for better control.
Don't save uploaded files with their original file names and extensions! Store this data in a database for retrieval later.
You can check the MIME type of the file, but don't worry as long as your php handler can only execute .php files and you're taking care of not saving uploaded .php files in your script, you're not exposing any security leak.
This is valid for .php files as well as any other server-side scripting language installed on your server of course.
A better idea is to keep a white of the extensions you're accepting to save on your filesystem.
I would ignore the MIME type and the file extension of the incoming file. These can be faked.
Store those files in a directory if you are going down that avenue.
Ensure that that directory is just for images (music) and then get a script to place the correct extension on them by looking at the files format.
Also ensure that that directory cannot execute PHP (or anything else).
This will keep you safe.
Im working on an upload script, and i want a user to be able to upload any file.
I had it al working on localhost, i added
php_flag engine off
AddType text/plain php html shtml php5 php4 php3 cgi asp aspx xml
to my htaccess in the upload folder, and it showed the source of PHP, html and all other files. Exactly as i wanted to.
Now i tried to upload it to a real webserver, and unfortunately my host does not allow such .htaccess files.
I tried openinging the files with file_get_content() and fopen() and giving them a text/plain header.. but nothing works. It first executes the scripts and shows the output in my textarea.
Do you guys have any suggestions on how i can fix this without .htaccess ?
Thanks!
Don't upload files into the webroot and let people access them directly. As you say, .php scripts (and probably a lot more) get executed that way. A classic way for arbitrary code execution attacks.
Store uploaded files outside the webroot where they're not publicly accessible and create a script that allows users to download the files, for example using readfile or Apache mod_xsendfile, after having done the necessary permission checks.
Also see Security threats with uploads.
My ad server has been hacked over the weekend.
It seems to be a widespread problem, according to this article.
There is something in there that got me thinking...
Attackers used one attack to get login
rights to his server, and then
uploaded a maliciously encoded image
that contained a PHP script hidden
inside it, he said. By viewing the
image, attackers forced the script to
execute on the server
How is this possible? Does it rely on the image being opened with GD or similar? Do they upload a script posing as an image, and somehow include it?
It can be as simple as uploading a file like
GIF89a<?php
echo 'hi';
If your upload script tests the content type via fileinfo or mime_content_type() it is recognized as "GIF image data, version 89a" since GIF89a is the only pattern/magic number that is required to identify a file as gif.
And the OpenX upload script apparently kept the proposed filename, i.e. it was possible to save this "image" as foo.php on the server. Now, if you requested that file via http://hostname/uploaddir/foo.php the script was executed as a php script because webservers usually/often determine the content type only by the filename extension, e.g. via
<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
php then echoes the leading GIF89a and executes the <?php ...code... block.
Putting the <?php block into a gif comment is slightly more sophisticated but basically the same thing.
Your server is parsing that file for w/e reason. The attackers are putting the PHP into the image comment.
How are you validating the file is an image? If you do it solely on mime type, then I believe they can fake the image header and include whatever they want after that. VolkerK has a practical example
In the perfect world, I wouldn't serve any public facing images via PHP for fear of such an issue.
Serve the image directly using the server; A good suggestion is to save those images to a directory where they can be served without PHP.
I think that's the gist of it, someone correct me if I'm wrong.
The only possibility I see for a server compromise is the image being included instead of read through e.g. readfile and other stream functions.
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.