I made an SQL-injectable web-app build to with PHP to get a better understanding of what is going on and automated it all with sqlmap.

The relevant code is the following:

mysqli_query($conn, SELECT trans FROM `dictionary` WHERE `word` LIKE '$unfiltered_variable');

I played around with SQLMap and the only thing I was able to get was the contents of the dictionary (since this was a dictionary website) but couldn't really do anything else since PHP's sqli_query() function does not support stacked queries.

So questions:

1) Is there something that can be exploited to do something else than to get the contents of the database?

2) If the contents of the database are not meant to be kept secret, is there any point in securing this vulnerability?

  • Have a look at Union query-based injection. The capabilities will depend on the permissions of the mysql user account your website is using. This is why it is good to lock down permissions using the principle of least privilege - then SQLi can do less damage. Which other options have you investigated with sqlmap. Try dumping the database list or try getting a SQL or even an OS shell. Jul 11, 2015 at 15:31

2 Answers 2


Let's remove PHP entirely from the equation for a moment.

SQL injection allows an attacker to manipulate the SQL query to be what he or she wants the query to execute. This can be dumping the contents of the database, modifying data, and even code execution.

The example you provided is indeed vulnerable to SQL injection. For the purposes of demonstration, let me simplify it a little:

mysqli_query($conn, "SELECT trans FROM dictionary WHERE word = '$search'");

Given a value of security, the resulting query would appear like this:

SELECT trans FROM dictionary WHERE word = 'security';

This is innocent and normal. However, given the following, an attacker can obtain the version of MySQL that you are running:

' @@version -- -

This would cause the query to result in the following:

SELECT trans FROM dictionary WHERE word = '' @@version -- - ';

Ultimately, depending on permissions and configuration, an attacker can jump from one database to another in your database server, read files from the filesystem, or execute code. Here is an example of how an attacker can read files from a Linux-based OS:

' LOAD_FILE('/etc/passwd') -- -'

This then would result in the following query:

SELECT trans FROM dictionary WHERE word = '' LOAD_FILE('/etc/passwd') -- -'

There are a couple of things to keep in mind at this point:

  • Not all SQL injection vulnerabilities are the same
  • Techniques to read files, execute code, and dump databases will vary widely from language, backend database server, and the circumstances surrounding the vulnerability itself

Regardless, I would highly, highly, highly recommend that an SQL injection vulnerability be fixed through parametrization or whitelisting of user input depending on the needs of the functionality in question.

I started off with removing PHP from the discussion because SQL injection is not language and framework dependent - it impacts any language that allows database connectivity. Regardless of language, user input should be treated with suspicion and handled appropriately.


If you are restricted to the current statement, the exploitation is also limited to the capabilities of the current statement type.

In general, a SELECT statement allows:

Of course, the way the web server processes the SQL query, the permissions of the MySQL user, and the point of injection within the statement can have further restrictions on exploitation.

However, in your case, you could try to find the location of the web server’s document root directory and try to write a PHP shell into it. This would allow you the execution of arbitrary PHP code and thus commands on the web server.

You must log in to answer this question.

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