Introduction to PHP Security @DevOpsSummit [#DevOps]

Introduction to PHP Security – Part 1

By Omad Habib

It is a question that has daunted software engineers for decades: how secure is my software application? Modern web application development has evolved to a point where one can build and launch an entire product or company revolved around a full-fledged software-as-a-service. The only interface to your product is the UI provided via a browser, mobile application, or the data exposed by your web service API. Unfortunately, as these modern software media continue to evolve into more sophisticated platforms, so do the areas in which your product and your data become exposed to potential security risks, criminal intrusions, and data theft.

We’ll explore in this blog frequent channels of attacking and exploiting a PHP application. This blog is by no means an official guide to the security of your application, and you should always consult with your team of security experts on the best practice for your application environment.

Common Attacks

For starters, we’ll cover some of the most common attacks that you should be aware of. Almost all modern frameworks, libraries, and extensions have built-in mechanisms to patch these popular methods of attacks, but we’ll cover them nonetheless. These attacks are extremely simple to do and very easy to thwart, but they are very damaging if left exposed to the public.

Cross-Site Scripting (XSS)

All the data that you present to your users are not entirely hosted by you, contrary to popular belief. Modern web applications are extremely dynamic and pull data from various sources. In some instances, your site could provide the ability for a user to leave comments via a form. From inside that form, a hacker could paste a <script> tag pointing to a malicious script on another remote server.

This comment is then saved in the database, retrieved again for another user, and displayed in that user’s web browser. Because the attack is HTML, the hack does not display when rendered in the browser. However, if you use the view-source command on the page, you’ll easily see the embedded Javascript that was inserted and executed in your browser and every browser of the users of the site. Potentially, millions of your customers could be compromised by running unknown Javascript that is served by your application but points to another remote file controlled by hackers!

Further, the hacker can place more than just a <script> tag. XSS involves <iframe>, <body>, and even <img> exploits. How do you avoid this? You sanitize all the data that you receive from users!

Common sanitation techniques include strip_tags(), htmlspecialchars(), and other data filtering techniques.

SQL Injection

This exploit is creative and, frankly, deadly to your database. Imagine, for instance, that you are passing information from one page to another via hidden fields in a form.

In this case, you are accessing $_POST[‘user’], and the value is 23 and $_POST[‘password’]. Then, you move on to the database to perform a SELECT from your user table where user = 23. This particular attack overrides the SQL and inserts an additional statement so that your query returns true. For example, where you normally perform this:

SELECT user_id FROM user WHERE user_id = ‘23′ and password = ‘bla’

this hacker could override that by making you execute this:

SELECT user_id FROM user WHERE user_id = ‘23′ and password = ‘bla’ OR ‘true’ = ‘true’

The query above can run successfully and return true, even though the password is incorrect, causing your hacker to gain access by only knowing the user_id and not knowing the password at all!

To learn how to avoid database hacks, you can scroll down to the Database section (below).

Security Best Practice

OK, we’ve covered a couple of the most common attacks look like. Let’s dive into software development best practices and how they can help protect you from being vulnerable to attacks.

Security is a moving target. There is no perfect method of protecting yourself from the infinite exploits that could potentially exist. What does one do in this case in order to avoid being compromised? There are some basic best practices that should be implemented in your PHP environment.

Keep your PHP Upgraded

Always keep your PHP version up-to-date. I cannot stress this enough. You would probably be shocked at the amount of PHP users today who are running vulnerable versions of PHP, going as far back as PHP 4! Even within the PHP 5 series, always keep up-to-date with the latest version, and keep in mind that the PHP group does drop support and will end-of-life a version, regardless of who is running it. This means your PHP version could be outdated and vulnerable.

Keep SSL on at all times

There used to be a time when SSL was only used for when dealing with financial or health records. In other words, SSL was used when federal regulatory bodies required it. However, best practice is beginning to dictate that SSL always be turned on at all times throughout the lifetime of a customer session. The threat to security has unfortunately become so prevalent that even the most basic of requests can come under threat. For this reason and others, turning on SSL at all times has become a common practice in most web applications.

Validate everything that you collect and that is sent to you

All information that is passed to your application is suspect. There is no exception to this rule. Even if you receive this information from a third-party web service API, there is no guarantee that their data is not contaminated. You cannot vouch for the security of another company, so it is probably best to practice good data validation against information received from the outside world.

This information can be in the form of input from your users, partner access to your web service API, or perhaps even local files you are opening with PHP to parse through. Before any data is processed, saved to a database, or returned to your customers, you should always run the data through basic sanity checks.

Also, keep in mind that the session data that you set can be jeopardized. For example, when you set a cookie value on the client side, that value can be manipulated; so, the next time you access it, you should validate that data. You probably shouldn’t see sensitive information in your cookies, but just in case, verify the data, too.

Take a look at the filter_var() and filer_input() functions and see how you can fit it into your sanitation workflow. Configure your php.ini for optimal security. Your php.ini file may contain serious security flaws if you do not configure your environment correctly. I wrote another blog piece on this topic that you can read. In that blog post, I have a section that covers a basic introduction to security, but also covers other basic declaratives that you should be aware of.

Follow proper Error Reporting practices

The general rule when it comes to error reporting is: report everything in development, display nothing in production.

This means that, while you are in development mode, you want to be aware of all potential issues with your PHP application – including Notices, Warnings, and, of course, Errors. However, in production, you never want error information to be displayed to your visitors. Not only will you avoid upsetting your customers, but you’ll also avoid displaying secure information that could be used against you if it fell into the wrong hands.

Configuration Files – Keep them safe and hidden

All modern frameworks and web applications require configuration files. These are the files that contain access information, connection info, passwords, database connectivity, and environment-specific variables. Obviously, this file is extremely sensitive and should never be compromised. You do not want these files in your public web directories. Configuration files should always be at least one directory above your public web folders and accessed from within the application itself by a front controller or the framework.

Front Controller Method – Keep PHP files private

This approach is possible with almost all modern PHP frameworks. The only file that should be exposed in your public web root folder is your front controller or index.php. Your front controller then instantiates your framework object, dispatches all requests to the internal router, and includes the necessary framework files by going one level down. This way, you never have any of your application files exposed to the Internet and only have a single point of entry that you can lock down to make more secure.

Database Abstraction Libraries are your friend

If you are using a framework, you are probably using a database abstraction layer. Alternatively, at the least, you could be using MySQLi or PDO. Regardless of what method you use to interface with your database backend, all data should be sanitized before being inserted into your database. Specifically, by using prepared statements, you ensure that your database libraries perform all the tedious work of extracting and removing potentially malicious data hidden inside your inputs. Remove unnecessary PHP extensions. You do not want to have more extensions than you need. Perform a quick phpinfo() on your PHP runtime to find out how many extensions you have loaded and remove all the extensions that you do not need. By including extensions that you do not need, you are introducing potential performance overhead and security risks. The more variables you can remove from the equation, the less you have to worry about. It is just good practice, in general, not to load more extensions than necessary.


This list barely scratches the surface in regards to PHP security. There are more advanced topics, including proper password hashing and encryption techniques, proper session and cookie management, file and permissions techniques, web server and firewall configurations, and more. I hope this post, at least, provides a basic introduction to PHP security topics as a starting point in securing your application and your customer data.


Interested in gaining end-to-end visibility of your PHP application? Check out a FREE trial today!

The post Introduction to PHP Security – Part 1 appeared first on Application Performance Monitoring Blog | AppDynamics.

© 2008 SYS-CON Media