I'm the SysAdmin of an AWS EC2 instance hosting a public website. The instance is running CentOS 7 with WHM/cPanel. Our website uses both PHP 5.6 and 7.1, and cPanel utilizes EasyApache 4. Since the 26th of July, every two weeks at exactly 2:04AM our .htaccess file is being modified by cPanel and completely breaking our website. The website would no longer load the webpage but instead download a file simply called "download". The file was harmless and only contained some laravel markup.
Once we discovered that it was the .htaccess file causing the site issues, the simple fix of replacing the file with a version from a backup solved the issue temporarily. Last time it happened on the 8th, I tried to restrict access by setting to the .htaccess file by setting:
Set “Depth to recurse for .htaccess checks” to 0.
in cPanel, but no dice.
From some other posts/sites I've managed to figure out that it may be EasyApache doing the writing to the file, and that this happens when sites have multiple versions of PHP in use at the same time. Below is what's being added to the .htaccess file that's breaking it.
# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php71” package as the default “PHP” programming language.
<IfModule mime_module>
AddHandler application/x-httpd-ea-php71 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
Commenting this out immediately fixes the issue.
Unfortunately I can't seem to figure out a solution to this issue however and was hoping I could get some help here. The website as it is, is on ice development-wise and very few changes will be made in the future, and definitely none to the .htaccess file. There may be a quick, dirty fix changing the permissions of the .htaccess file to 444 but I want to figure out the actual issue as opposed to implementing that.
I noticed that it's possible to run a file via PHP even if its extension wasn't .php, for example file test.xyz.php.whatever.zyx can be still run with PHP even when the extension isn't .php! It just happens to have .php. in the filename, and that's enough for my Apache to run the PHP script.
I tried (as someone suggested) to put this in a .htaccess file on that folder:
php_flag engine off
But it didn't work on my machine.
The only solutions I know for now are:
Rename to known file extension, which is not run via PHP, such as .txt.
Remove all dots from the filename, thus making it extensionless.
But I'm still not sure how these solutions would work on other servers than my Windows server (with Apache).
Is there any other solutions which doesn't need the filenames to be renamed in any way?
for uploading by users I suggest that you upload a folder in a layer above the root path
in this case Only You Have Access To upload folder( In direct addressing)
and an attacker have not access to any files in this folder
Thus you disable an attacker action to run malicious file
To be completely secure, you'll need to do a couple of things:
Set your upload directory above your "public" folder, making it inaccessible from a browser. This setting is in php.ini (php config file). You'll need to restart Apache for this to take effect. On most Redhat / Fedora / CentOS web servers, this can be:
upload_tmp_dir = "/var/tmp/"
OR, on my local Windows 7 WAMP install, it is set to:
upload_tmp_dir = "c:/wamp/tmp"
Disable scripts from running on that directory (c:/wamp/tmp), in .htaccess:
RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
php_flag engine off
In your PHP script, get the uploaded file, filter it based on mimetype (not filetype extension), change the filename, and put it into a secured publicly accessible folder. In more detail:
create a whitelist of filetypes, ex: only images (jpeg, png, gif, bmp). This can be done using mime_content_type() http://php.net/manual/en/function.mime-content-type.php or the newer finfo_file() http://us3.php.net/manual/en/function.finfo-file.php
choose a new filename, often it's best to use a random MD5 hash based on the original filename + salt + timestamp.
move it to a public folder, ex: "c:/wamp/www/project_name/public/uploads"
Preferably use an MVC framework, such as Zend Framework, which includes filetype filtering.
If you do all of that, you should be secure. Obviously you'll never be 100% safe, since there are countless obscure exploits targeting PHP, MySQL, the command line, etc, particularly on older systems. On larger company webservers (what I work on), they disable everything, and selectively enable only what is required for the project. With a system such as WAMP, they enable everything, to ease local development.
Good practice for working on a professional project is to get a cloud server account with Rackspace or Amazon, and learn how to configure php.ini, and httpd.conf settings, as well as PHP security best practices. In general, do not trust the users input, expect it to be corrupt / malicious / malformed, and in the end you'll be secure.
First of all you need to understand what happens here:
test.xyz.php.whatever.zyx
Such a file on a webserver on it's own would do nothing. Only added configuration does tell Apache to execute PHP on that file.
So if you remove that added configuration, Apache won't care to find .php in there - be it at the very end or part of a stacked file-extension.
Check which handler you have set for php in your server configuration. Remove it for the upload directory. This then won't resolve any other configuration issues you might have with uploaded files, however PHP files aren't executed by PHP any longer then - which is what you want if I understood you right.
If you've got a problem to find out what this is about, you need to post your PHP configuration in your httpd.conf file and associated Apache HTTPD configuration files for your system.
The directive somebody told you for .htaccess:
php_flag engine off
does only work if you're running PHP as an apache SAPI module.
Instead of php_flag engine off you could remove the handler for PHP files using an .htaccess file for a single directory.
In the directory you are disabling PHP in, your .htaccess should include:
RemoveHandler .php .phtml .php3 .php4 .php5
RemoveType .php .phtml .php3 .php4 .php5
You can likely get away with the below however, depending on which AddHandler types you have configured in your default Apache configuration, which, on windows, should be in C:\Program Files\Apache<version>\conf\httpd.conf
RemoveHandler .php
RemoveType .php
You will also need to ensure that in your main apache configuration file, that the directory containing the .htaccess file is in, is covered by a Directory statement which has AllowOverride FileInfo set. You may wish to consider AllowOverride All if you will be using .htaccess files for other purposes - see the Apache documentation for AllowOverride for an explanation of the differences.
Personally, this is the main reason I no longer upload files to the web server under any circumstances. Instead, I use S3 / Amazon SDK to move the uploaded temp file directly to a bucket on S3 with Private permissions (I use S3, any other CDN will work just as well). If the file needs to be viewed or viewed by a web client, I use a "getter" function of sorts that integrates with the SDK to get the file and display it.
There are just so many uncontrollable variables that come into play whenever you allow any kind of file upload to a web server, it can be difficult to manage permissions, filtering, and even just space. With S3 (or any other CDN), that is all very easy to manage, and all files are effectively quarantined from the server by default.
On Apache you could disable all dynamic handlers for the directory that contains the untrusted files.
SetHandler default-handler
this is not really good answer but hope useful in some special cases ...
you can use mod_rewrite in .htaccess file like this :
RewriteRule ^(.+).xyz.php.whatever.zyx$ index.php?openfile=$1 [NC,L]
and inside your index.php file :
$file = secure_this_string($_GET['openfile']);
include($file.'.xyz.php.whatever.zyx'); # or some other files
remember to see this answer for security reasons StackOverFlow
and in test.xyz.php.whatever.zyx file :
<?php echo 'hello';
now if client requests /test.xyz.php.whatever.zyx file , out put should be 'hello'
A simple regex would do the job
<?php
$a = strtolower($_FILES["file"]["name"]);
$replace = array(".php", ".phtml", ".php3", ".php4", ".php5");
$_FILES["file"]["name"] = str_replace($replace, "", $a);
?>
This works fine on any server
The following .htaccess-code could work and deny access to files containing "php":
<FilesMatch "php">
Deny from all
</FilesMatch>
I could reproduce your issue quite easily on our server. There is a way to fix this, you need to edit /etc/mime.types and comment out lines
#application/x-httpd-php phtml pht php
#application/x-httpd-php-source phps
#application/x-httpd-php3 php3
#application/x-httpd-php3-preprocessed php3p
#application/x-httpd-php4 php4
#application/x-httpd-php5 php5
These lines cause anything with .php in name to be processed.
Once you comment out the entries in mime.types, mod_php config in /etc/apache2/mods-enabled/php5.conf has this entry which correctly only processes files ENDING with .php
<FilesMatch "\.ph(p3?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
What is REALLY SCARY is that this is a default config (Ubuntu 10.04 in our case).
EDIT
On Windows the mime.types file should be in apache_home/conf/mime.types
I'm trying to use .htaccess files with PHP on OS X (Snow Leopard, 10.6.8), but when I go to localhost/ the browser just downloads whatever file it's lead to by the rewrite rules (rather than getting the output of the server-side execution of the PHP).
I've confirmed that PHP runs with Apache on other, simpler installations. For debugging I'm targetting check.php script so that should be good.
The web is full of guidance to hunt down and replace all AllowOverride None statements with AllowOverride All, but my apache configuration for this differs from the base OS X installation and doesn't include any of the various files with the AllowOverride None directives. I've set all of those touched by my configuration.
This same configuration runs the php scripts just fine when they're hit by the URL.
I've confirmed that mod_rewrite.so is available and loaded.
I'd appreciate help diagnosing / debugging this.
EDIT:
Also, when I hit the page from Firefox, I get a dialog saying "You have chosen to open [blank, for the index url] which is a: application/x-httpd-php5" and the choice to save or run. That x-httpd-php5 value is the string I use in the AddType directive in the .htaccess file.
Make sure Web Sharing is turned on in the preferences.
My ISP requires me to put the following in my .htaccess files:
AddType x-mapp-php5 .php
But that breaks my development machine.
I don't really understand what that directive is for, but I'm sick of commenting it out for dev, and uncommenting it whenever I need to upload a new version.
Is there some way of supporting it in dev?
You could try the <IfModule> Apache directive to distinguish your development machine from the production machine.
E.g. the following would work if you're running PHP as an Apache module, and your ISP runs it as CGI:
<IfModule !mod_php5.c>
AddType x-mapp-php5 .php
</IfModule>
You could also check for the existence of a PHP4 module.
Or you could pass a startup parameter to Apache on your development machine and check for that using <IfDefine>.
This merely tells the web server that files with the extension .php are to be handled by the PHP module.
But I would recommend asking web-server related questions on serverfault.com, where your question won't get closed (with the reason belongs on serverfault.com) and where you will receive much better answers than here.
I'm trying to port a PHP site developed by another coder (who is no longer around) and I'm having a problem with the Apache Rewrite rules which are prompting a file download on the target server. I'm sure this is a simple problem, but I'm having some difficulty Googling an answer. I'm running on a (dedicated) Ubuntu Server with a standard installation of Apache and PHP5 and porting from shared a shared server where everything runs fine. No site files have been altered during the port.
The .htaccess file contains this code (only)
# Use PHP5 as default
AddHandler application/x-httpd-php5 .php
Options -Indexes FollowSymlinks
RewriteEngine on
RewriteRule ^html/(.*) /index.php?init=site\/$1\/$2\/$3\/$4\/$5\/$6\/$7\/$8\/$9
RewriteRule ^mykart$ /index.php?admin=true
RewriteRule ^mykart/$ /index.php?admin=true
RewriteRule ^mykart/(.*)$ /index.php?init=admin\/$1\/$2\/$3\/$4\/$5\/$6\/$7\/$8\/$9&admin=true
When I try to open the file http://www.mysite.com/html/#home the browser attempts to download the (index.php) file instead of displaying it, with the message
"You have chosen to Open
[dialog shows blank space here]
which is a: application/x-httpd-php
from....
"
I guess I must have missed something in either the PHP or Apache configuration, but what?
EDIT: To clarify, the server is running Apache2 and has several, functioning, PHP sites on it. Furthermore if I delete the .htaccess file and run a simple phpinfo display page everything runs fine, so it's not the execution of PHP per see.
I suppose that the MIME type application/x-httpd-php5 is not valid. I’ve tried it on my local machine and it caused the same behavior.
Have you tried application/x-httpd-php instead?
Looks like an Apache config issue, of course I could be wrong. Have you checked httpd.conf for the following lines:
# Add index.php to your DirectoryIndex line:
DirectoryIndex index.html index.php
AddType text/html php
I had a similar issue. Browser attempted to download links from php website, instead of loading them.
It wasn't Php interpreter issue for me, it turned out to be misplaced .htaccess file. However, I didn't realized that disabling the htaccess file solved the issue for hours, due to browser cache.
So, don't forget to clear your browser caches! And restart Apache.