1

I have Mysql database with an API tied to it to call and run PHP code stored in that database. Yes, you heard right, PHP Code stored and run from a Mysql database. So, this is pretty serious from a security standpoint, and that is my dilemma. Your first suggestion might even be,"NO, Bad!". Fear not, it can be done. There are a few good reasons for doing this.

  1. 40x speed increase (no HD reads)
  2. Automatic Dependency Injection.
  3. Other Programming Languages.

Security.

Input sanitation would "seem" to be the most important thing here, and my filter is top notch. SQL Injection would be your worst nightmare.

My question is this: When running live code from a database, can it be defendable, can it be attacked? What attack vectors could be possible? And how could you defend?

In summary, I need expert advice, Worst-Case, Best-Case, Do this, Don't do this. You are insane, something.

UPDATE1: I will be reading all comments over and over, The Truth Matters.

  1. I am using a percona mysql cluster, measurable speed is occurring (stored in ram)
  2. Versioning is easy (and built in) Got a table with L(language) FunctionName Vars Deps RequiredVars VERSION# etc...etc.
  3. I Would add for interest level, that An application could be mostly integer based, in which case input can be sanitized by casting to (int) (IE. $num = (int)$_GET['s']; )
  4. I highly welcome ideas, suggestions, and topics. As I believe this breaches many barriers while reaching new ones and am now fully willing and pre-dedicated to figuring this out, that part is a done deal; O, The Humanity! But I believe this CAN be successfull.
  5. Another added benefit is language neutrality, since I store my code in a database, labeling one code as PHP and one as RUBY or PYTHON, has serious uses. Nothing a little php-shellexec action cant make beautiful (again with near-perfect input sanitation in mind)

Will Continue to update (i have a busy schedule, but I will be as attentive as I possibly can.)

Improve this question
7
  • 3
    In order to identify possible attack vectors we would first need to know how that code gets into the database. Can it be changed at runtime? How and by whom? Commented Dec 27, 2016 at 16:11
  • Your worst case is that the hacker, get your actual source code, find a bug(or credentials,etc) in it, and exploit it. Very careful setting of permissions is necessary. Any access from the web through nginx,apache, or etc should be limited. I would have a 2nd user account with only the ability to execute routines. Commented Dec 27, 2016 at 16:13
  • This is stupid for so many reasons, the biggest one is that you can't use version control on the code. How are you going to work efficiently without that? Commented Dec 27, 2016 at 17:18
  • I think this could be a really interesting question, but right now it is way to broad. Could you edit and add more details about your use case. Who should be able to edit the code? Are you just using the DB as a replacement for the file system, or are end users somehow supposed to be able to change/edit the code? Commented Dec 27, 2016 at 20:29
  • 3
    Regarding your update, you do know that you can easily mount a tmpfs filesystem that is kept in RAM? Just do that in a script when the server starts, copy your code there and enjoy your performance "benefits" (hint: the speed at which the code is read is rarely, if ever, the bottleneck in real world applications). Commented Dec 27, 2016 at 23:36

3 Answers 3

Reset to default
5

General Thoughts

This seems like an awful idea for production. If you just want to try stuff out, that's another matter.

I also don't see how it is an advantage. Regarding your points:

  1. Where is your db located? Why would you assume that it doesn't require hd reads? And if you think db results are stored in ram, why not php code from files? And have you actually profiled this? For a large scale? I would assume a large speed decrease (and that is not even considering things like not being able to use php caches).
  2. Really? How? And couldn't you just use a library for that?
  3. What? I don't think that this really counts as language neutral

You also need to consider that debugging will be quite difficult, which is probably the biggest downside. Developing and deploying new code will likely also be more difficult.

Threats

The things you need to worry about with your approach:

  • Being able to write to the code database will lead to code execution. Writes could take place via injection, or by reading out or bruteforcing the database password (if an attacker is able to connect to the database).
  • Being able to inject into the SELECT code database queries will lead to code execution.

Mitigations

Anyways, if you still want to do this (hint: don't), there are a couple of things you can do to make it a bit more secure:

  • Store your PHP code in a separate database, accessible with a different user. The user that retrieves normal data from the database should have no access to this database.
  • Don't allow remote access to the code database, and obviously use a secure password. Don't use things like phpmyadmin, which would in effect allow remote access to the database.
  • Don't put user input in queries running against the code database.
  • Ideally don't perform queries against this database all over the place. You probably only need one or two functions which select the code you want. Use prepared statements for those.
  • Think about only giving the code database user read access to the code database (if this makes sense in the context of your application).

Also, the proper defense against SQL injection is not input sanitation or filtering (it will go wrong), but prepared statements. Casting input to ints is great as defense in depth, but in practice, it is miserable as only defense. I have seen many application that take that approach (plus ecaping/filtering for non-int), and it never goes well.

I assumed that you store your PHP code in the db and execute it with eval, but most of the points will likely apply with other approaches as well.

Improve this answer
1
  • I do use eval, i am looking to find another one for function init, becuase it errors as no values passed, quite annoying, but ya eval. Commented Dec 27, 2016 at 21:35
2

40x speed increase (no HD reads)

OMG, NO.

enter image description here

If you've got a setup where code read from the DB runs 40 times faster than code read from files then that configuration is fundamentally broken. That you don't know this already makes me think you are nowhere near ready to try something as esoteric as what you describe.

Unless you have rewritten the PHP loader or its interface to the opcode cache, then you will be parsing and compiling (and optimizing if it's using the Zend opcache) each time you fetch code from the database. If this is running faster than reading files from the filesystem then you have no opcode cache, it is very badly configured, you have some horrendous problems with your filesystem or VFS caching. Something is very, very wrong.

Automatic Dependency Injection

No. There is no way for the system to magically know what your code dependency looks like. It is possible to define a framework which is effectively scripting this - but this is also possible without having to keep your PHP in a database.

Other Programming Languages.

What about them? Most programming languages allow you create constructs which invoke code written in other languages. Both PHP and MySQL can call shared libraries which have been written in a way that can invoked by the same thread/process. But this really is rocket science stuff and very dangerous if you don't know what you're doing (it's rather dangerous when you do know what you're doing). PHP on the other hand comes with many well-written extensions for manipulating data (encryption, image handling, network functions....). Many more than MySQL does. It also comes with support for invoking other processes with uni- or bi-directional communication.

Input sanitation would "seem" to be the most important thing here, and my filter is top notch

You should validate input and sanitize output. I'll give you the benefit of the doubt here and assume you mean the input to the system as a whole and not just one tier. However (if your justifications were valid) I would be doing a lot of shouting at anyone working for me who stored executable code accessible / modifiable by the same account which accessed/modified data in the database. Even then this carries huge risks of code injection/modification.

mostly integer based

= not just integer based. I do hope you are using a better method where the input may be something other than an integer.

The only remotely justifiable reasons I can think of for attempting such an architecture are:

  • where you provide a (very heavily sandboxed) facility to run user-submitted code in
  • where you want to provide a mechanism for change management in a large server farm (but here again I would take issue with the architecture as innefficient, dangerous and ineffective while being achievable by using code stored in files).
Improve this answer
3
  • +1 because all those points are valid. Note though that the main question here should be about the security aspect. OP may want to consider asking the same question - with a different focus - at eg softwareengineering.SE, where this would be a great answer. Commented Dec 27, 2016 at 23:41
  • definitely points to consider deeply. Commented Dec 28, 2016 at 16:26
  • LOVE that picture, lol. Commented Dec 29, 2016 at 1:02
1

I don't see your mentioned advantages are valid and outcome the cost as the following are some threats and downsides you should pay attention to:

  1. As your DB is increasing, your fetching speed is slower and slower which will affect the whole performance of the website especially when you will have nested fetch: Like your code in the DB is accessing the DB again for other data!.

  2. Very hard to maintain your code:

    • Editing is costly: To change one character in your code, you have to update the whole code text via SQL command.
    • Testing is costly: For every change or failure, you have to update the whole text via SQL command.
    • Debugging is impossible.
    • No support from source versioning control (SVN, GIT, CVS..etc).

  3. No permission control so you need to have more access and authorization controls on DB level which is more costly and harder to implement.

  4. Availability issue if the DB is not available.

  5. If you have a DB leakage, then you will have code leakage also which will may reveal more information and doors into your infrastructure.

  6. Code injection attacks will be easier and have more impact... imagine uploading a shell via SQL injection only.

  7. No audit or last modify to check if any code is changed without your knowledge.

Improve this answer
2
  • All of these can be overcome, but it will cost him in terms of time spent reinventing the wheel. Versioning could be done by copying changes to an archival table using a trigger. His app is probably DOA if the DB is down, so he may not care. Auditing can be automated (again by a trigger) and might even be easier than monitoring the file system. He's already wired it all together so those costs are already spent. It's the security that seems to be the big problem - injection and permissions. I don't think it's nearly as negative as it's being painted. Commented Dec 27, 2016 at 19:13
  • I see both your points complete, and the above comment is correct, many expenses (versioning, editing, archival, etc are done. Security is the issue) lol DOA lol. Ya no db, no care. Commented Dec 27, 2016 at 21:31

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.