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.