We have an Ioncube encoded script running on an Apache web server which stores customer confidential information in a MySQL database. We have configured the script to run under its own account using suphp. As usual the script reads the database credentials from a 'config.php' file. We'd like to mitigate the risk of the database contents being exposed through a zero day exploit. The web server OS, Apache and MySQL have been hardened. Is there anything we can do to lock down this script further. For example, if someone did exploit the script, I assume they would end up with the same privileges as the suphp account that the script runs as - Would they attempt to mysqldump the database? Should we be restricting access to all the mysql binaries?

2 Answers 2


You didn't mention MYSQL injection attacks in your list of precautions. Also you could reduce the permissions of the mysql user for the database. Usually people give the user all rights but you can restrict the mysql user's ability to do ALTER, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EXECUTE, INDEX, INSERT, LOCK TABLES, REFERENCES, SELECT, SHOW VIEW, TRIGGER, and UPDATE. Only give the mysql user permission that are needed to run your script.


A defense in depth approach is to plan on failure and to limit what privileges you give to your application and to your administrators.

That being said Ioncube protected scripts are a joke, all code obfuscation is very easy to undermine in PHP using runkit. If you are relying upon this as a means of protecting some kind of password then you have a very serious problem on your hands. An 0-day isn't required because you are not doing anything to protect your secrets.

This reminds me a lot of the Super Meat Boy MySQL hack, the developer had a desktop application that was directly connecting to a mysql server. Needless to say the developer was hacked to tears.

No amount of cryptography can solve this problem. It is never acceptable to allow an attacker to connect to your database. You must implement an API that limits the access accessible to the client.

  • Thanks, but we didn't make the choice of ioncube encoding the script. Our business purchased the script and my responsibility is to do my best to secure it. What do you mean by "It is never acceptable to allow an attacker to connect to your database."? - Why do you think I believe otherwise? Thanks.
    – Michelle
    Commented May 30, 2012 at 9:08
  • @Michelle - It also is your responsibility to point out the flaws in your setup.
    – Ramhound
    Commented May 30, 2012 at 11:55
  • @Michelle Ok so, you are doing nothing to protect the password. I can just hook the mysql_connect() function and print out the password in plain text. Or maybe sniff the write and crack the handshake, you probably are not connecting over ssl. Obfuscation cannot help you in this situation, you are only fooling your self.
    – rook
    Commented May 30, 2012 at 13:48
  • 1
    @Rook The password is stored in the config file and only the owner can read the file (the suphp account). Of course you can use the mysql_connect function to connect to the database and do what you want. Connecting over SSL? The script is accessing a local database, what has SSL to do with it? I really don't think you understand my question, but thanks fwiw.
    – Michelle
    Commented May 30, 2012 at 17:48
  • @Michelle You need to be more clear about what you are trying to do. So Ioncube isn't a security measure and you aren't relying up on it. I have no idea what you are asking.
    – rook
    Commented May 30, 2012 at 18:20

You must log in to answer this question.

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