Since they're using SQL Server (hint is that they are checking for "xp_"), you can get a list of all of their databases with "SELECT name FROM sys.databases", then loop through and drop them. Hope the web login doesn't have drop permissions.
Heh. One of the best protections against SQL injection is not to grant those privileges to the db account from the webserver. So many sites could protect themselves at the least from data loss by using the built in tools. Also, I've worked on projects where the only way to change a table is via a stored proc, no select access on the tables, no SQL injection. Or at least you'll have to figure out a way to to the injection into the stored proc which is nigh impossible unless they are using exec_sql in the store proc.
Why the downvotes? It is common sense to not run software with more permissions than it needs. Your production app shouldn't connect to your database through the root account, for example, unless it needs full, complete permissions to function. Not likely.
Of course, this does not eliminate the need for solid code-based prevention of injections...
If you take away write-access privileges, then malicious script still can steal your data.
Most of the time - that's really bad by itself even if you keep your copy of data intact.
Are they actually vulnerable? How do you know? People have gotten in serious trouble in the UK for "innocuously" testing web apps for SQL problems. Know that in both the UK and the US, you are taking a significant risk by prodding websites like this.
"Testing" a web app when it is not your job to do so is self evidently a suspicious act, just like walking down a line of cars testing the door handles to see if any have been left unlocked would be a suspicious act.
If destruction isn't your fetish, you could also get all of the table names from the databases, and use sp_send_dbmail to send the SELECTs for all of them to your email address. There might be an easier way to get the data out though.
