On 03/23/2016 08:21 PM, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using
readline 5.1
I spotted something strange and immediately installed a routine to
automatically impose an iptables block when the key used for database
access is excessively long.
My URL was something like this
...../...../.....php?key=123456
The injection was something like this
...../...../.....php?key=876711111111111111111111111111' UNION SELECT
13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM
information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /*
order by 'as
There are no user permission on information_schema.
There seems to be 2 versions of the coding floating around on Austrian
and Russian IPs. One is ineffective but the other works. It seems the
author is expert in the intricate structure and design of SQL.
Always use parameterized statements (aka prepared statements) for SQL
that involves untrusted input.
I like to use them even for input that involves trusted input because it
is easy to make a change in my code and not think about how it impacts
the parameters.
-=-
This is an attack on WordPress ??? Or just trying to get WordPress
database from a different app?
Be careful with WordPress - it's database handler doesn't actually use
parameterized statements, it emulates them with printf - one (of many)
reasons I do not like the product.
If it is not an attack on WordPress directly - your WordPress database
should be using a different uname/pass from anything else, so actual
queries for data should fail.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
