Protecting Your WordPress Code of Sql Injection Part 1

Introduction:

Some time ago I have dedicated to researching about security and vulnerabilities of WordPress plugins. And the result as we can see below is very satisfactory. I have posted and helped the community to stay a bit more secure.

• WpVull, site that lists vulnerabilities with a focus on WordPress.
• Exploit-db, Site listing 0days of all types.

Interesting of this research is not only the result, but the numerous curiosities of the code, how complicated security issues are resolved and how numerous solutions to the same problem exist. The result of these observations I intend to publish sequentially on my site.

The first is about the amount of techniques we can use to protect ourselves of a Sql Injection.

But what is a Sql Injection?

Sql Injection is a type of attack that sends SQL commands, through form fields (POST) or through URLs (GET). The success of the attack usually causes sensitive data to be extracted as a database containing access data such as login and password, but depending on the attack it may even drop the database.

Simple Example:

We received a query with login and password to access with data coming from the login form:

$username = $_POST['username'];
$password = $_POST['password'];

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

If we send the parameter as follows …

$username = 1' or '1' = '1
$password = 1' or '1' = '1

Result that this way the search will be positive and will have access to the system.

Example with WordPress Plugin.

A true example with WordPress Plugin taken from another post:

After an access to the administrative part with the dsubscribers plugin with the vulnerable version I will insert the following url:

 http://target/wp-admin/admin.php?page=dsubscribers&action=edit&dsubscribers=0 UNION SELECT 1,2,CONCAT(user_login,char(58),user_pass) FROM wp_users WHERE ID=1

The query with problem is:

$id = $_GET['dsubscribers'];
...
$wpdb->get_row("SELECT * FROM $table_name WHERE id=$id");

The result is:

• Observations
  • I will not talk which is the best solution.

-Scenario will be:

Most common, it will be installed a plugin that creates new tables and needs a select with parameter passing via GET to return specific information.

Tests :

I Example: ✅

Tipo : $wpdb->prepare.

Query:

$query=$wpdb->get_row( $wpdb->prepare("SELECT * FROM ".$wpdb->prefix."spidercatalog_product_categories WHERE id=%d",$_GET['id']) );

Reason: What saves the Sql Injection in this situation will be the $ wpdb->prepare method that serves justly to be able to handle and filter. Read More…

II Example: ✅

 

Tipo : Usando (int).

Query:

$pppm_phid = (int) $_POST['pppm_phrase_filter'];
$pppm_res = $wpdb->get_row( "SELECT `phrase`,`replace` FROM `".$wpdb->prefix."pppm_filter` WHERE `id` = $pppm_phid ", ARRAY_A );

Reason: What saves the Sql Injection in this situation is the validation of the integer in the query (int) in the first row when the expected value is an integer. This goes for PHP in general. Read More…

Observation: Others serve for something similar to this typification as:

• $pppm_phid = (integer) $_POST[‘pppm_phrase_filter’];
• $pppm_phid = intval($_POST[‘pppm_phrase_filter’]);
• $pppm_phid = (float)$_POST[‘pppm_phrase_filter’]);

 

Have more, wait …