My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.
Related
I'm trying to query environment variables that i have set my .bashrc file (i'm running Ubuntu 14.04) in a PHP scripts that run's under Apache server.
When i query the getenv('MY_VAR_NAME') or $_ENV['MY_VAR_NAME'] while accessing the page, it seems that those variables are missing..
My guess is: when the script is been executed the user is www-data, so 'MY_VAR_NAME' is not accessible.
Is there any procedures / best practices to this kind of problems ?
Thanks
My guess is: when the script is been executed the user is www-data, so 'MY_VAR_NAME' is not accessible.
Your guess is correct. :)
Is there any procedures / best practices to this kind of problems ?
What most programmers would do is to have a configuration file containing these variables. You would store the configuration file in some area where the PHP scripts could get to it -- whether that's in a home directory somewhere, in /etc. or in some other place such as in the web root or a directory near it.
Different frameworks take different approaches to the format of the configuration files -- some are PHP scripts, some are YAML files, some are windows/DOS format INI files, some are XML, some are JSON, etc.
Personally I like the idea of doing this:
Store in a simple INI file only the configuration required to access the database.
Store all of the remaining configuration in a database table, and build an editor for the parts that you need to be able to edit.
Cache the contents of the configuration database table in memcached.
Whichever method you use is up to you, however, and will vary depending on the needs of your application.
I recently updated my server to use SuPHP to increase security.
One downside is that I used to be able to include files from my other domains hosted on my server using absolute paths to the file. This doesn't work anymore.
The file in particular that I include from other domains is my functions file which is huge and used on all my websites. For the sake of maintainability, I've been including a central file rather than uploading the file to each server every time I make changes.
I thought that saving the functions file as plain text and using file_get_contents() across domains might be the right way to go. But apparently this doesn't work.
Is there a way to make it work?
Or is there some other whizz bang function that can help me achieve my goal?
Cheers.
It sounds like you need configure open_base_dir in each of your websites vhosts so they are allowed to access the directory where these function files reside. You should put them in a common location.
open_basedir
Another alternative would be to use php_info() to check your include path to see if there is a suitable location already configured where you could place these files, then simply include using include()
include_path
I have a doubt about PHP, Apache, server interpretation... I know that when a PHP file is loaded by the browser from an Apache+PHP server it is interpreted and only the HTML and plain text is showed but is there a way to download this files instead of interpreting them?
In this case it would be very unsecure because MySQL passwords would be unsafe.
Is it any security measure to prevent this or it's impossible to download this files?
As long as your server is setup properly it isn't going to happen.
A good step though is to put all of your actual passwords and whatnot in a config.php and including it. That way you can use htacces too block that file so that should your server ever start serving the raw pages that file won't be accessible anyway.
To clarify if you create a .htaccess file and place it in the same folder as the config.php with the below information that file will not be served, even if requested directly. Simply define your config stuff (db name, user name, password, hashes, etc) in this file and include_once it at the top of each page that needs it and you will be good to go.
<files config.php>
order allow,deny
deny from all
</files>
There is no way to 'download' PHP files, but for more security you can place your 'core' PHP files outsite of the public_html folder
Unless the PHP interpreter stops working for some reason, it's not something to worry about. Most servers are designed to interpret the PHP files every time they are requested and serve only the interpreted HTML text. It's possible to secure your sensitive PHP settings files just in case - often by placing them outside of the root directory with modified permissions.
The only way someone could download the files is to have a server set up that serves the raw files. As long as you don't have such a server set up, they're inaccessible. If the only server software on your system is Apache and it's configured correctly, people cannot see your source code.
However, if somebody seeing your source would render your app vulnerable, you might want to give some thought as to how you can fix that problem. Lots of secure open-source software exists — why would yours being open-source cause problems?
With proper configuration apache guarantees that files will always get interpreted and won't be offered for download.
You always may install fault update or make wrong configuration, but with skilled admin and stable release those cases just don't happen.
I've just bough VPS account for testing and development.
Is there a function of PHP to parse Apache config file, PHP config, FTP Server config, zone files, etc? Also a way to insert data into config file.
I want to create a simple Control Panel to add ftp accounts and web account (with domain). If you have done it before - how did you do it?
It would be quite challenging to learn
Thanks.
No, PHP has no functions to parse the config files of those programs - you'll have to write a custom parser for most of those formats. However, for php.ini you might be able to use PHP's ini functions.
Most webhosting control panels either create the whole config file based on their database - i.e. they never read it but only (over)write it or they require you to include (apache and bind support that for example, for PHP you can use php_admin_value in the apache virtualhosts) their generated file - which is also never read by the tool.
If you really want to create a tool that actually modifies existing files, don't forget that you cannot simply skip comments as nobody would want an application to rewrite his config file stripping all comments.
You may be able to use the follow pear library to parse apache config files:
http://pear.php.net/manual/en/package.configuration.config.avail-container.apache.php
Parsing a php.ini file, depending on what you want to do, is probably best done with ini_get
I'm not aware of such functions and I highly doubt they exist for the simple reason that there are just too many HTTP / FTP / SMTP / ... server implementations. Control panels like cPanel, WebMin and others usually do the heavy lifting for you and some even provide an API to automatize things from PHP.
For the PHP configuration the following functions will probably do the trick:
ini_get()
ini_set()
ini_get_all()
get_cfg_var()
Bare in mind however that not all PHP configuration directives can be changed with ini_set().
I often see examples in PHP that include.inc files. What is the meaning of .inc? What it is used for? What are the disadvantages and advantages of using it?
It has no meaning, it is just a file extension. It is some people's convention to name files with a .inc extension if that file is designed to be included by other PHP files, but it is only convention.
It does have a possible disadvantage which is that servers normally are not configured to parse .inc files as php, so if the file sits in your web root and your server is configured in the default way, a user could view your php source code in the .inc file by visiting the URL directly.
Its only possible advantage is that it is easy to identify which files are used as includes. Although simply giving them a .php extension and placing them in an includes folder has the same effect without the disadvantage mentioned above.
If you are concerned about the file's content being served rather than its output. You can use a double extension like: file.inc.php. It then serves the same purpose of helpfulness and maintainability.
I normally have 2 php files for each page on my site:
One named welcome.php in the root folder, containing all of the HTML markup.
And another named welcome.inc.php in the inc folder, containing all PHP functions specific to the welcome.php page.
EDIT: Another benefit of using the double extention .inc.php would be that any IDE can still recognise the file as PHP code.
Generally means that its a file that needs to be included and does not make standalone script in itself.
This is a convention not a programming technique.
Although if your web server is not configured properly it could expose files with extensions like .inc.
It's just a way for the developer to be able to easily identify files which are meant to be used as includes. It's a popular convention. It does not have any special meaning to PHP, and won't change the behaviour of PHP or the script itself.
This is a convention that programmer usually use to identify different file names for include files. So that if the other developers is working on their code, he can easily identify why this file is there and what is purpose of this file by just seeing the name of the file.
Just to add. Another disadvantage would be, .inc files are not recognized by IDE thus, you could not take advantage of auto-complete or code prediction features.
In my opinion, these were used as a way to quickly find include files when developing. Really these have been made obsolete with conventions and framework designs.
Note that
You can configure Apache so that all files With .inc extension are forbidden to be retrieved by visiting URL directly.
see link:https://serverfault.com/questions/22577/how-to-deny-the-web-access-to-some-files