SQL Injecting PhpMyAdmin(0x000000.com)
0x000000.com
SQL Injecting PhpMyAdmin
http://www.0x000000.com/?i=587
4 comments
Not real likely to be attacked, since they would not only need to know the database name, but the address of the PHPMyAdmin install. But hopefully it's addressed quickly.
Now if the title was "CSRF against PhpMyAdmin" then it would make more sense. Given that PMA has a form dedicated to letting you run arbitrary SQL statements, the fact that it allows arbitrary statements to be run is not news.
CSRF attacks are weak. You'd have to know my website's phpMyAdmin location (if I used phpMyAdmin) and my table names in order to do this. CSRF attacks are only scary when they effect major websites.
CSRF attacks are strong. I can write an attack that tries dozens of different potential combinations of URL and table names just as easily as I can attack one.
Not to mention that many people use their web host's one-click install tool which always puts scripts like phpMyAdmin in the same place.
Not to mention that many people use their web host's one-click install tool which always puts scripts like phpMyAdmin in the same place.
But you still need to know the address of the site. You'd need to create a new attack site for every victim. And then lure the victim there after they had just been in PHPMyAdmin. Not exactly like a CSRF in Facebook or something.
It should definitely be fixed, but it really is a weak attack.
It should definitely be fixed, but it really is a weak attack.
What if you're using a common application like WordPress or Movable Type where the database and table names are known?
the solution is simple, give access to your database only to people you trust and don´t access to your super important database from a public location using phpMyAdmin!
That's not a solution. You can read more about XSRF and how to protect against it: http://en.wikipedia.org/wiki/Cross-site_request_forgery
I have my phpMyAdmin installed only on my secure site, behind HTTP authentication as well.
If you're using HTTP Basic auth, your browser will happily cache the credentials and re-submit them every time when asked for the same server/realm combination. You'll need to restart your browser to clear the cached auth data.
The reason CSRF is scary is that it works against those defences.
Actually, the solution is not to ever use phpMyAdmin on a public web server. Just like Webmin, and every other tool that has god-like power over critical system resources, it should be on a private IP, accessible only from trusted systems via an encrypted, strongly-authenticated channel.
This doesn't help. If you use the same web browser for using phpMyAdmin that you use for visiting the attacker's site, you're hacked.
"Strongly-encrypted channel" basically means VPN in my book. If the phpMyAdmin server isn't on a publicly-routable IP, and you don't have the VPN tunnel open when you aren't using the secure host, then it will in fact defeat CSRF.
Again, CSRF defeats those defences.