PHP Security Tips
Search Google on the topic “php security”, you will come across a great article in Security Tips. We would like to share the valuable tips inspired from that article. This post discusses about the most common security vulnerabilities along with some standard best practices in php coding.
PHP is the most popular web programming languages in use today due in large part to the fact that it is a highly flexible syntax that can perform many functions while working flawlessly in conjunction with HTML. It is relatively easy to learn for beginners and is also powerful enough for advanced users. It works exceptionally well with open source tools, such as the Apache web server and MySQL database. In other words, its versatility is unsurpassed when compared to other scripting languages, making it the language of choice for many programmers.
There are various types of attacks that PHP is particularly vulnerable to. The two main types of attacks are human attacks and automated attacks, both of which can potentially devastate a website. The goal of PHP security is to minimize, and ultimately eliminate, the potential for both human and automated attacks by putting into place strategic lines of defense to eliminate access to your site by unverified users. The way you go about doing this is to target the most common types of PHP security breaches first, so that you can guard your website against malicious attacks. So what are the most common types of PHP security breaches?
Most Common PHP Security Vulnerabilities
1. Register_Globals
Register_Globals makes writing PHP applications simple and convenient for the developer, but it also poses a potential security risk. This setting is located in PHP’s configuration file, which is php.ini, and it can be either turned on or off. When turned on, it allows unverified users to inject variables into an application to gain administrative access to your website. Most, if not all, PHP security experts recommend turning register_globals off.
So instead of relying on register_globals, you should instead go through PHP Predefined Variables, such as $_REQUEST. To further tighten security, you should also specify by using: $_ENV, $_GET, $_POST, $_COOKIE, or $_SERVER instead of using the more general $_REQUEST.
2. Error Reporting
Error reporting is a great tool for diagnosing bugs. It allows you to fix bugs quicker and easier, but also poses a potential security threat. The problem occurs when the error is visible to others on-screen, because it reveals possible security holes in your source code that a hacker can easily take advantage of. If display_errors is not turned off, or has a value of “0?, the output will appear on the end user’s browser – Not good for security! If you want to set log_errors to on, then indicate the exact location of the log with error_log.
3. Cross-site Scripting (XSS)
Cross-site scripting, or XSS, is a way for hackers to gather your website’s user data by using malicious markup or JavaScript code to trick a user, or their browser, to follow a bad link or present their login details to a fake login screen, which, instead of logging them in, steals their personal information. The best way to defend against XSS is to disable JavaScript and images while surfing the web, but we all know that’s nearly impossible with so many websites using JavaScript’s rich application environment these days.
Useful for protecting against XSS is a useful PHP function called htmlentities(). This simple function works by converting all characters in html to their corresponding entities, such as “<” would convert to “<” (without the quotes).
4. Remote File Inclusion (RFI)
This type of attack is relatively unknown amongst developers, which makes it an especially damaging threat to PHP security. Remote file inclusion, or RFI, involves an attack from a remote location that exploits a vulnerable PHP application and injects malicious code for the purpose of spamming or even gaining access to the root folder of the server. An unverified user gaining access to any server can wreak major havoc on a website in many different ways, including abusing personal information stored in databases.
The best way to secure your site from RFI attacks is through php.ini directives – Specifically, the allow_url_fopen and the allow_url_include directives. The allow_url_fopen directive is set to on by default, and the allow_url_include is set to off. These two simple directives will adequately protect your site from RFI attacks.
Other PHP Security Tools
This useful tool reports security information in the PHP environment, and best of all, it offers suggestions for improving the errors. It is available for download under the “New BSD” license, and the PhpSecInfo project is always looking for more PHP developers to help improve this tool.
This is a tool used to scan PHP code for vulnerabilities, and it can be used to scan any directory. PHP Security Scanner features an useful UI for better visualization of potential problems, and it supports basic wild card search functionality for filtering directories or files that are to be searched.
– Spike PHP Security Audit Tool
The Spike PHP Security Audit Tool is an open source solution for doing static analysis of PHP code. It will search for security exploits, so you can correct them during the development process.
Here, we have given some basic coding standard for setting up database configuration. This is very simple one without implementation of any framework. We have given it to explain how can we convert a normal code to a standard code.
$mysql = mysql_connect(‘localhost’, ‘test’, ‘test’);
mysql_select_db(‘sample’) or die(“cannot select DB”);
Trying a DRY approach
$db_host = ‘localhost’;
$db_user = ‘test’;
$db_password = ‘test’;
$db_database = ‘bwired’;
$mysql = mysql_connect($db_host, $db_user, $db_password);
mysql_select_db($db_database);
As the values normally don’t change, we can use constants
define(‘DB_HOST’, ‘localhost’);
define(‘DB_USER’, ‘test’);
define(‘DB_PASSWORD’, ‘test’);
define(‘DB_DATABASE’, ‘sample’);
$mysql = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);
mysql_select_db(DB_DATABASE);
After years of changing the values every time, you upload something to the live server
define(‘LIVE_ENV’, true);
if(LIVE_ENV) {
define(‘DB_HOST’, ‘localhost’);
define(‘DB_USER’, ‘test’);
define(‘DB_PASSWORD’, ‘test’);
define(‘DB_DATABASE’, ‘bwired’);
} else {
define(‘DB_HOST’, ‘testserver.com’);
define(‘DB_USER’, ‘testuser’);
define(‘DB_PASSWORD’, ‘test’);
define(‘DB_DATABASE’, ‘sample’);
}
$mysql = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);
mysql_select_db(DB_DATABASE);
Even better would be this
if ($_SERVER[“HTTP_HOST”] == ‘www.domain.com’) // remote live environment
{ … }
else // localhost test environment
{ … }
PHP5 procedural approach using the new mysql extension
$link = mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD, DB_DATABASE);
if (!$link) {
printf(“Connect failed: %sn”, mysqli_connect_error());
exit();
}
printf(“Host information: %sn”, mysqli_get_host_info($link));
mysqli_close($link);
