I just found an injection vulnerability on a live site of a client. It looks like this:

$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" .     $Pword . "'";

I successfully "hacked" it using wikipedia examples, so it ought to be pretty bad vulnerability.

The site has been like this for many years.

I know how to fix it, but since I don't know much sql, I am worried about backdoors.

Would I be still exposed after fixing this? What backdoors could there be left?

Eg could an attacker have already gained total access, like mysql user and pass and not even need injections in the future? Do I need to change user and pass? What else?

The Database gets used by multiple sites, so im pretty sure its cross domain enabled.

  • 2
    Without a detailed forensics process it's very difficult to tell what happened. In your case, assume the worst.
    – Adi
    Commented Jun 17, 2013 at 0:35
  • 1
    I think the question is basically "What is the worst?" Commented Jun 17, 2013 at 2:01
  • @KenB Exactly what the OP is thinking. Full compromise and the existence of a backdoor.
    – Adi
    Commented Jun 17, 2013 at 3:03
  • Exactly, there may or may not be a compromise. The question is what to do? Would changing mysql user and pass be sufficient? Commented Jun 17, 2013 at 4:46
  • Practical example: Some university here left port 80 open for users so that they could host servers there. Someone had an unprotected wamp installation (windows, apache, mysql, php, phpmyadmin), and I was able to compromise his laptop entirely (admin account) by using a simple INTO OUTFILE statement and then calling the php script remotely. LIke Adnan said, without analysis you should assume the worst.
    – Luc
    Commented Jun 17, 2013 at 7:19

2 Answers 2


As @Adnan says, the worst is "Full compromise and the existence of a backdoor.". Why? While playing with SQL alon can't lead to any compromise of the system itself (just reload the datatabase from a backup and you ought to be set), the programs using SQL and interacting with the system have much higher capabilities.

For example, there's a chance that you have a table containing PHP template snippets. An attacker can edit that and add malicious code. If anything from the SQL tables is being executed (or even dumped to a file -- if the file can be dumped to the web folder, then an attacker could use it to inject and run his own PHP), then you may have a problem.

So find out where all the data in the tables is used. If, at any point, it is being saved or executed, see if this is exploitable (in the case of the former, it depends if the attacker can put arbitrary text in the web folder using it. In the case of the latter, it's almost always a problem). If so, there's a chance the system was compromised, and you may want to do a clean install.

If not, then just look for problems in the tables and fix them if present. Make sure you change your username/password (and check for rogue accounts)

An interesting thing to note is that in SQLite, the ATTACH DATABASE command can be used to directly introduce vulnerabilities.

Similarly, the SPOOL command in SQL* Plus can be used if the injection allows for multiple commands to be executed.

If you're using either of the above two, a clean install would be good regardless of how the data is being used.


An SQL injection alone CAN lead to a full system compromise. There are many ways from databases to access the local file system via read and write operations. Lets consider the database is running as 'root' then it would be trivial to read the /etc/shadow file. Also, lets assume you can read the local users table of the database (select user,pass from mysql.users for example), and after cracking trivial hashes you May be able to SSH into the host using the same credentials (abusing password reuse). Also, and probably more commonly you can execute operating system commands from the database itself. Xp_cmdshell can be used on SQL Server, User defined functions can be created on MySQL and there are a whole raft of ways to do this on Oracle - creating Java functions is just one!

If your database has been compromised and you have not gone into any steps to lock it down, or harden it then you can assume that worst - that the attacker has privilege escalated on to the operating system itself.

  • it has not been compromised (afaik) but, an attacker could have quitely had access for years. Thx for info! So basically, would it be enough to change user pass on mysql + close injection? I guess not really :/ Commented Jun 17, 2013 at 9:00
  • It may be enough - it may not. Its hard to tell without seeing how it is configured. For example, if its running as the mysql user and not root, then thats good, also if its patched to a fairly recent version, thats also good. Review the mysql general query log and see what has been executed - may show what has been compromised in the past!
    – fixulate
    Commented Jun 17, 2013 at 9:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .