Is it possible to execute some code (e.g. PHP code on a PHP-based web application) on the server through SQL injection? If yes, how exactly?

I understand that un-escaped field can lead to SQL injection and an attacker can execute SQL commands of his choice directly on the server. But I think of running only SQL commands, not some arbitrary code. Am I wrong here?

  • 2
    I just want to add that only escaping fields will not fully protect you. Attacks rely on giving malicious content and apostrophes/quotes are only a fraction of what might be used. That is why you should completely sanitize the input, checking for things other than string termination characters. The example used at OWASP illustrates this very well, as the malicious payload used only letters, space (optional), parenthesis and a semi-colon. Dec 29, 2014 at 16:44
  • 2
    Extracted from OWASP SQL Injection CheatSheet:"This third technique is to escape user input before putting it in a query. However, this methodology is frail compared to using parameterized queries and we cannot guarantee it will prevent all SQL Injection in all situations. This technique should only be used, with caution, to retrofit legacy code in a cost effective way." Dec 29, 2014 at 19:48

6 Answers 6


SQL database systems typically have an export mechanism which can write arbitrary files on the server, e. g. SELECT ... INTO OUTFILE in MySQL. If an attacker is able to assemble such a query and isn't stopped by restrictive permissions, they can in fact create PHP scripts. Now they still need to get the server to execute the script. In the easiest case, they have write access to a web directory. If they request the script, the webserver will happily execute it.

  • If your database was on another machine separate from your web server then this attack wouldn't be possible. You could create the PHP script but without an accessible PHP container to execute it you couldn't get execute it. Dec 31, 2014 at 14:18
  • The database role of the application shouldn't be able to create files in the first place.
    – Fleche
    Dec 31, 2014 at 18:00
  • 2
    @chubbsondubs thats a flawed assumption, into out file can still be used in some cases, but second order injections also come to mind. Here is an rce exploit that uses sqli and will work even if the database is on a different host:exploit-db.com/exploits/35578
    – wireghoul
    Jan 2, 2015 at 13:08
  • Interesting exploit thanks for sharing, but it's not the same exploit discussed above. Nothing is using the database to write a file to the database server. In your case it's pulling the php from the log file on the web server. Clever indeed. Just to restate what I said WASN'T implying that separating the database from web server keeps you safe as a general rule just that this exploit discussed in the answer wouldn't work if you did that alone. Jan 2, 2015 at 15:00
  • 1
    Actually @wireghoul's example exploit is exactly what the op was looking for. Better answer than the accepted answer. Jan 2, 2015 at 15:07

It depends on the type of database (MySQL, Postgres, Oracle, etc.) and the privileges of the database user.

If the application connects to the database using an administrator account, code execution is usually possible. It is straightforward on SQL Server, using xp_cmdshell. Other databases require more involved techniques. SQLmap, the most popular SQL exploitation tool, mentions this:

Support to execute arbitrary commands and retrieve their standard output 
on the database server underlying operating system when the database software 
is MySQL, PostgreSQL or Microsoft SQL Server.

For MySQL at least, I think it uses the trick of writing to a PHP file mentioned by Fleche.

From a defence point of view, this is the reason why you should never have your application connect as administrator.

  • Agreed, it's going to be very database specific and even configuration specific. On SQL Server, the ability to create files combined with ability to enable/load CLR assemblies could allow limited or vast RCE possibilities, but this would require changing default settings(for example CLR is disabled by default, and has limited permissions given the context of the account running the query).
    – AaronLS
    Dec 29, 2014 at 22:57
  • 1
    @AaronLS worth noting that earlier versions of SQL Server have xp_cmdshell available by default which leads to trivial RCE on apps with SQL Injection. In older tools that's pretty much how it was always done. Dec 30, 2014 at 15:40

Many non-trivial applications store objects in the database. An attacker with db access (such as obtained by a SQL injection) could modify them in such way that when they are unserialized, they run the intended code.

This depends on the php application to have a class with a __wakeup() method that can be abused, but the webapp author is not completely in charge of that, as there may be as well third-party classes installed on the server that could be abused.

(The SELECT INTO OUTFILE issue pointed out by Fleche is also worth to note, although *nix mysql servers are usually setup with its own user, and this attack is not possible)

  • In the serialization case you'd have to modify a pointer to the code, say a class name in the case of Java, to allow for arbitrary code execution. But then you'd have to get your class onto the classpath, and if you could do that then why bother with modifying a serialized object? If you can get something on the classpath you can just execute that code at load time. Dec 31, 2014 at 14:25
  • 1
    @chubbsondubs, serialization gives you a string like O:8:"DateTime":3:{s:4:"date";s:26:"2014-12-31 23:59:59.000000";s:13:"timezone_type";i:3;s:8:"timezone"... you can freely modify the class name (here "DateTime") and it will be loaded if it either exists in core or a loaded extension, is in the webapp, or the autoloader can find one. The attacker dream would be a class which evals() one of its members, but a class that eg. opened a filename set inside a member variable could also be very valuable.
    – Ángel
    Dec 31, 2014 at 20:08
  • The first part of your comment was exactly what I said. I could change DateTime to MySpecialAttack, but I have to get MySpecialAttack code into a place where the app would load it (ie classpath), but if I could inject something on the class path why would I bother to modify the serialized object? If a serialized class was eval'ing a member I could see why modifying a serialized class might be helpful. But the real weakness is not serialized objects it's the ability for the attacker to add something to your extensions you load. Cut that off and the attacker can't do anything. Dec 31, 2014 at 21:19
  • The point of serialization attacks are exactly that you identify a bundled class and divert its logic to the attackers benefit without placing your own code on the server. Look at some serialization exploits against sugarcrm for example. Most of those abuse the applications own theme classes to write php shells on the server.
    – wireghoul
    Jan 2, 2015 at 13:13

Besides the things already mentioned, some databases rely on code – for example, the largest part of Oracle itself is written in oracle, i.e. PL/SQL, running inside the database server. If you get an SQL injection, you can very well do things to alter the system state, sometimes beyond what the database user account allows, especially if you have a chance to combine it with a local privilegue escalation.

Oracle, at least, also allows running Java™ code in the database server by default. And maybe a couple more things…

PostgreSQL is extensible, too. You can run things like Perl scripts, not just PL/pgSQL…


Another possible attack vector would be if at any point the contents of the database are executed as code.

A pseudocode example in PHP:

$dbstring = some_db_query('SELECT some_code from some_table ...');
eval( $dbstring );

Thankfully, such a thing would not be common, but if trusted users were permitted to add code to a database, then SQL injection could overwrite it with malicious code.

I believe that the CMS Drupal has such a feature for content created by trusted users (unless they have since removed it).


What your describing would be very possible if the website is running PHP code that is stored in the database and run with eval(). SQL injection would be used to modify the PHP content being stored in the table so that the attackers code is run instead of the original content.

Another possibility would be with a remote file include attack on a file name that is pulled in from the database.

Microsoft SQL server has a stored procedure called xp_cmdshell, that will allow you to run arbitrary command-line applications. This is commonly used by hackers to upload backdoors or web application modifications through FTP.

You must log in to answer this question.

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