For our thirteenth security review of a plugin based on the voting of our customers, we reviewed the plugin wpDataTables Lite.
If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.
The review was done on version Lite 1.2.2 of wpDataTables Lite. We checked for the following issues:
- Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
- Deserialization of untrusted data
- Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
- Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
- Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
-
SQL injection vulnerabilities (the code that handles requests to the database)
-
Reflected cross-site scripting (XSS) vulnerabilities
-
Lack of protection against unintended direct access of PHP files
- Insecure and unwarranted requests to third-party websites
Results
We found several vulnerabilities and an additional minor security issue. After notifying the developer of those issues, they have, for the most part, been resolved in version 1.2.3.
Cross-Site Request Forgery (CSRF) Vulnerability
The plugin functionality for deleting one of its tables lacked protection against cross-site request forgery (CRSF). That was fixed in version 1.2.3
SQL Injection Issues
That CSRF vulnerability also allowed for SQL injection. Here is how the function that does the deleting looks as of version 1.2.2:
function wpdatatables_delete_table( $id ){
global $wpdb;
if( empty( $id ) || !current_user_can('manage_options') ){ return false; }
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatatables
WHERE id={$id}");
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatatables_columns
WHERE table_id={$id}");
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatacharts
WHERE wpdatatable_id={$id}");
} |
function wpdatatables_delete_table( $id ){
global $wpdb;
if( empty( $id ) || !current_user_can('manage_options') ){ return false; }
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatatables
WHERE id={$id}");
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatatables_columns
WHERE table_id={$id}");
$wpdb->query("DELETE
FROM {$wpdb->prefix}wpdatacharts
WHERE wpdatatable_id={$id}");
}
The SQL statement there lacks protection against SQL injection, either through the user of prepared statement or less ideally sanitization or validation.
The value of $id used in the statement comes from the following code:
$id = $_REQUEST['table_id'];
if (!is_array($id)) {
wpdatatables_delete_table( $id );
} else {
foreach ($id as $single_id) {
wpdatatables_delete_table( $single_id ); |
$id = $_REQUEST['table_id'];
if (!is_array($id)) {
wpdatatables_delete_table( $id );
} else {
foreach ($id as $single_id) {
wpdatatables_delete_table( $single_id );
Which passes user input to the function without sanitization or validation either.
There are a number of other locations in the code where the plugin has lacked proper security for SQL statements. The other one that we found vulnerable was the function wdt_get_table_by_id():
function wdt_get_table_by_id( $table_id ){
global $wpdb;
do_action( 'wpdatatables_before_get_table_metadata', $table_id );
$query = "SELECT *
FROM {$wpdb->prefix}wpdatatables
WHERE id={$table_id}"; |
function wdt_get_table_by_id( $table_id ){
global $wpdb;
do_action( 'wpdatatables_before_get_table_metadata', $table_id );
$query = "SELECT *
FROM {$wpdb->prefix}wpdatatables
WHERE id={$table_id}";
One of the avenues for getting to that function is through the function wpdatatable_shortcode_handler(), which as the name suggest handles the plugin’s shortcode. It is possible for any logged in user to access most shortcode’s through WordPress’ AJAX functionality, so those should be a check to make sure the user should have access as well as proper security surrounding of any user input that came come through that. In this case the code lacked either of those, passing an unsantized and unvalidated user input to the function wdt_get_table_by_id():
function wpdatatable_shortcode_handler( $atts, $content = null ) {
global $wpdb, $wdt_var1, $wdt_var2, $wdt_var3, $wdt_export_file_name;
extract( shortcode_atts( array(
'id' => '0',
'show_only_chart' => false,
'no_scripts' => 0,
'var1' => '%%no_val%%',
'var2' => '%%no_val%%',
'var3' => '%%no_val%%',
'export_file_name' => '%%no_val%%',
'table_view' => 'regular'
), $atts ) );
// Protection
if(!$id){ return false; }
$table_data = wdt_get_table_by_id( $id ); |
function wpdatatable_shortcode_handler( $atts, $content = null ) {
global $wpdb, $wdt_var1, $wdt_var2, $wdt_var3, $wdt_export_file_name;
extract( shortcode_atts( array(
'id' => '0',
'show_only_chart' => false,
'no_scripts' => 0,
'var1' => '%%no_val%%',
'var2' => '%%no_val%%',
'var3' => '%%no_val%%',
'export_file_name' => '%%no_val%%',
'table_view' => 'regular'
), $atts ) );
// Protection
if(!$id){ return false; }
$table_data = wdt_get_table_by_id( $id );
The SQL statement in the function wdt_get_table_by_id() was parameterized in version 1.2.3.
Lack of Protection Against Direct Access to Files
The plugin’s .php files lacked code at the beginning of the files to restrict direct access to them. We didn’t see anything that could be exploited in the files without the restriction in place. Code to protect against that was added to many files in version 1.2.3.