6 Major PHP Security Vulnerabilities And How To Fix Them

Introduction

According to Kinsta, 79.2% of all websites rely on PHP to some degree. Although PHP is one of the oldest web development programming languages, it’s still very popular and widely in use. Like in other languages or frameworks, PHP is also vulnerable to attacks. With the wide use of PHP, the impact of exploiting PHP security vulnerabilities is too high and you can’t take it for a pinch of salt. 

To help you with this, we’ll be talking about 6 major PHP security vulnerabilities and how to fix them. 

6 Major PHP Security Vulnerabilities And How To Fix Them

1. Secrets

Web applications deal with a lot of sensitive information such as passwords, SSH keys, API keys, etc. If they fell in the wrong hands, the consequences can be catastrophic. Therefore, it’s important to handle sensitive information securely. One of the most simple ways attackers find secrets is when it’s hardcoded in the code. Along with this, secrets in transit can also be accessed by intercepting the traffic. 

How To Handle Secrets

Do not hardcode secrets: One should never hardcode secrets in code. They should fetch it from a secure location and channel whenever there is a need to use secrets. 

Use Encryption: Using encryption prevents an attacker from accessing sensitive data in its original form because the data is encoded. Therefore, even if an attacker got hold of it, it’ll be difficult to decode it without the correct passphrases or keys.

Use password managers: Most password managers use strong security measures to secure passwords. And they also keep updating their security to keep up with the latest attack techniques. 

2. Vulnerable Libraries

According to the listing on php-download, there are over 20,000 libraries for PHP. It’s not always wise to reinvent the wheel so developers use several libraries in their application. But if these libraries are vulnerable, it opens the application to vulnerabilities. 

How To Reduce Risks From Vulnerable Libraries

Remove unused libraries: Why keep something in the code that is not in use? Several times developers might have imported a library and just left it there when they switch to using a library that’s more suitable. Remove any unused libraries. 

Implement patch management: For libraries that can not be removed, have a patch management process to check for recent patches available and apply them. 

3. SQL Injections

SQL is one of the most used databases in the world. According to a survey conducted by Stack Overflow, SQL databases have come up as one of the most popular databases and as per enlyft’s data, over 200,000 companies use Microsoft SQL. As PHP applications commonly use SQL databases on the back end, they become susceptible to SQL injections. 

SQL injection is a type of code injection vulnerability where an attacker sends malicious inputs to the application to perform malicious SQL queries. Let’s look at a simple example of a login bypass using SQL injection. Consider an application that takes the username and password from the input fields and tries to authenticate the user using the following SQL statement:

SELECT * FROM users WHERE username=$user AND password=$password;

Here, the $user and $password are replaced by the username and password input from the user. 

In a legitimate login scenario, a user would enter their username and password and if the SQL query returned a result it would indicate that there is a user with the entered username and password in the database and the system would authenticate the user. 

SELECT * FROM users WHERE username=’bob’ AND password=’alice’;

Now let’s see what happens if a malicious input was given as the username with some random password. Let’s consider that the username is “bob’ OR 1=1–” and the password is “randompass”. The SQL query would be:

SELECT * FROM users WHERE username=’bob’ OR 1=1–’ AND password=alice;

In this case, the AND boolean logic is changed to an OR. And because 1 is always equal to 1, this statement will be true and the query will return a result and authenticate the user. This is one type of SQL injection. 

You can find more information on SQL Injections here.

There are different types of SQL injections:

1. Blind SQL Injection: In this type of injection, the query does not display data or errors. The response of the query indicates whether the query executed successfully or not. Attackers keep on trying different queries based on the response to find the malicious query that performs the intended action. 
2. Blind Time-based SQL Injection: This is a version of the above type where attackers include sleep times in the query. The response time indicates whether the query was successful or not. 
3. Error-based SQL Injection: Attackers use the information from the errors displayed on the application when he/she injects malicious inputs. 
4. Union-based SQL Injection: Attackers craft the input such that it combines the results of two or more queries and displays the information along with the display of data from the legitimate query. 

How To Fix SQL Injection Vulnerability

The main reason for a SQL injection vulnerability in PHP applications is the use of unsafe data. Here are some ways to mitigate it:

• Sanitize user inputs: This removes the meaning of special characters and the system treats them as strings. As a result, the malicious input will lose its power and not execute as a SQL query. 
• Parameterize SQL queries: By parameterizing SQL queries, you are defining the SQL query and the parameters that come from the input. If an attacker inputs a malicious string, then the system will consider it as untrusted and doesn’t execute it as a SQL query. 
• Use PHP data objects (PDO): PHP data object is an extension that uses the object-oriented approach to interact with a database. By using PDO prepared statements, you leave placeholders in the SQL query for the inputs and bind the inputs to the query before executing the query. This helps the system differentiate between the predefined SQL query and user inputs.

4. Command Injection

Command injection is a vulnerability that allows attackers to run arbitrary shell commands on the system by crafting malicious inputs to the application. Command injections occur when the PHP application is calling the system’s shell. Let’s take an example where the PHP application is using the ping utility of the system. The application takes a hostname or an IP as input, uses functions such as exec(), passthru(), or system(), and passes the input to the system ping utility ,and displays the output.

$command = “ping “.$_GET[‘host’];

$output = exec($command);

If the input is a hostname or an IP like “www.example.com”, the command that is passed to the system would look something like this:

ping www.example.com

However, attackers can modify the input to execute more than just the ping command. For example, if the input is “www.example.com; whoami”, the command would be: 

ping www.example.com; whoami

First, the system will execute the ping command and then the whoami command revealing the current user of the system. Attackers can use more dangerous commands to delete files, download malware, and much more. 

How To Fix Command Injection Vulnerability

• Avoid using shell calls: Avoid using functions such as exec(), passthru(), and system(). Try to find an API or a library that would provide the same function as the system command. 
• Validate input: When passing input to the command, validate it to make sure it does not contain something unsafe. For example, if you’re passing an IP or hostname to the ping command, validate that the input is indeed an IP or a hostname. 

5. Cross-Site Scripting

Cross-site Scripting is a vulnerability that allows an attacker to execute arbitrary browser-side scripts by crafting malicious inputs. This is a vulnerability that impacts the end user of the application. When an application renders user input data on the browser side, if the input is not sanitized, attackers can inject scripts as input which would then execute when it is rendered on the browser. For example, let’s take a simple application that takes a user name as input and displays a greeting message. So if the input is “Tony”, the output is “Hello, Tony! Welcome to this application.” Going one level deeper, the URL with the input would be:

http://www.example.com/name.html?name=Tony

and the browser-side script would be:

<?php echo ‘Hello, ’. $_GET[“search”]. ‘! Welcome to this application.’; ?>

This code would resolve to:

<?php echo ‘Hello, ’.’Tony’. ‘! Welcome to this application.’; ?>

An attacker can craft a malicious input as follows:

<script type=’text/javascript’>alert(document.cookie);</script >

And when this is placed in the above PHP echo line, the browser would consider this as a script and execute it. On execution, you would see the cookie value in the alert box. Attackers can use cross-site scripting(XSS) to steal data, get unauthorized and even get complete control of the system. 

There are 3 major types of cross-site scripting:

1. Reflected XSS: The malicious script is only on the browser side and the attacker will have to send the payload to the victim. 
2. Stored XSS: The malicious script is stored in the database and the script executes when the victim accesses it from the database. 
3. DOM XSS: The malicious script is written to the DOM and the client reads from the DOM. 

How To Fix Cross-Site Scripting Vulnerability

• Sanitize user input: This cleans any potential dangerous parts in the input that would lead to an XSS attack. Sanitizing input takes out the special meaning and the application considers it just as data and not as a script. 
• Validate user input: This restricts what input the users can enter before processing it. As a result, the input of malicious script reduces. For example, validating an email before submission prevents attackers from entering XSS payloads in the email field. 
• Use HttpOnly flag: When you use an HttpOnly flag for a cookie, if the client-side script tries to read the cookie, the browser returns an empty string. This doesn’t exactly fix the cross-site scripting vulnerability but limits its impact. 
• Use Content Security Policy (CSP): CSPs restrict the resources that the webpage can load. Using this, you can restrict the malicious scripts from loading on the page and therefore, prevent cross-site scripting.

6. Insecure Deserialization

PHP uses serialization to convert an object into a byte stream and deserialization to convert the byte stream back to an object. Although this helps store or pass the values without losing their type and structure, it leaves room for insecure deserialization vulnerability. Let’s say there’s a PHP object as follows:

$user->name = “Tony”;

$user->isAdmin = false;

When serialized, this data would look as follows:

o:4:”user”:2:{s:4:”name”:s:4:”Tony”; s:7:”isAdmin”:b:0;}

Here, the isAdmin attribute indicates that Tony is not an admin. However, if an attacker could modify this value from false to true, and re-encode the object, then this is privilege escalation. The modified data would look as follows:

o:4:”user”:2:{s:4:”name”:s:4:”Tony”; s:7:”isAdmin”:b:1;}

Because the structure or the type has not changed, the system will be able to deserialize this. 

How To Fix Insecure Deserialization Vulnerability

• Include data integrity checks: Using data integrity checks such as checksum will help you identify if the data has been unexpectedly modified. If the data integrity is compromised, then you can restrict the use of that data. 
• Use custom serialization: Using custom serialization and deserialization structure and logic makes it difficult for attackers to modify the data into valid data. However, this practice does not prevent insecure deserialization altogether. 
• Avoid deserializing data from untrusted sources: The risk of insecure deserialization comes from untrusted sources so wherever possible, avoid deserializing data from untrusted sources. 
• Use deserialized data in low-privilege environments: By doing this, even if the data is modified to execute something critical or make critical changes, limited privileges will prevent the action. 

This brings us to the end of major PHP Security Vulnerabilities. 

Conclusion

PHP is one of the most commonly used languages for web application development. The wide use of PHP applications makes it a good target for cyber attackers. Therefore security should be a top priority while developing PHP applications. We went through the 6 major PHP security vulnerabilities commonly found in PHP applications and how to fix them. But don’t limit yourself to mitigating these vulnerabilities, this is just the beginning. 

Once you fix the high-priority vulnerabilities, you have to identify other vulnerabilities in the application and work on fixing them. If you’re looking to make finding and fixing PHP security vulnerabilities easy, check out GuardRails. GuardRails makes it easy to find, prioritize and fix PHP security vulnerabilities along with other languages, as early as they are created, saving everyone in the organization time and unnecessary stress. This improves the overall process of enhancing the security of your PHP applications and makes the lives of the developers and security teams easy. 

The post 6 Major PHP Security Vulnerabilities And How To Fix Them appeared first on GuardRails.

*** This is a Security Bloggers Network syndicated blog from GuardRails authored by Team GuardRails. Read the original post at: https://blog.guardrails.io/6-major-php-security-vulnerabilities-and-how-to-fix-them/