I have been reading about where to securely save a PHP file that has my mysql database connection password. I understand from the forums that it should be saved in a folder above the webroot. I have a cloud server from a hosting company.I have access to root
The path to the public files is as follows:-
/var/www/vhosts/mydomain.co.uk/httpdocs/afile.php
Say I have a PHP file (containing my password) called sqlpassfile.php
Would the following be okay as a place to securely store it? ie in a new folder called Newfolder after vhosts??
/var/www/vhosts/NEWFOLDER/sqlpassfile.php
Sorry for a simple question but just want to make sure its secure
Thanks
All the nowadays PHP framework you will find do, indeed store their whole code base in a level under the web root.
They do not only store informations like credentials actually, they do store all the business logic of the application outside of the web root. They will then only allow a facade file to be accessed (most of the time a index.php or app.php) that will, then, with the help of controllers, handle every request and route you to the right page/content, and, of course, all the static content the site will use (your design images, your css, your js, ...).
For example :
Zend Framework does use a public folder where you will find an index.php and all the static files
Symfony does use a web folder where you will find two files app.php and app_dev.php and again all of the static files
So in your case you could do
/var/www/vhosts/example.com/httpdocs/ is the web root of your server
/var/www/vhosts/example.com/app/ store all the php code you need
/var/www/vhosts/example.com/app/config store all your configuration file, and then maybe your credentials files which you can call sql_config.php
/var/www/vhosts/example.com/httpdocs/afile.php will require_once '../app/config/sql_config.php
Usually, People just save the database connection information in a regular PHP file, for example, Wordpress saves the connection info in it's wp-config.php. Simply because nobody is able to see your password by visiting that php page, nothing is returned.
To make it more secure, you can disable access to php file while mod_php stopped working. Try this in you .htaccess
<IfModule !mod_php5.c>
<Files *.php>
Order Deny,Allow
Deny from all
</Files>
</IfModule>
Please also have a look at this post:
Password in file .php
Whether your method is safe depends on the configuration of the server, something that providers are not often very good at documenting.
Your first line of defence is keeping what is essentially confutation data inside a file named with a .php extension. So if it is accessible from a browser the webserver will execute the file rather than returning the data. You certainly want at least 2 levels of security on your data (each of which you have tested independently).
Considering the path you have chosen, /var/www/vhosts/NEWFOLDER/sqlpassfile.php what happens if you request http://NEWFOLDER/sqlpassfile.php from the server? (In most cases, nothing but once in while....) Generally its better practice to keep it well clear of the directories your webserver uses.
Related
Good day all,
I have a folder called documents in my site root, this is password protected by a .htpasswd file, but it is allowed to be accessed by a script to view.
how would I allow a script to be able to download the file without accessing it directly from the directory?
I'll give an example to explain the situation.
on my home page I display the picture test.jpg, this image is in the documents folder that is protected. The image displays correctly on the home page.
If type in the address bar www.domain.com/documents/test.jpg it does not display or downloads, but asks for a password.(this I want, but don’t want people to type in a password for each file they want to download)
Is there a way that I can make php or JavaScript download the document without ever having to prompt for a password? Other words bypass the .htaccess rule?
thanx in advance
I've retagged adding PHP and Javascript. There is nothing stopping you writing a remapper PHP script which is outside the documents folder and therefore accessible without Apache authentication. This could issue a readfile() to send the file (see the document example and user contributions for a more detailed explanation. Since this is a server-side script, it will have direct access to the protected directory.
Of course you might want to implement some form of access control, say appending a request parameter check which is based on the md5 of the filename plus a shared secret. This would be easy to compute in the calling script. However, once you move such access negotiation to a client-side script you need to accept that this could be retro-engineered and exploited by any experienced hacker.
As a footnote, if you want to allow users to download your images, why are locating them in an access controlled directory. Why not just move them out of this directory?
As Barry said, the .htaccess is processed before any PHP is, so bypassing it is not an option. You will have to either change the .htaccess configuration or write a remapper PHP script.
I suggest changing the .htaccess configuration to allow direct download links but deny directory listing. This will allow people to download direct links such as http://www.example.com/documents/some-file-name.ext without being prompted for a password, but they will have to know the link ahead of time - they won't be able to view the /documents/ folder to see everything in there.
You can do this by commenting out or removing the Auth directives:
#AuthUserFile /path/to/.htpassword
#AuthName "Name"
#AuthType Basic
#Require Valid-User
And adding a directive to block directory listing:
Options -Indexes
I'm working on an installer for a project of mine and the installer will create a configuration file.
I have it working 99.99% fine, but in that file i want a check to ensure a hacking can't access it directly, and that code uses the $_SERVER super global, which in every run, gets parsed by php so it breaks the logic I'm trying to go for.
does anyone know I can get the superglobal to stay intact as it is without it parsing or should i rethink my logic and add it elsewhere?
for those who may want to see the code, here it is:
#Disable direct access.
if(!strcasecmp(basename($_SERVER['SCRIPT_NAME']),basename(__FILE__)) || !defined('accessed')){
die('<string>No Direct access is allowed for this file.</string>');
}
Assuming you are using Apache (or any .htaccess compatible server), you just have to create a .htaccess file in the folder holding your configuration file, containing the following:
<Files config.php>
deny from all
</Files>
It will prevent any access to this file through an HTTP request.
See using .htaccess files for details.
Don't use in-script or .htaccess protections - just write the file somewhere outside of the document root. If you don't want something to become available, don't make it available.
Putting it in the document root is like your bank hanging sacks of money in the front window with "do not steal" written on them.
I'm slowly learning PHP, MySQL, along with some HTML, using localhost as my webserver. However, I'm starting to wonder how my .php files are going to be secured if I put this actually on the Internet.
I have a webpage at localhost/app.php that includes a form, some PHP code, and some MySQL queries. The MySQL credential information is located one directory above where app.php is located, but how do I prevent from strangers accessing the contents of app.php, including MySQL data structure, commands I'm using, etc. When you view the source code in a browser, you only see the HTML part of it, but couldn't someone download app.php and look into the actual file if he wanted to?
What's the proper way of constructing the file structure? Links or comments are greatly appreciated! TIA!
Well, if you're using the .php extension, then Apache will serve up the parsed version -- echo and print will output but your variables won't.
If you're still concerned there's a few ways of making your files more secure.
Apache aliasing is common -- it lets you have one directory act like it's another. In this case, you'd alias your PHP directory to some directory on your domain. If your file structure is /home/user/my_files/, you might alias my_files to be www.my-domain.com/files. The script would not be accessible there to the requests, but it would be accessible to something on the server.
Symbolic links or symlinks can accomplish the same as the above.
simply place the config files somewhere else and directly reference them. Generally not a good idea as it is hard-coding file locations, but it is an option.
the CodeIgniter method: in your index.php have define( 'IN_APPLICATION', 1 ); in your config files have if( !defined( 'IN_APPLICATION' ) ) die( 'No direct script access allowed' );
No. the php is parsed if the page is requested over HTTP. The person would have to know a vulnerability in your app, Apache or PHP or have some other access such as FTP.
You can move the files out of your wwwroot and reference them elsewhere. Also, never name your include files as .inc. always name them `.php.
Try to download the .php file on your localhost. You'll find that all you get is HTML code. This is because of how a server works. Here is an example with a php file
Client (usually a web browser) sends a HTTP request to the server, i.e:
GET /app.php HTTP/1.1
The server takes the request and processes it. In the case of a php file, the server should process the php file into HTML.
The HTML is returned to the client.
If you are using Apache, and want to make sure that the php files are being processed, make sure these rules are in your apache2.conf:
LoadModule php5_module modules/libphp5.so
AddHandler php5-script .php
AddType text/html .php
And, just for fun, if you did ever want to expose your php source, add this line to apache2.conf:
AddType application/x-httpd-php-source .phps
To be secure, make sure that your mySQL configuration files and anything else you don't want public are stored outside the directory you are serving up. The apache docs are a great resource for understanding how all this works.
While there is not a direct problem with doing this, (many applications do this, and since the source cannot be seen without hacking your site), many applications solve this using a 'frontcontroller'. A frontcontroller is used a lot in MVC structured (Model, View Controller) applications.
A typical structure is like this:
app/ (applications, controllers and views)
lib/ (libraries, generic logic)
config/ (your configurations)
web/ (your webproot, only for css, images, javascript etc.)
web/index.php (your frontcontroller)
By only exposing index.php and placing all php and sensitive files outside of your webroot they will not be accessable for anyone from the web.
This may be a really stupid question...I started worrying last night that there might be someway to view PHP files on a server via a browser or someother means on a client machine.
My worry is, I have an include file that contains the database username and password. If there were a way to put the address of this file in to a browser or some other system and see the code itself then it would be an issue for obvious reasons.
Is this a legitimate concern?
If so how do people go about preventing this?
Not if your server is configured right. I think discussion on how that is done belongs on serverfault.
To add on to the other answers:
If you use a file extension like .inc there's indeed a higher risk. Can you open the file directly in your browser?
The most important advice is missing:
Only the files that should be accessed by a browser, should be in a publicly accessible location. All the other code (and configuration) should be in a completely separate directory.
For example
root
- webroot
- includes
- config
Only 'webroot' is exposed by your webserver (apache). Webroot can for example contain a single index.php, along with all your assets (javascript, css, images).
Any code index.php needs to load comes from 'includes' and all the configuration from 'config'. There's no way a user could ever directly access anything from those 2 directories, provided this is done correctly.
This depends on the file extension you have given the include file.
If the extension is one that is known and executed by the web server, it will be protected. If you browse to the file, the server will try to execute the code rather than just returning it as plain text.
If the extension is not known by the web server it will serve it as plain data, so anyone (who can guess the file name) can browse to the file and see the source code.
A Directory Traversal Vulnerability can used to obtain files off of the remote mahine. Alternatively you can use MySQL based sql injection to read files using load_file(). You can also test your system with w3af's urlfuzzer which will look for "backup files", such as index.php.zip. Also make sure that all files have .php extensions, a .inc can be viewed from the public. I would also disable Apache directory listing.
Normally there should be no way to view the PHP files remotely... it would be absolutely pointless. This completely depends on what web server you are using and how it's setup though.
Having looked around I can see that it is possible to protect a directory via the .htaccess by adding these lines:
Order allow,deny
Deny from all
This apparently protects the directory so that only local non web-access is possible.
This allows me to keep my includes in a subdirectory of the main site directory which is good for organisation and it can be used on the projects where I do not have access to folders outside the web root.
Does anyone else use this method?
Just for good measure I've put the directory permissions to execute only.
And the include extension is PHP as suggested by others.
I have an config.php file where I simply make an huge array that contains all the framework configuration. Also the database source string thing like "mysql:host=localhost;dbname=mydb" (whats that called, btw?) and username + password for DB. I'm afraid this is:
stupid
not good; better solution there
not secure (?)
so how do the PHP experts do that?
If you have a www, httpdocs or public_http folder or something like that, where your php application is situated, then it is good practice to put the config file outside of that folder, and just access it like this:
include "../config.php";
Nobody can gain access to that file without FTP access, and so it's relatively safe compared to having it in the application folder.
If you don't have such a folder, you can create one, and make a .htaccess file in the root, which redirects all requests to that folder. There are many different ways to do that, but that's a different question all together.
I store it in a plain text ini style configuration file, usually above the web root so as not to allow users access to it. In the cases where it is accessible, I usually have a .htaccess file with deny from all so as to prevent all access to it.
Storing it in a PHP file accessible to users should be fine, but it isn't ideal. If the sever handles PHP files correctly, even if people can access the file, they can't access the values as they just get the output (nothing). There are of course issues with this, (see comments).
Using PHP files is the most common method with PHP projects (Both FOSS and commercial) I have used. Most of them didn't both storing them above the web root. With any stable setup, there is on the face of it very little point in storing your configuration file above the web root, although given Murphy's law it is worth doing if you can (That or use .htaccess or the equilivent for your server to deny user access to a directory)
That's how most do it, but you could also try some of these solutions:
Save the configuration file outside the web folder (this requires that the open_basedir configuration in PHP is disabled).
Restrict access to the configuration file by using .htaccess:
<Location /config.php>
Order deny,allow
Deny from all
</Location>
Use .ini files and the parse_ini_file function (this is not really a solution in itself, but could be combined with the others)
Why storing DB username & password in "config.php" is not fine? as long as i know, the data in this file can't be shown publicly.
E.G.
<?php
$DB_User = "amindzx";
$DB_Pass = "Something";
// connect to DB and so on.
?>
unless if the hacker can gain access to your FTP.
Why it's stupid to hold simple config.php file without any securities? Even if programmer finds this file he can do nothing, because, like amindzx said "this file can't be shown publicly." Or I'm wrong?
With sensitive info like database or payment gateway credentials, and when I have control over the server, I like to add lines like the following to my apache virtual host config:
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
In your PHP, you can access these using $_SERVER['DB_USER']. You can make this config file readable only by root, which you can never do to a file that php accesses at run time. One caveat: Be sure you disable php_info and don't expose these variables with something silly like print_r($_SERVER). (Much of this is paraphrased or stolen from here.)
For non-sensitive configuration, I like to do a class full of constants, which is similar to your setup, but I like the OOP-ness of it.
class Application
{
const CONTACT_EMAIL = "me#mysite.com";
}
usage:
$contactEmail = Application::CONTACT_EMAIL;
I usually store settings in a config.php too, such as database connection settings, file paths etc.