I've been pulling my hair off trying to find a solution for denying access to a file for all AJAX/ PHP/ in-browser requests EXCEPT when they come from one (other) directory/ file on the same server.
I have a .htaccess in the directory of the JSON file. The file is fetched by a CMS plugin as follows (pretty standard):
Javascript makes an AJAX call to a PHP file on the server, called handler.php.
handler.php then retrieves the contents of the file and returns it to JS.
I can't use rewrite rules, as it is not a prereq. for the CMS. I also can't set a known domain name, as it is dynamic. Ideally I would do Allow from SELF.
I have tried the following .htaccess configs without luck:
Order Deny, Allow
Deny from all
Allow From <ownDomainName/subpath>
Or:
Order Deny, Allow
Deny from all
Allow From <ownDomainName/subpath/fileName.ext>
I tried with setEnv directive too, and a mixture of others involving using <Files>, <Directory> and <Location>. If I just Deny from All the PHP cannot access it. Is there any solution for restricting access to a JSON file?
Also, does it have anything to do with the fact that I am testing on localhost?
There are 2 types of access to the file.
From web, where .htaccess rules or server (apache) config is applied.
By app or script running on the server machine, where filesystem permissions are applied.
So you can deny all requests in .htaccess file, but PHP script still can access the file via FS (dependent on FS permissions).
I'm adding some database usage to a public facing site, and I wanted input on what the most secure way to store mysql connection information might be. I've come up with a few options:
First I could store the config in another directory, and just set the PHP include path to look for that dir.
Second, I know there are some files that apache won't serve to browsers, I could use one of these types of files.
Third, I could store encrypted files on the server, and decrypt them with PHP.
Any help would be much appreciated.
Storing the config outside of apache's document root is a must
You can configure apache to disallow any files with htaccess.
in the config folder add a .htaccess with the following
order allow,deny
deny from all
If you don't want to use .htaccess as #johua k, mentions, instead add
<Directory /home/www/public/config>
order allow,deny
deny from all
</Directory>
to your apache config.
This will deny any files in that folder from being served to anyone, which is fine since php doesn't care about htaccess you can just
include('config/db.php')
If you properly config your php scripts, they should never appear in plain text.
so a file like
define('mysql_password', 'pass')
would never display that text.
If you are worried about a shared hosting environment and another use having access to read this file then you should evaluate the security of the linux installation and the host. Other users should have any browsing access to your file. From the web files marked php should never return source.
You can explicitly tell apache not to serve the files ever, so they would only be include() or require() able.
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 have a processing file for my website's payments. It works just fine, but what I would like to do is log all the requests to this page so that if anything throws an error, the raw data is saved and I can process the transaction manually. The processing file uses fopen to write to the log file in another directory.
What I have right now is a separate folder on my root directory with permissions 755. Then a log file inside with permissions 777. The processing file that writes to the log file, in PHP if that matters, is set to 777.
This works right now, but the log file is publicly available. I know I can be doing this better and that the permissions aren't correct. How can I do this better?
Put the log file outside the document root. The PHP script that writes to it will still be able to get to it (via the full path) but Apache won't be able to serve it.
I came across this whilst searching the answer for myself. I don't believe there is a simple "permissions fix" to do what you want and perhaps the safest way is to put the log files outside of public_html directory.
However this can be a nuisance sometimes - especially if you are wanting to e.g. catch paypal ipn dump text in a log file, but not have it publicly accessible.
In such cases, you can use .htaccess file directives to allow write from script, but deny reading from public access.
For example, this works for me (Apache .htaccess in root public_html folder);
<FilesMatch "mycustom\.log">
Order allow,deny
Deny from all
</FilesMatch>
and if you have multiple logs you want to protect, use it like this, with "Pipe Separated";
<FilesMatch "mycustom\.log|ipn_errors\.log">
Order allow,deny
Deny from all
</FilesMatch>
It is worth noting that the above directives are deprecated as of apache 2.4 and you may wish to consider using more current directives instead: https://httpd.apache.org/docs/2.4/howto/access.html
Hope that helps you!
Last night I made some admin changes to my webserver. I use php. The php processor failed after the update and if someone went to my homepage, the php page would simply download and show the proprietary code and password to anyone visiting. So I was wondering if there is a way to prevent any form of download for php files using .htaccess -- but still allow for normal viewing of the files.
A good pattern to follow during development is to use a minimal initialization file, which invokes the actual application which resides outside the webroot. That way only a minimal stub with no critical information is exposed in a case like this.
Simplified example:
/
/app
critical_code.php
/webroot
.htaccess <- rewrites all requests to index.php
index.php <- invokes ../app/critical_code.php (or other files as requested)
The trouble here is that either .htaccess is serving your files to the user or it's not. You can't tell it to deny access to the .php files, because then access will be denied during normal use, as well. There is no fallback behavior for the PHP processor simply not running correctly.
Maybe it's worth temporarily moving the web root to point to an "under maintenance" site when doing big things like that, to minimize risk as much as possible.
Assuming you're using Apache, your .htaccess file would look something like this.
<FilesMatch ".*\.php">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
<IfModule php5_module>
<FilesMatch ".*\.php">
Allow from all
Satisfy All
</FilesMatch>
</IfModule>
The first rule denies access to all .php files. By default, the user will see a 403 (Forbidden) error.
If the PHP5 module successfully loads, the second rule will take affect, which grants access.