PHP Most Potentially Dangerous Feature, Secure It Today PHP Secrets
PHP Most Potentially Dangerous Feature, Secure It Today PHP Secrets
1. Register Globals
When this directive is On, PHP will inject extra variables in the script such as HTML request variables, etc. PHP could inject these sort of variables in a script. The problem with this approach is that a developer cannot rely anything outside of his script and by injecting these variables an outside attacker could overwrite already defined variables or create potentially dangerous ones.
Suggestion: Always Set register_globals directive to Off
2. Error Reporting
Enabling errors display is essential. You cannot fix the committed errors if you can’t see them, but once the website is in production, the errors display should be disabled, because PHP errors provides detailed information to the outside attacker.
A good approach is to enable error display in development environment:
error_reporting(E_ALL);
ini_set(‘display_errors’,’On’);
And once in production environment disable error display, but enable error logging to a file:
error_reporting(E_ALL);
ini_set(‘display_errors’,’Off’);
ini_set(‘log_errors’, ‘On’);
ini_set(‘error_log’, ‘/path/to/error/log’);
Alternatively you can use error_reporting(E_ALL | E_STRICT), this is the highest setting, offering suggestion for forward compatibility too.
Suggestion: Disable error display in production environment
3. Cross-Site Scripting (XSS)
Cross-site scripting vulnerability is the most common form of attack on websites. The mistake made by developers is not filtering input data from web forms and not escaping the output.
For example we have the following comment form:
<form action=“process.php” method=“post” accept-charset=“utf-8” enctype=“multipart/form-data” name=“frmComment”>
<textarea name=“txtMessage” id=“txtMessage”></textarea>
<input type=“submit” name=“submit” value=“Send” id=“submit” />
</form>
The application displays the following data like:
echo $_POST[‘txtMessage’];
The vulnerability is that the application doesn’t filter the input and escape the output. Let’s say someone writes the following javascript in the comment textarea:
alert (‘hacked’);
If an application doesn’t escape this output on every page request a Javascript alert box will pop up. The best a developer can do is to filter out any HTML tags from the data with:
$clean_message = strip_tags($_POST[‘txtComment’]);
And escape it when outputting the date with htmlentities:
htmlentities($clean_message, ENT_QUOTES, ‘UTF-8’);
A better solution is to use HTML Purifier to filter out any unwanted malicious input and to test your web forms that it’s XSS proof use the XSS cheat sheet.
Suggestion: Filter your input and escape your output to avoid XSS attacks.
4. Exposing Sensitive Information
Store sensitive information in files such as database passwords and other credentials. If these files are not properly secured an attacker could see the contents of them, therefore hacking the applications database, etc.
The most common file extension for php include files is .inc. By using this extension and not properly creating parsing rules in Apache, a developer could create a major security hole in the web application.
In Apache configuration the default file type for unknown file extensions is text/plain. If the .inc file is not set to be parsed as a PHP file and it is in the document root then we can access this file and see the contents of it by visiting the corresponding URL.
The best solution to this problem is to store these files outside of your document root (e.g. /www, /public_html, etc.). A best practice is to place the most essential files in your document root.
If you don’t have access outside your document root then at least use the following 2 methods:
1. Use an extra .php extension on the end of your file. E.g. sensitive.inc.php
2. Secure the .inc file in a .htaccess file:
<Files ~ “\.inc$”>
Order allow,deny
Deny from all
Files>
Suggestion: Move all your sensitive information outside of your document root, if that’s not possible add an extra .php extension to your .inc files and/or secure them in a .htaccess file
Source :PHP Secrets
