Merge pull request #130 from enygma/security-update1

adding sections for config files, register_globals and error_reporting

_posts/07-05-01-Configuration-Files.md

@@ -0,0 +1,15 @@
+---
+isChild: true
+---
+
+## Configuration Files
+
+When creating configuration files for your applications, best practices recommend that one of the following methods 
+be followed:
+
+- It is recommended that you store your configuration information where it cannot be accessed directly and pulled in 
+via the file system.
+- If you must store your configuration files in the document root, name the files with a `.php` extension. This 
+ensures that, even if the script is accessed directly, it will not be outputed as plain text.
+- Information in configuration files should be protected accordingly, either through encryption or group/user file 
+system permissions

_posts/07-06-01-Register-Globals.md

@@ -0,0 +1,18 @@
+---
+isChild: true
+---
+
+## Register Globals
+
+<strong>NOTE:</strong> As of the introduction of PHP 5.4, the `register_globals` setting has been removed and can no 
+longer be used.
+
+When enabled, the `register_globals` configuration setting that makes several types of variables (including ones from 
+`$_POST`, `$_GET` and `$_REQUEST`) globals, available in the global scope of your application. This can easily lead to 
+security issues as your application cannot effectively tell where the data is coming from.
+
+If you are using a version of PHP that's prior to 4.2.0, please be aware that you may still be at risk of this setting 
+causing problems. As of PHP 4.2.0, the `register_globals` setting has been defaulted to "off". To ensure the security 
+of your application, ensure that this setting is <strong>always</strong> set to "off" if available.
+
+* [Register_globals in the PHP manual](http://www.php.net/manual/en/security.globals.php)

_posts/07-07-01-Error-Reporting.md

@@ -0,0 +1,33 @@
+---
+isChild: true
+---
+
+## Error Reporting
+
+Error logging can be useful in finding the problem spots in your application, but it can also expose infromation about 
+the structure of your application to the outside world. To effectively protect your application from issues that could 
+be caused by the output of these messages, you need to configure your server differently in development versus 
+production (live).
+
+### Development
+
+To show errors in your <strong>development</strong> environment, configure the following settings in your `php.ini`:
+
+- display_errors: On
+- error_reporting: E_ALL
+- log_errors: On
+
+### Production
+
+To hide the errors on your <strong>production</strong> environment, configure your `php.ini` as:
+
+- display_errors: Off
+- error_reporting: E_ALL
+- log_errors: On
+
+With these settings in production, errors will still be logged to the error logs for the web server, but will not be 
+shown to the user. For more information on these settings, see the PHP manual:
+
+* [Error_reporting](http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting)
+* [Display_errors](http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors)
+* [Log_errors](http://www.php.net/manual/en/errorfunc.configuration.php#ini.log-errors)