Multiple SQL injections in server side processing php scripts
Multiple SQL injections in server side processing php scripts
jhlange
Posts: 1Questions: 0Answers: 0
The example scripts under /DataTables-1.9.4/examples/server_side/scripts/ have multiple sql injection vulnerabilities.
I don't really like posting this in the open, but I can't see a say to secure it. Since this code is copied verbatim to users' own sites, along with being used in many examples on this site, it's important to get visibility for the issue, once it is fixed.
The main premise is that mysql_real_escape_string() is being used to sanitize parts of the query which are not quoted.-- Meaning that the input strings do not need to terminate a quoted string to do their injection.
The affected files I've found are:
custom_data_property.php:
details_col.php:
id.php:
id_jsonp.php:
jsonp.php:
objects.php:
object_jsonp.php:
post.php:
Line 62: mysql_real_escape_string( $_GET['iDisplayStart'] )
Line 63: mysql_real_escape_string( $_GET['iDisplayLength'] )
Line 79: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
server_processing.php (has the code from 62/63 above, but properly sanitizes input with intval() ):
Line 79: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
filter_col.php:
Line 34: mysql_real_escape_string( $_GET['iDisplayStart'] )
Line 35: mysql_real_escape_string( $_GET['iDisplayLength'] )
Line 45: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
They are being used in this way:
$sLimit = "LIMIT ".mysql_real_escape_string( $_GET['iDisplayStart'] ).", ".
mysql_real_escape_string( $_GET['iDisplayLength'] );
When the input iDisplayLength is sent to the server as something like '1' (no quotes), everything is fine, and this gets generated:
LIMIT 1, 1
When iDisplayLength equals: 1 UNION SELECT * FROM another_table
This string gets generated:
LIMIT 1, 1 UNION SELECT * FROM another_table
I don't really like posting this in the open, but I can't see a say to secure it. Since this code is copied verbatim to users' own sites, along with being used in many examples on this site, it's important to get visibility for the issue, once it is fixed.
The main premise is that mysql_real_escape_string() is being used to sanitize parts of the query which are not quoted.-- Meaning that the input strings do not need to terminate a quoted string to do their injection.
The affected files I've found are:
custom_data_property.php:
details_col.php:
id.php:
id_jsonp.php:
jsonp.php:
objects.php:
object_jsonp.php:
post.php:
Line 62: mysql_real_escape_string( $_GET['iDisplayStart'] )
Line 63: mysql_real_escape_string( $_GET['iDisplayLength'] )
Line 79: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
server_processing.php (has the code from 62/63 above, but properly sanitizes input with intval() ):
Line 79: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
filter_col.php:
Line 34: mysql_real_escape_string( $_GET['iDisplayStart'] )
Line 35: mysql_real_escape_string( $_GET['iDisplayLength'] )
Line 45: mysql_real_escape_string( $_GET['sSortDir_'.$i] )
They are being used in this way:
$sLimit = "LIMIT ".mysql_real_escape_string( $_GET['iDisplayStart'] ).", ".
mysql_real_escape_string( $_GET['iDisplayLength'] );
When the input iDisplayLength is sent to the server as something like '1' (no quotes), everything is fine, and this gets generated:
LIMIT 1, 1
When iDisplayLength equals: 1 UNION SELECT * FROM another_table
This string gets generated:
LIMIT 1, 1 UNION SELECT * FROM another_table
This discussion has been closed.
Replies
I've also re-issued DataTables 1.9.4 with these fixes, and updated all instances of these scripts on this site. Unfortunately I'm not in a position to release a DataTables 1.9.5 at the moment, which would be the best thing to do, due to time constraints, but I will most certainly look at doing so as soon as possible. Certainly 1.10 will carry these fixes.
I must admit that I really don't like those example scripts much - darn ugly, but I guess they serve their purpose. I'm hoping to update them at some point in future to something a little more likeable...
Regards,
Allan