Top 10 PHP Security Vulnerabilities

Share this article

Security is not a list of things you do. Security is a way of thinking, a way of looking at things, a way of dealing with the world that says “I don’t know how they’ll do it, but I know they’re going to try to screw me” and then, rather than dissolving into an existential funk, being proactive to prevent the problem. But, you can’t buck statistics. Nobody is going to read an article entitled “Coding for Security.” Everyone wants an article with a number in it: “The 8 Most Common PHP Security Attacks and How to Avoid Them”, “23 Things Not to Say to a Super Model”, and “15 Reasons to Avoid Radiation Poisoning.” So, here goes, the “Top 10 PHP Security Vulnerabilities.”

SQL Injection

Number one on the hit list is the SQL injection attack. In this case, someone enters an SQL fragment (the classic example is a drop database statement, although there are many possibilities that don’t include deletions which could be just as destructive) as a value in your URL or web form. Never mind now how he knows what your table names are; that’s another problem entirely. You are dealing with an insidious and resourceful foe. So, what can you do to avoid this? First and foremost you need to be suspicious of any input you accept from a user. Believe everyone is nice? Just look at your spouse’s family… they’re weird and freaky, some dangerously so. The way to prevent this sort of thing is to use PDO Prepared Statements. I don’t want to go through a full discussion of PDO now. Suffice to say prepared statements separate the data from the instructions. In doing so, it prevents data from being treated as anything other than data. For more info, you might want to check out the article Migrate from the MySQL Extension to PDO by Timothy Boronczyk.

XSS (Cross Site Scripting)

Curse the black hearts who thrive on this type of deception. Parents, talk to you children today lest they become evil XSS’ers! The essence of any XSS attack is the injection of code (usually JavaScript code but it can be any client-side code) into the output of your PHP script. This attack is possible when you display input that was sent to you, such as you would do with a forum posting for example. The attacker may post JavaScript code in his message that does unspeakable things to your site. Please don’t make me go into detail; my heart weeps at what these brigands are capable of. For more information and how to protect yourself, I suggest reading these fine articles on PHPMaster:

Source Code Revelation

This one has to do with people being able to see the names and content of files they shouldn’t in the event of a breakdown in Apache’s configuration. Yeah, I dig it, this is unlikely to happen, but it could and it’s fairly easy to protect yourselves, so why not? We all know that PHP is server side – you can’t just do a view source to see a script’s code. But if something happens to Apache and all of a sudden your scripts are served as plain text, people see source code they were never meant to see. Some of that code might list accessible configuration files or have sensitive information like database credentials. The solution centers around how you set up the directory structure for your application. That is, it isn’t so much a problem that bad people can see some code, it’s what code they can see if sensitive files are kept in a public directory. Keep important files out of the publicly-accessible directory to avoid the consequences of this blunder. For more information on this, including a sample of what your directory structure might look like, see point 5 in this article. For additional discussion on this topic, see this forum discussion.

Remote File Inclusion

Hang on while I try to explain this: remote file inclusion is when remote files get included in your application. Pretty deep, eh? But why is this a problem? Because the remote file is untrusted. It could have been maliciously modified to contain code you don’t want running in your application. Suppose you have a situation where your site at www.myplace.com includes the library www.goodpeople.com/script.php. One night, www.goodpeople.com is compromised and the contents of the file is replaced with evil code that will trash your application. Then someone visits your site, you pull in the updated code, and Bam! So how do you stop it? Fortunately, fixing this is relatively simple. All you have to do is go to your php.ini
and check the settings on these flags.
  • allow_url_fopen – indicates whether external files can be included. The default is to set this to ‘on’ but you want to turn this off.
  • allow_url_include – indicates whether the include(), require(), include_once(), and require_once() functions can reference remote files. The default sets this off, and setting allow_url_fopen off forces this off too.

Session Hijacking

Session hijacking is when a ne’er-do-well steals and use someone else’s session ID, which is something like a key to a safe deposit box. When a session is set up between a client and a web server, PHP will store the session ID in a cookie on the client side probably called PHPSESSID. Sending the ID with the page request gives you access to the session info persisted on the server (which populates the super global $_SESSION array). If someone steals a session key, is that bad? And the answer is: if you aren’t doing anything important in that session then the answer is no. But if you are using that session to authenticate a user, then it would allow some vile person to sign on and get into things. This is particularly bad if the user is important and has a lot of authority. So how do people steal these session IDs and what can decent, God-fearing folk like us do about it? Session IDs are commonly stolen via a XSS attack, so preventing those is a good thing that yields double benefits. It’s also important to change the session ID as often as is practical. This reduces your theft window. From within PHP you can run the session_regenerate_id() function to change the session ID and notify the client. For those using PHP5.2 and above (you are, aren’t you?), there is a php.ini setting that will prevent JavaScript from being given access to the session id (session.cookie.httponly). Or, you can use the function session_set_cookie_parms(). Session IDs can also be vulnerable server-side if you’re using shared hosting services which store session information in globally accessible directories, like /tmp. You can block the problem simply by storing your session ID in a spot that only your scripts can access, either on disk or in a database.

Cross Site Request Forgery

Cross Site Request Forgery (CSRF), also known as the Brett Maverick, or Shawn Spencer, Gambit, involves tricking a rather unwitting user into issuing a request that is, shall we say, not in his best interest. But rather than me going on and on about CSRF attacks, refer to an outstanding example of just what kind of content we have here on PHPMaster: Preventing Cross-Site Request Forgeries by Martin Psinas.

Directory Traversal

This attack, like so many of the others, looks for for a site where the security is not all that it should be, and when if finds one, it causes files to be accessed that the owner did not plan to make publicly accessible. It’s also known as the ../ (dot, dot, slash) attack, the climbing attack, and the backtracking attack. There are a few ways to protect against this attack. The first is to wish really, really hard that it won’t happen to you. Sometimes wishing on fairies and unicorns will help. Sometimes it doesn’t. The second is to define what pages can be returned for a given request using whitelisting. Another option is to convert file paths to absolute paths and make sure they’re referencing files in allowed directories.

Summary

Those are the top 10 issues that, if you aren’t careful to avoid, can allow your PHP application to be breached. Yep, 10. Count them… 1, 2, 3… What? You only counted 8? Okay, maybe 7. Well then that shows you just how easily you can be fooled, and I’m not even one of the bad guys! Image via Fotolia

Frequently Asked Questions (FAQs) on PHP Security Vulnerabilities

What are the most common PHP security vulnerabilities?

The most common PHP security vulnerabilities include SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), File Inclusion Vulnerability, and PHP Object Injection. These vulnerabilities can lead to unauthorized access, data theft, and even server takeover if not properly addressed. It’s crucial for developers to understand these vulnerabilities and implement appropriate security measures to protect their PHP applications.

How can I prevent SQL Injection in PHP?

SQL Injection can be prevented by using prepared statements or parameterized queries. These methods ensure that user input is always treated as literal data, not part of the SQL command. This effectively eliminates the risk of SQL Injection. Additionally, always validate and sanitize user input to ensure it does not contain malicious code.

What is Cross-Site Scripting (XSS) and how can it be prevented?

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. This can lead to session hijacking, identity theft, and other serious issues. To prevent XSS, always encode user input and never insert untrusted data into your HTML output.

How can I protect my PHP application against Cross-Site Request Forgery (CSRF)?

CSRF attacks can be prevented by using anti-CSRF tokens. These are unique, random values associated with a user’s session. They are included in every state-changing request (like a form submission) and checked by the server. If the token is missing or incorrect, the request is rejected.

What is File Inclusion Vulnerability and how can it be mitigated?

File Inclusion Vulnerability occurs when an application uses user input to construct a file path for operations. An attacker can manipulate the input to include files from remote servers, leading to code execution, data leakage, or denial of service. To mitigate this vulnerability, avoid using user input in file paths, or validate and sanitize the input thoroughly.

What is PHP Object Injection and how can it be prevented?

PHP Object Injection is a vulnerability that occurs when user input is used to instantiate a class. An attacker can manipulate the input to create an instance of any class and execute its methods. To prevent this, never unserialize data from untrusted sources.

How can I secure my PHP sessions?

PHP sessions can be secured by using secure cookies, regenerating session IDs after login, and implementing session timeout. Additionally, store session data on the server side and only use the session ID to reference it.

What are some best practices for PHP security?

Some best practices for PHP security include keeping your PHP version up-to-date, using secure configuration settings, validating and sanitizing user input, using secure password hashing algorithms, and implementing proper error handling.

How can I detect PHP vulnerabilities in my application?

PHP vulnerabilities can be detected through code reviews, penetration testing, and using automated security tools. Regularly auditing your application for security vulnerabilities is a crucial part of maintaining a secure PHP application.

What resources are available for learning more about PHP security?

There are many resources available for learning about PHP security, including the PHP manual, online tutorials, security blogs, and forums. Additionally, organizations like OWASP provide comprehensive guides on web application security.

David ShireyDavid Shirey
View Author

Dave Shirey is owner of Shirey Consulting Services which provides business and technical project management, EDI set up and support, and various technical services for the mainframe, midrange, and desktop worlds. In addition to PHP Master, he also writes frequently for MC Press and Pro Developer (formerly System iNews). In his free time, he tends to worry vaguely about the future and wonder obsessively how different his life might have been if he had just finished working on that first novel when he got out of college.

Intermediate
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week