DEV Community

Cover image for These 7 PHP mistakes leave your website open to the hackers
SmartScanner
SmartScanner

Posted on • Updated on • Originally published at thesmartscanner.com

These 7 PHP mistakes leave your website open to the hackers

Make these mistakes and hackers will attack your web application using Cross Site Scripting, SQL Injection, Path Traversal, and other attacks to take over your website.

Let's review common mistakes and their prevention methods.

1- Echo user input

Below code is enough to create a XSS vulnerability in your website.

echo '<p>' . $_GET['name'] . '</p>'; // vulnerable to XSS
Enter fullscreen mode Exit fullscreen mode

Never directly use user input for generating response contents. You have to use proper encoding on user input to escape any dangerous code. PHP has the build-in htmlentities() function to encode html special characters which you can use.

echo '<p>' . htmlentities($_GET['name']) . '</p>'; // safe code
Enter fullscreen mode Exit fullscreen mode

Sometimes user input is used indirectly for generating a page. For example, user input might be saved in a database before being used in the response.

2- Using user input in file paths

Generating and using file paths that contain user inputs is one of the most dangerous mistakes that can cause critical vulnerabilities like:

Below code is an example of a file inclusion vulnerability.

include $_GET['file']; // vulnerable to remote/local file inclusion
Enter fullscreen mode Exit fullscreen mode

To prevent file inclusion vulnerabilities:

  • Resolve all relative paths containing ./ and ../ to absolute paths and make sure the final file is in the directory where it should be.
  • Try to accept only whitelisted inputs whenever possible
  • Check for invalid characters in the filename like null byte, questions mark, semicolon, etc.
  • Do not include URLs starting with a scheme (http://, ftp://, etc.)

3- Concatenating SQL queries with user input

Creating SQL queries using user input allows users to manipulate the original SQL command and inject their arbitrary command. This is called SQL Injection. Hackers can exploit SQL Injection vulnerability to execute commands like drop on the database or execute system commands.

Example code:

<?php
$db = new SQLite3('products.db');
$id = $_GET['id'];
// below line is vulnerable to SQLI
$name = $db->querySingle("SELECT name from products where productId=$id");
// below line is not vulnerable
$name = $db->querySingle("SELECT name from products where productId='" .
SQLite3::escapeString($id) . "'");

echo $name ;
Enter fullscreen mode Exit fullscreen mode

It's always a good practice to use prepared statements for creating SQL queries to prevent SQL Injection. Another method to avoid SQLI is to escape special characters in the user input (like the above example).

4- Executing user input

Below commands in PHP allow execution of either PHP code or OS commands.

  • eval()
  • preg_replace()
  • system()
  • exec()
  • passthru()
  • shell_exec()

Passing user input as arguments to the above functions can cause command execution vulnerabilities where hackers can execute arbitrary commands on the server. Consider below code as an example:

$ip = $_GET['ip'];
echo exec("ping $ip");
Enter fullscreen mode Exit fullscreen mode

The above code is a ping service where users can ping any IP. If a user enters 1 & echo 123 as an IP address then the command echo gets executed on the server.

How to prevent command execution vulnerabilities:

  • Avoid using functions like eval(), system(), ...
  • Accept whitelisted inputs
  • Check inputs for special characters like &, semicolon,

The popen() function can also be used for command execution indirectly. So be careful when using it.

5- Redirecting to user input

Redirecting a user in PHP is common and easy. It can be done using below code.

header('Location: ' . $_GET['url']); // vulnerable code
Enter fullscreen mode Exit fullscreen mode

But this is vulnerable! It can be exploited to redirect the user to any other website.
To prevent open redirections, make sure the URL is not an off-site link before redirecting the user.

6- Displaying errors

PHP errors disclose information like path/files, database errors, OS type, and some other information. Displaying any kind of PHP errors on production helps hackers to break into your website easier.
But you still need to log and review PHP errors on the production server. So you should have errors reported but not shown to the user.

error_reporting(E_ALL); // enable reporting of errors

display_errors(true); // bad code for production, it displays all errors to the user
display_errors(false); // safe for production usage, no error is shown to user
Enter fullscreen mode Exit fullscreen mode

7- phpInfo()

The phpInfo() function displays a huge amount of information. PHP version number, active extensions, configurations, and system paths are a few examples of such information. This information can be used by hackers to learn about the server and craft their attacks to be more successful.
To avoid any information disclosure it's better to never use the phpInfo() function on production servers.

Conclusion

Dealing with user inputs in PHP applications can be tricky and prone to different vulnerabilities. XSS, SQL Injection, and local file inclusion are a few of explained vulnerabilities related to user inputs. Make sure you have strict checking for user inputs and avoid using risky functions like eval() and phpInfo() to have a more secure code.

NOTE: These are basic and most common issues you should be aware of. There are more complex security vulnerabilities like the ones @moay referenced in this article.

Top comments (6)

Collapse
 
therceman profile image
Anton

Thanks for the article!
preg_replace function injections is something new to me.
Tested it right now and it really works in PHP <= 5.6.29

Collapse
 
smartscanner profile image
SmartScanner

PHP is full of surprises!

Collapse
 
moay profile image
moay

Thanks for your article. I appreciate your effort, but I don't think this is a good list for anyone unexperienced to read. In contains basically just two very basic rules:

  • 1 to 5: DONT TRUST USER INPUT
  • 6 and 7: DISABLE DEBUGGING STUFF IN PRODUCTION

These very basic rules are quite important, but it's

  • not seven things
  • not covering a lot of important things junior devs should think of.

If you are looking for a better read on what to keep in mind, read this: how2lab.com/internet/security/php-...

Collapse
 
smartscanner profile image
SmartScanner • Edited

Thanks. You are right. But I wanted to simply explain the common issues. I updated the article with a note. Thanks again.

Collapse
 
leob profile image
leob

Good overview, OTOH who is still coding PHP without using a framework? Something like Laravel takes care of all of these.

Collapse
 
smartscanner profile image
SmartScanner

There are still some folks doing that 🤦‍♂️