5 PHP Security Issues and What You Can do About Them?

PHP has developed into the most popular programming language and is widely used for rapid development of dynamic websites. Since web servers are publically accessible, they present significant security vulnerabilities. Below mentioned pie-chart is created by Web Hacking Incident Database for 2013 (WHID), which clearly shows different attack methods by hijackers that are the most popular.

In this article I have described some of the most common areas of vulnerability found in PHP web applications as well as suggestions on how they can be managed and prevented. By showing you about implication of flaws, and how each particular flaw can be exploited, I hope that you will understand not just how to avoid these particular mistakes, but also why they result in security vulnerabilities.

SQL Injection

SQL injection is one of the most common types of hacking and it is specifically targeted at database-driven websites or web applications which link to and interact with databases. This attack is a type of code injection, where attackers exploit vulnerabilities in the site’s security measures to send special SQL queries to the database that can modify it and tables within it or in the worst case delete the whole database.

This attack occurs when the web-developers have failed to build in any checking or data validation functionality for the areas of the website where data from external sources can be inserted into the website. An attacker will add his own SQL statements in unprotected SQL queries that utilize data submitted by the user to look-up something in the database.

For example:

An unprotected statement would be:

$query = “SELECT * FROM users WHERE username = ‘niki’”;

An SQL injection query will result in the following attempt:

$query = “SELECT * FROM users WHERE username = ” or ’1=1'”;

The result returned here will be true, and thus the content of entire table users would be displayed.

[related_posts]

In this type of php security issue, attackers can gain access to all the information in the database including usernames, names, passwords and other sensitive information as well. Moreover, all the information in the databases can be altered or dropped which could obviously have terrible effects on the front end of website and the entire website can be defaced if attacker gains administrative privileges.

• For better prevention of this security issue, the data must be validated, verified and cleaned up before it can enter the application;
• All the sensitive information such as passwords should be encrypted using SHA1 or SHA;
• Technical information can sometimes contain technical details that might reveal security vulnerabilities to an attacker; therefore, it must be removed from error messages;
• An attacker specifically looks to error messages to get information such as database names, usernames and table name, hence, you should disable error messages or you can create your own custom error messages;
• You can limit the permissions granted on the database and fewer permissions results lower chances of attack;
• You may use stored procedures and previously defined cursors to abstract data access so that users do not directly access tables or views;
• You can prevent words such as ‘insert’, ‘update’, ‘drop’, and ‘union’ from being added to the database (these all being words which can alter tables and databases).

Remote File Inclusion and Remote Code Execution

This security breach allows a malicious or unknown party to run code on your web server or client side and it can lead to several further types of hacking. Remote file inclusion is caused by a site vulnerability which allows hackers to deploy a malicious file onto the web server. This can be caused by improper use of require() and include() functions when the register_globals directive, a setting which controls the availability of superglobal variables, is ON (allowing the user to initialize variables remotely). If this directive is ON, an uninitialized variable can be used to include malicious or unwanted files from remote locations, and if the allow_url_fopen is enabled in php.ini, then remote files can be uploaded to the site’s server via FTP or HTTP from a remote location.

Remote file inclusions lead to remote code execution on the server, data theft, and code execution on the client-side that lead to problems such as cross site scripting and denial of service (DoS). The remote code execution on the server side means that if the file that the hacker has included is a shell (a file which can affect the operating system), then the hacker can run system-level code on the server and use this to alter or retrieve data on that web server or hack the end-user’s terminal. Client side remote code execution leads to cross site scripting. Denial of Service (DoS) prevents the user of a website from being able to access that website by preventing the servers from serving web pages, or it can overload the server with requests that results slow-down, making the website inaccessible.

• You should make OFF The register_globals directive, in later versions of PHP, it is OFF by default, but one should always check that. If the directive has to be set to ON for some reason, all variables must be properly initialized.
• There are other PHP directives can be used to prevent this security breach, which include:

• allow_url_fopen (set to on by default) that controls whether remote files should be includable and should be turned to OFF
• allow_url_include (set to off by default) that controls whether include_once(), include(), require() and require_once() commands are able to include remote files into the code
• Enabling safe_mode which forces PHP to test of user ID permissions before opening any file

Cross Site Scripting (XSS)

Cross Site Scripting is probably the most common form of hacking and in this type; hackers use a legitimate site’s vulnerability to force that site to do certain things. In this attack, the hacker infects a web page with his malicious client-side script and when a user visits this page the script is downloaded to his browser and executed. The pattern of XSS attack is depicted in the diagram below:

Once injected, the malicious code is stored in the site’s database and when it is displayed to the visitor, the resulting page can be distorted and code can also be run which steals cookies, or sends important information such as session ID to a malicious third-party website. If JavaScript is injected into the HTML source, then it can also be used for things such as redirecting users to a spam website or in a more sophisticated attack like keylogging (sending the user’s keystrokes to an external database).

XSS is also used for user-account hacking and stealing the confidential information of users. A method used in conjunction with XSS is known as Cross-Site Request forgery. This is where, malicious code tricks the users’ browser to send requests under the guise of legitimate user, so for example, it can use a users’ online email account to send out emails automatically.

• The best way to prevent XSS is to use escape functions, specifically to escape characters that comprise HTML and JavaScript syntax like ‘>’ and ‘<’ or to convert these into HTML entities, (so < would become < for example);
• In forum websites, where users want to post HTML like links, an alternative syntax like bbcodes (which is very common on forums) can be used in order to overcome the escaping of HTML characters;
• The htmlspecialchars () function indentifies any output you do not want to be HTML output and converts it into plain HTML entities, for example: ‘&’ becomes ‘&’ and ‘”‘ (double quote) becomes ‘"’;
• You should rigorously test the website before launching it.

Session and Cookie Hacking

The session and cookie hacking can’t breach the database or the web application itself, but it can compromise user accounts. A session is an entity triggered when users initiate contact with a web server and consists of a period of interaction between users and web application which may be authenticated using security measures like a username and password. During this session, the web application stores a cookie or file on the users’ browser which will contain information about the session like the users’ preferences, authentication data, unique codes or shopping cart information.

When user logs into website, a session ID is created, and a session hacker tries to obtain the legitimate user’s session ID and use the information for unfair means. When the hacker tries to reuse a session ID, it is known as session fixation, and it can allow hackers to login as an authentic user and cause alter or damage the user’s account, which is particularly dangerous when the user is an administrator or someone whose account contains important or sensitive data.

• In order to prevent hackers from setting session ID’s prior to login, ID’s should be changed often, therefore, the session_regenerate_id() function should be used every time the user logs in, assigning them a fresh ID;
• The risk of this hacking can be mitigated by revalidating a user who is about to perform important or sensitive tasks like resetting their password (i.e. by making them re-enter their old password);
• If user’s password is to be stored in a session variable, it must be encrypted (using the sha1() function)
• If your web application is handling sensitive information like debit and credit card numbers, then using an SSL or any other secured connection can also prevent session and cookie hacking

Directory Traversal (aka path traversal)

Directory traversal is a method of exploiting web applications by accessing files beyond the document root directory that allows attackers to view restricted files and interact with the web server by executing commands. This attack occurs through a browser and is accomplished by the hacker entering a URL into the address bar which takes him out of the root directory and into the main server directories; this generally takes some guesswork on the part of the hacker, but can actually be done quite easily. The attack can also be done through input portals on the front end of the web application.

Once inside the server’s system folders and files, the attacker has access to all sorts of information and sensitive data including application source code and critical system files. The hacker may even delete or add files and play havoc with the server’s setup.

• You should validate and sanitize all user input correctly by removing all suspect data and filtering out meta-characters;
• Another precaution from this hacking is to never store sensitive configuration files inside the web root;
• If a suspect request to a file is made, the full file-path should be built up and all the characters in the path should be normalized (e.g. change %20 to spaces);
• Careful programming on the web-server is important and you should make use of security software, patches and vulnerability scanners.

* * *

Security is a process, not a product, and adopting a well research approach to security will allow you to produce tighter, more robust code. In this article, I have mentioned the top five PHP issues that, if you aren’t careful to avoid; can allow your well-developed PHP application to be breached. I also recommend you to hire experienced PHP developers, who can perform this task for you with great accuracy and promptness. Still have doubts and need more information? Just click here to get some.