[johnnie2]

Reading through the forum posts and docs, I've gathered that IPF provides a Configuration Manager that allows the end-user to edit an application-provided file via a simple text editor. Afterward a 'main page' is launched by the end-user to validate/record these changes.

Could other features of IPF then be used to protect this configuration file? My concern here is unauthorized access by outside parties to this configuration data; if this data is stored within a PHP file, it may then be remotely included, its contents read, etc.

Would instructing IPF to set file permissions to prevent access from outside parties curtail this problem? If so, what permissions should be allowed (user/group) such that the application's own PHP files may still access the configuration file?

Thanks in advance for any responses, and apologies if this is slightly off-topic.

[liaison]

Hi

You raise an interesting issue that's not just confined to IPF. Firstly, on file permissions, the general use for custom permissions is of course to elevate permissions to grant write access to files or directories by the web server rather than reducing permissions. As config files generally need to be at least read by the web server, restricting permissions on config files would more than likely prevent them being used at all, so the permissioning feature is probably not going to help.

If config files are PHP files, the risk from access outside of the web server is probably none. Unless a web server is misconfigured, remote inclusion should not be possible as a PHP based config file will be processed as a PHP file (as that's what it is), and so will most likely just produce a blank page if accessed directly. We generally caution against using PHP files as config files as there may be possible exploits on the PHP product itself through arbitrary code being inserted into the config file, but this does then raise a potential problem as a plain text file, e.g. config.txt, more than likely could be read by an external request.

The use of .htaccess files may therefore be preferable to lock down a config file directory so that web requests to the config directory are redirected or blocked, while PHP includes or file access functions, which aren't affected by .htaccess files, can read the config files.
_________________
Community Admin

[johnnie2]

Thanks for enlightening me.

I'd made an error in assuming that a remotely-included PHP file would render as the actual PHP code itself, not as the output of this code. Thinking on your post for some time finally forced this realization.

OK, since a PHP file accessed by any outside party (via remote inclusion or browser) will produce the output of said file, my security problem seems to be solved; however,

[Alasdair]

[liaison]

[johnnie2]

You both raise very interesting points; overall, the use of PHP configuration files raises very little direct security risk but poses an indirect risk via arbitrary code injection. The main advantage of moving to a non-PHP config file is to minimize the possible damage of an adversary who has discovered a flaw in the system.

Though I'd rather concentrate on fault prevention rather than damage control, the most robust applications probably have both of these combined in a sort of harmony. This, added with the realization that the remainder of the codebase would be itself protected from intrusion (encoding and Loader checks), urges me toward a non-PHP config file.

Therefore I am fortunate to have found parse_ini_file(), meaning I can rely on PHP to conveniently parse and return settings in an array.

Now, does anyone know of any security issues associated with the use of parse_ini_file()?

[johnnie2]

Good, I'll take the ensuing silence as a 'no.'

I've just integrated parse_ini_file() into the configuration settings loading portion of my application, and it seems to work quite well. Combined with an .htaccess file this should solve the security issue with which I started, so I thank you all again for your suggestions.

I'll keep you posted should I come up with anything further.

[johnnie2]

For the interested, the directive for use in the .htaccess file is Deny from all. The effect is the user meeting with a Forbidden notification on access into the denied directory, including all files and subdirectories; PHP includes and requires into the denied directory are unaffected.

Note that use of .htaccess files must be enabled in the server's main configuration file. (troubleshooting from the Apache server docs)