How to Fix PHP Vulnerabilities (So Your Site Won’t Get Hacked)


As a programming language, PHP has many advantages but security has always been a major issue. Partially these security problems are inherent to the language itself because PHP was meant to be an easy and powerful programming language, while security came second. However, when you add bad coding and non-adherence to even the basic security rules, the situation gets out of control.

Fortunately, it is possible to fix PHP vulnerabilities and make PHP applications more secure. Some of the defenses are common for all programming languages, while others are found only in PHP. Here are some of the best defenses you have when you want to fix PHP vulnerabilities and make your site more secure.

Defend Your Code Against SQL Injections

SQL Injection is one of the most typical PHP vulnerabilities and many hackers take advantage of it. In order to prevent SQL injections, you need to always check input data and to escape characters (such as single quotes (‘) or double quotes (“)). If you do it, it won’t be possible to execute malicious SQL queries, which take control over your database or compromise the security of your site in other ways.

The two most common defenses against SQL injections are the use of the mysql_real_escape_string and PDO. The mysql_real_escape_string prepends special characters and as a result these special characters are not sent directly to the MySQL database. It is recommendable to use mysql_real_escape_string on all input variables, which are sent to the MySQL database.
PDO adds an abstraction layer to your code, thus making it more secure. PDO prepares a statement for execution and returns a statement object.

Don’t Leave Room for Cross-Site Scripting Vulnerabilities

Cross-Site Scripting (XSS) is also common in PHP. Again, the defense against XSS isn’t rocket science. If the users input HTML data is escaped properly, your code won’t be vulnerable against XSS. If you don’t do it, then a hacker can insert any HTML code (or even Javascript) he or she likes and modify your page, so that he or she can steal data from users.

The best defense against XSS is to use the htmlspecialchars() function. This function identifies any output you wouldn’t like to be considered as HTML output. While you can never be certain that XSS is impossible, the htmlspecialchars() function will make it harder for a hacker to succeed.

Watch out for File Inclusion Vulnerabilities

Of all PHP vulnerabilities, file inclusion attacks are the most severe. A file inclusion attack gives the hacker the opportunity to include a random file and to deploy it on your server. File inclusion attacks are possible when the register_globals directive is on, which means that unchecked input variables are allowed. The best defense against file inclusion vulnerabilities is to mind how you use PHP include() functions. If you are not sure you can use these functions properly, you’d better avoid any include statements – just use switch statements with hard coded strings and this will help to avoid file inclusion vulnerabilities.

Don’t Forget to Initialize Variables

If you program in many other languages, then you maybe don’t need to be told explicitly to initialize variables because you already have the habit of doing it. However, if you are mainly a PHP programmer, maybe you don’t always initialize variables because in PHP, unlike in many other programming languages, a variable can be used without being initialized first. From a security point of view, uninitialized variables are a huge risk and this is why you should never use them.

Don’t Leave the register_globals Directive ON

File inclusion attacks aren’t the only evil the register_globals directive brings to your code. The register_globals directive is very powerful but unfortunately its power is easily abused. In recent versions of PHP the directive register_globals is OFF by default and in PHP 6 it is altogether removed but if you are using earlier versions of PHP, take the time and check if it isn’t ON by accident.

Encryption Always Helps

No matter which programming language you use, encryption always helps. It doesn’t matter how secure your PHP code is when you send sensitive data unencrypted and anybody can read it. The safest form of encryption is end-to-end encryption but it takes a lot of resources and it might be hard to implement. This is why it is acceptable if you encrypt at least passwords, credit card numbers, and other similar data. Don’t leave sensitive data unencrypted because this is what hackers want most.

Test Your PHP Code with Tools

There are many PHP tools to test the security of your code with. Sure, you should do your best to write secure code, adhere to security practices, and carefully review your code for errors but an automated tool to check your code with is always useful. Some of the best tools to test PHP vulnerabilities with are PhpSecInfo, PHP Security Scanner, and Spike PHP Security Audit Tool. Run them on your code and see what they will find.

Further Reading

These steps are just the beginning to make your PHP code secure. You must always take at least these steps because if you don’t you leave the door wide open to hackers. On the other hand, even if you do everything we described here, you can never be sure that no vulnerabilities exist. There is much more to PHP security and if you want to expand your knowledge, read the PHP Security manual and this paper. Both of them will tell you more about how to fix PHP vulnerabilities and make your site secure.

This guest article was written by Christopher Shepard of Webhost Gear, a website that provides information about hosting and reviews of the most popular web hosting services, as well as technical and website maintenance tutorials.

This site is a digital habitat of Sameer Borate, a freelance web developer working in PHP, MySQL and WordPress. I also provide web scraping services, website design and development and integration of various Open Source API's. Contact me at metapix[at]gmail.com for any new project requirements and price quotes.

8 Responses

1

mike

May 25th, 2010 at 12:45 pm

Thank you for this nice article ! :)

2

Jim O'Halloran

May 26th, 2010 at 4:59 pm

I disagree with the characterization of these as “PHP vulnerabilities”. None of the above are vulnerabilities in PHP itself, they’re vulnerabilities in the code you write using PHP.

Secondly, if you’re dealing with credit card numbers, think very seriously about whether to store them at all. In most cases you can put up a form, collect the card number and pass it off to your payment gateway immediately without storing it. If they’re not stored permanently the chances of their being compromised are daramtically lower, Of course, you should NEVER accept a credit card umber over a http connection, always use SSL (https) with a certificate from a reputable supplier.

Finally, a minor correction. PDO stands for PHP Data Objects, not Portable Data Objects.

Jim.

3

Bruno Cassol

May 26th, 2010 at 6:40 pm

None of those are PHP’s fault. You can make the same mistakes with any programming language. Use a framework and it will enforce good practices.

Please stop blaming PHP for such things that are caused by poor programmers.

4

Irina

May 26th, 2010 at 11:42 pm

Great article! Thanks for the info!

5

Hisham Muteb

May 27th, 2010 at 2:35 am

yes it is not php fault
it is depend on the programmer and his code
and yes @Bruno Cassol I am agree with you
“You can make the same mistakes with any programming language”
at the end it is good article

6

internet

August 16th, 2010 at 8:39 pm

How can this be implemented in a forum site powered by SMF? I’ve seen some forum sites being hacked. The php codes are already included in the installation package? Do we have to modify the codes? Will it violate rights of software maker?

sameer

August 17th, 2010 at 12:20 am

Well this are guidelines, you have to implement it yourself. Most modern software take most of the precautions to prevent hackers from penetrating the sites. But there are other factors then the actual software, like security of the hosting provider. Even if SMF is secure, the server on which it is installed may not be. You can modify the code without violating any copyrights of the maker (I’m talking about SMF here, other software licenses maybe different.)

8

Art

August 15th, 2012 at 5:15 am

Why all the negativity over what was said about PHP’s weak security issues. This was a wonderfully written article that focused primarily on PHP and how to make our sites more secure. We all know how smart some of you are! It’s just degusting of how some feel that the only way they can show others how smart they are is by them running others into the ground.

Thank you for taking the time to write this article. When compared to many other articles on the subject of PHP security it is easy to understand and hits all the basics right on. –Good Job!

Your thoughts