XML Configuration File

I'm rebuilding this "system" (5th time).
This time I want whoever want to use it, just copy it to their web directory, and use it.
First time, it should see there is no configuration file (xml), and create a copy from a template. The user will then be taken to a "settings" page, where they can enter and save database connection parameters.
After that, just when you run the system, it will just verify the config file exist, got the necessary nodes, and the values are still valid.

Wrote the following code, late at night (only way to keep gf studying for coming exam is sit here next to her working), and don't feel so comfortable about my code. But then, I never did this before. Though it does works perfectly well (Guess will set a session variable to say file have been checked. No use doing that each time a page load huh) Some masta mind take a look and comment?

Code:

---

<?php
        if($page_id=="config_settings")  /* dont care to chec file if we on edit settings page */
                return;
        $error                =        "";
        /* ensure the existence of our configuration file. If not exists, copy and rename template configuration file */
        $error = check_config_exists();                       
        /* does the file have the necessary fields (not corrupted?) */
        if(!$error) {
                $filename = $level."config/config.xml";
                $xml = simplexml_load_file($filename);
                /* see if database variables section exists */
                if(!isset($xml->database))
                        $error =  "Corrupt configuration file (Database settings missing). You might need to reinstall DataShop.";
                else if(!isset($xml->database->db_database))
                        $error = "Corrupt configuration file (Database name node missing). You might need to reinstall DataShop.";
                else if(!isset($xml->database->db_username))
                        $error = "Corrupt configuration file (Database user name node missing). You might need to reinstall DataShop.";
                else if(!isset($xml->database->db_password))
                        $error = "Corrupt configuration file (Database password node missing). You might need to reinstall DataShop.";
                else if(!isset($xml->database->db_host))
                        $error = "Corrupt configuration file (Database host name node missing). You might need to reinstall DataShop.";
                else if(!isset($xml->database->db_table_prefix))
                        $error = "Corrupt configuration file (Database table prefix node missing). You might need to reinstall DataShop.";               
                /*see if the variables are valid to connect to the database*/
                if(!$error) {
                        @ $mysqli = new mysqli($xml->database->db_host, $xml->database->db_username, $xml->database->db_password, $xml->database->db_database);
                        if (mysqli_connect_errno()) {
                                header("Location:".$level."config/settings.php");
                        }
                }
        }
        if($error)
                echo "This app is up to *****";
        else
                echo "all seems ok";

        function check_config_exists() {       
                $template = $level."config/ds_config_template.xml";
                $filename = $level."config/config.xml";
                if (!file_exists($filename)) {
                        if (!file_exists($template))
                                return "ds_config_template.xml seems to be missing. Please ensure this file exist in your config directory, or reinstall DataShop.";
                        if (!copy($template, $filename))
                                return "Failed to create config.xml. Please ensure ds_config_template.xml exists, copy and rename it to 'config.xml'.  Otherwise reinstall DataShop.";       
                }
        }       
       
?>

---

Hi StrangerInBeijing,

I'm no mastermind but I've had a quick look at your code...

Don't save your database credentials in a plain XML file! Anybody could navigate to www.yoursite.com/config.xml and view your information. It's a good idea to save them in XML format like you are, but make sure you secure the file so that it can't be retrieved by anyone.

I also noticed you didn't call exit() after the redirect. It is good practice, and safer to call exit() right after you send a redirect using header(). If you don't the script may continue to execute after the header() call until the browser receives the redirect.

PHP Code:

---

header("Location:".$level."config/settings.php");
exit(); 


---

If you wanted to optimise your code a bit, you can use single quotes 'around a string literal that has no variables', like when you have those error messages. If you use double quotes, the PHP interpreter will look for variables in the string, whereas with single quotes it won't waste time doing that. It won't make a lot of difference and is a preference thing really - some people like to keep it consistent by using double quotes for everything.

Hope this helps a bit:thumb: :wave:

thanks man,
I also thought about the password thing, and thought better md5 the password when writing it to the xml file. Better not let user's edit the config file manually (like with wordpress....just store your credentials for all to see!)

Cool explanation of the single/double quotes. Thanks again!

This thing say I must spread the love before giving you rep points....sorry

If you MD5 the password in the config file you'll have to somehow decrypt it when connecting to the database.

I would leave the file as it is, but just secure it from visitors accessing it. Theres a few ways you could do it:

• Use a htaccess to deny all requests for files inside the config folder.
• Use a htaccess to tell PHP to try and parse .xml files as PHP - this will give a blank screen when trying to view it in a browser.
• Save the config file as a .php extension. That would produce the same results as above.
• Store the config file above the httpdocs folder, this might cause you problems if you have an installer script.

The easy solution is to store the config file outside the document root. Then no one but your PHP script will be able to access it. Most of the time the database password is stored in plain text in the PHP script; why are we now worrying about it being stored in plain text in an XML file? :D

using one way encryption such as MD5/SHA will be of no use as you won't be able to retrive the password again the next time you need it. If you want to maintain server level security then I suggest you use the mcrypt extension to encrypt the password before you store it in the XML file. Of course, you would then need to store the key to encrypt it somewhere; preferably securely. Why not encrypt that too? But then what do you do with the key you used to encrypt the key? See where i am going here? :p

Quote:

---

Originally Posted by the182guy

Hi StrangerInBeijing,
I also noticed you didn't call exit() after the redirect. It is good practice, and safer to call exit() right after you send a redirect using header(). If you don't the script may continue to execute after the header() call until the browser receives the redirect.

---

As defined in the HTTP RFC, sending a location header should not be an indication for to the web browser to terminate any CGI script running. Apache will not terminate a CGI script or any executing module when it encounters a location header and will infact wait for it to finish before acting on it; i.e: keep the connection alive.

There are versions of IIS that will however terminate both the connection and script. While this doesn't comply with the HTTP RFC I don't think Microsoft have any plans to fix this behaviour.

If you have a properly written script then there is no need to call exit after you have sent a Location header because if you intend the script to exit then the location header shall be the last statement you execute. Conversely if you do not want the script to exit after sending the location header; perhaps you want to run some clean-up tasks, or write to a log then this should also be clear from the logical flow of your script.

If someone doesn't know when the script will finish then it might be wise to start considering a different career or hobby. :wave:

Quote:

---

Originally Posted by visualAd

The easy solution is to store the config file outside the document root.

---

That is one option I mentioned in my post, the only problem with it is if the app has an installer, it might run into problems with permissions to write above the httpdocs. I wouldn't like to be the one trying to debug that when I'm only trying to install an app.

Quote:

---

Originally Posted by visualAd

Most of the time the database password is stored in plain text in the PHP script; why are we now worrying about it being stored in plain text in an XML file?

---

I certainly would be worried if my password was stored in a plain XML file inside the httpdocs folder because like I said before, anybody could just navigate to the file and download it, you can't do this with a PHP script, so I would not be worried about storing the password in a PHP script.

I wouldn't bother messing about encrypting the password if the file is secure. If the app is being distributed then it can just cause problems for the person that installs it - even if there is a nice GUI for editting the config, the user at some point still might need to just open up the file and edit it.

Quote:

---

Originally Posted by visualAd

If you have a properly written script then there is no need to call exit after you have sent a Location header because if you intend the script to exit then the location header shall be the last statement you execute. Conversely if you do not want the script to exit after sending the location header; perhaps you want to run some clean-up tasks, or write to a log then this should also be clear from the logical flow of your script.

---

I agree that the script should be written in a way so there will be as few exit points as possible (pereferably one) in which case there would be no need for the exit() call, but if there is code following the header() call then calling exit() if you don't want the script to continue after the call is a good idea.

I wouldn't however put any code that I wanted executing, after the header() call. I think it makes a lot more sense to do that before the call to redirect.:wave:

Quote:

---

Originally Posted by the182guy

That is one option I mentioned in my post, the only problem with it is if the app has an installer, it might run into problems with permissions to write above the httpdocs. I wouldn't like to be the one trying to debug that when I'm only trying to install an app.

I certainly would be worried if my password was stored in a plain XML file inside the httpdocs folder because like I said before, anybody could just navigate to the file and download it, you can't do this with a PHP script, so I would not be worried about storing the password in a PHP script.

---

The majority of web hosting services will allow write access to at least one directory above the document root. If this is not the case then I would worry about their security policies and configuration and find another host.

The only secure way to keep a file which contains sensitive information away from public view is to keep it outside the document root. There are a number of reasons why you don't want to go down the route of using files with a php extension or using per directory configuration files to restrict access. One of which being that any configuration errors and / or security vulnerabilities could leave these files open to attack.

So if you are writing an installation script, don't overlook security in favour of usability.

Quote:

---

Originally Posted by the182guy

I wouldn't bother messing about encrypting the password if the file is secure. If the app is being distributed then it can just cause problems for the person that installs it - even if there is a nice GUI for editting the config, the user at some point still might need to just open up the file and edit it.

---

It depends on the level of security one requires. I would be more inclined to encrypt sensitive data if it is to be stored on a shared host. Again, you are putting usability before security.

I personally would not bother encrypting a database password. I would store it in the configuration file outside the document root and ensure the appropriate file permissions are applied. Encrypting it would be a false economy because I would still need to store the encryption key somewhere.

Quote:

---

Originally Posted by the182guy

I agree that the script should be written in a way so there will be as few exit points as possible (pereferably one) in which case there would be no need for the exit() call, but if there is code following the header() call then calling exit() if you don't want the script to continue after the call is a good idea.

I wouldn't however put any code that I wanted executing, after the header() call. I think it makes a lot more sense to do that before the call to redirect.:wave:

---

Indeed, if you want your script to terminate after the header call then you can use exit after. There is certain code however that is executed after the exit call. This includes shut down functions, class destructor's and exception handlers. That is why you do not want the web server prematurely terminating the interpreter process as soon as it seas a location header.

There are also instances where a response body may be required, in this instance it would be logical to send the Location header then output the response body rather than setting up an output buffer.

Quote:

---

Originally Posted by visualAd

The majority of web hosting services will allow write access to at least one directory above the document root. If this is not the case then I would worry about their security policies and configuration and find another host.

The only secure way to keep a file which contains sensitive information away from public view is to keep it outside the document root. There are a number of reasons why you don't want to go down the route of using files with a php extension or using per directory configuration files to restrict access. One of which being that any configuration errors and / or security vulnerabilities could leave these files open to attack.

So if you are writing an installation script, don't overlook security in favour of usability.



It depends on the level of security one requires. I would be more inclined to encrypt sensitive data if it is to be stored on a shared host. Again, you are putting usability before security.

I personally would not bother encrypting a database password. I would store it in the configuration file outside the document root and ensure the appropriate file permissions are applied. Encrypting it would be a false economy because I would still need to store the encryption key somewhere.


Indeed, if you want your script to terminate after the header call then you can use exit after. There is certain code however that is executed after the exit call. This includes shut down functions, class destructor's and exception handlers. That is why you do not want the web server prematurely terminating the interpreter process as soon as it seas a location header.

There are also instances where a response body may be required, in this instance it would be logical to send the Location header then output the response body rather than setting up an output buffer.

---

Good points visualAd, just to pick up on some...

If an app requires as high security as encrypting the password in the config file then IMO that alone constitutes a dedicated server rather than a shared host.

If common sense is applied, and the neccessary security measures used (found on a lot of articles online) then there should be no need to worry about having a password in a PHP script.

Take a look at some of the big projects on SourceForge, for example the XRMS customer relationship management system which is backed by a lot of people and is in use today all over the world. That stores the database credentials in a PHP config script.

I wouldn't say I would be favouring useability over security by doing this. I think there needs to be a balance - especially from the point of view of somebody selling the product. And as you said the security requirements depend on the web app in question

As for calling exit() after header(), yes it is better to not require this, but calling exit() solves a lot of problems with badly written scripts. Have a look on php.net at all the posters hailing the exit() function for solving their hours upon hours of headaches.

Anyway I will shut up babbling in somebody elses thread lol:thumb: :D

Thanks guys. Learned a bit from you two quote bucking each other.

I think what I'm going to do is:
1) Keep the config file in the web directory, as I really just want to make it a copy and run installation. Like Wordpress
2) Use a php file for the configration settings. Anyone trying to browse to it directly will see and empty page. Like Wordpress
3) Use some kind of encryption I can decrypt the password again, like suggested. Unlike WordPress.

Is ok right?

Quote:

---

Originally Posted by StrangerInBeijing

Thanks guys. Learned a bit from you two quote bucking each other.

I think what I'm going to do is:
1) Keep the config file in the web directory, as I really just want to make it a copy and run installation. Like Wordpress
2) Use a php file for the configration settings. Anyone trying to browse to it directly will see and empty page. Like Wordpress
3) Use some kind of encryption I can decrypt the password again, like suggested. Unlike WordPress.

Is ok right?

---

Sounds good. BTW I like your idea of storing the config settings in XML format, and I like your idea for a page to write the settings. I don't think you should scrap those ideas!

I know most PHP applications store database credentials in a PHP script underneath the web root. I think this is a bad idea. As visualAd, said any problem with the web server configuration will expose your credentials to the world (vBulletin, the forum software which powers this site, is one of them; just use Google Code Search to find countless unsecured vBulletin installations on the web).

For maximum security the configuration file should be stored outside the web root.

It can be harder to secure existing applications which are hard-coded to store the configuration file underneath the web root. In such cases one thing you can do is move the file outside the root and create a symbolic link inside (on Unix-based systems, at least), and tell your web server not to follow symlinks. However, this also relies on a correct configuration.


On point (1): Copying the configuration file does not make sense; configuration is almost always unique for each instance of the application, so it is the only file you do not want to copy. Dire things can happen when you do: Suppose you copy everything, forget to change database credentials, and accidentally wipe out the data in the instance you copied. It can happen; I have done it several times. :)

On point (2): As above, you should not be even able to browse to the configuration file, let alone execute it. Any error in the script or web server configuration could result in sensitive data exposed to the world.

On point (3): There is no value in encrypting server-side configuration files. In fact, this is a bad idea: it makes maintenance difficult (What was the database password again? Ah, I'll just look in the config file! Oh, bugger...), and it will severely impact performance. Suppose you make 1000 database connections per minute: That's 1000 times you need to decrypt the database password, every minute. For what gain? If someone does access the config file, you're screwed anyway; presumably they can also access your code, and then they can decrypt the password. If they can't access your code (but they can access your config file? Your security model is whacked!) they can probably still guess the encryption algorithm, and then decrypt it.

Thanks Pen, that made me rethink everything. Lucky I'm so busy with a work project I did not continue where I left of with DataShop (gonna be famous one day..watch it!)

Keeping in mind that I don't have experience for other kind of hosting than dedicated servers (my web development history are pretty short) I wanted to ask...

Say you store a file (xml) outside the web root, will your php code still be able to write to it?
I guess I can just check using my own server, but I am curious about those using shared hosting or whatever. Do you have access to a folder outside the document root?

I was figuring I should let the "user" be able to copy the configuration file to where every they want.
Hmm...how the app know where is the config file? I guess can store that in a php file in the web directory...no use for any bad guy to read it, as he wont be able to browse to the directory with the config file anyhow. Right?

Any web hosting worth its money will give you read/write access to a directory outside the document root. I would not go near a hosting company that doesn't. That said, there are many poorly operated, cheap hosting solutions which are insecure and not configured well; this means there are likely to be many users who do not have write access to the directory above the document root and cannot, can't afford to or don't want to move to another host.

It is your decision weather or not you want to cater for these users. Simple economics states that you should, while good practice states that you shouldn't :D I don't see a security issue with providing the users with a PHP file with some configuration variables which govern the configuration. But be very careful the variables you choose and ensure that you treat any data in the way you would treat data from a user who submitted a web form; i.e: validation, escaping, security.

One thing many applications do is to look for the config file in several predefined locations. You could look first one level above the index page and failing that somewhere within the web root.

If you are installed in a subdirectory it could be harder. You could even recurse up the directory tree until you find the file.

A bottom down approach might be better; it would prevent a compromised web application from placing a new configuration file.