ionCube Logo
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


 
Post new topic   Reply to topic    ionCube Forum Index -> ionCube Package Foundry

Protecting config data

Author Message
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Sat Dec 31, 2005 1:20 pm    Post subject: Protecting config data Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2757

PostPosted: Sat Dec 31, 2005 5:37 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Sun Jan 01, 2006 7:03 am    Post subject: re Reply with quote

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,

nick wrote:
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[.]


This is baffling me; from what I understand atm the only way arbitrary code could be inserted into a PHP config file is through direct action of the user (administrator) of the application. Therefore if the admin exploited his copy of the app in this way, wouldn't he simply be putting himself at risk?
Back to top
View user's profile Send private message Visit poster's website
Alasdair



Joined: 11 Jan 2005
Posts: 30

PostPosted: Sun Jan 01, 2006 3:12 pm    Post subject: Re: re Reply with quote

johnnie2 wrote:

nick wrote:
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[.]


This is baffling me; from what I understand atm the only way arbitrary code could be inserted into a PHP config file is through direct action of the user (administrator) of the application. Therefore if the admin exploited his copy of the app in this way, wouldn't he simply be putting himself at risk?


Not necessarily. If we take the phpnuke content management system/portal for example (a common PHP application that is generally considered insecure due to the number of security issues found with it over time) there might be a security issue with the code there that would allow someone to format a URL, or even something like submit a specially formatted comment to a news article, to access a write function and put extra data in the config.php file. The next time the file is accessed (e.g. the next time someone visits a page) that code would then be executed. Depending on the code it could create an administration login for the hacker, wipe the mysql database etc… Basically, if there is an input somewhere and it’s not properly checked/sanitised, it opens the possibility for hackers to get at it and start prodding till they find a way to use that ‘opening’ to cause damage.

Applying this in general to PHP developers, it’s all about errors in the code that could pose a security risk; and as we’re all humans, we’re bound to make a mistake at some point – with potentially devastating results.
_________________
Alasdair Stewart - SolidPHP, Inc.
Home of the PHPAudit licensing system
Back to top
View user's profile Send private message Send e-mail
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2757

PostPosted: Sun Jan 01, 2006 5:27 pm    Post subject: Reply with quote

johnnie2 wrote:
This is baffling me; from what I understand atm the only way arbitrary code could be inserted into a PHP config file is through direct action of the user (administrator) of the application. Therefore if the admin exploited his copy of the app in this way, wouldn't he simply be putting himself at risk?


It depends what he put into the config file. If we consider a poorly written program that is fully featured, and uses a global variable to control what features are available; e.g. a demo version that has some features disabled. If the global has been setup before the config file is read, the user could first put in a line to the config file that displays the contents of $GLOBALS. This might expose the crucial variable name, and by then putting code in the config file to overwrite the variable, the behaviour of the scripts could be changed.

Many apps wouldn't have that type of critical flaw, but some probably do, and a developer should keep in mind to consider whether the behaviour of their application could be undesirably changed by actions such as modifying state, including of files that replace functionality of their application etc.
_________________
Community Admin
Back to top
View user's profile Send private message
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Mon Jan 02, 2006 7:27 am    Post subject: re Reply with quote

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()?
Back to top
View user's profile Send private message Visit poster's website
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Wed Jan 04, 2006 6:56 am    Post subject: re Reply with quote

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

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.
Back to top
View user's profile Send private message Visit poster's website
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Wed Jan 11, 2006 8:26 am    Post subject: re Reply with quote

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)
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ionCube Forum Index -> ionCube Package Foundry All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum