PHP in database: bad practice but

Question

Lots of times here I've been told that using views custom php fields, filters or others is a bad practice, because putting php in the sql is dangerous.

My question is, if you only call to a function, that you defined in a module, is it still as bad?

Sometimes, especially for Views, making a custom handler, or, other example, a custom token, can be really heavy.
What are the risks if I make a custom field that only calls a function? Is it as dangerous and "forbidden"?

Answer 1

Here's my take on it:

The PHP docs says about eval:

Its use thus is discouraged

It is always, let me emphasize that again, always, bad to use the PHP module (technically eval, but the PHP module makes a dangerous language feature much worse).

Details discussed in this question: What are the downsides of using PHP Filter code in blocks, nodes, views-args, etc?

The link provided by Clive claims

Sometimes eval is the only/the right solution.

It is possible that this is true, some times, but during quite a few years of professional development, I have never stumbled across a real need for it, in PHP or other languages.

Personally, I've taken it to the level that my servers disable the functionality on the php level itself, with disable_functions = eval.

With that said, on a small personal website, it's likely of less consequence than on a large enterprise one, and there are cases where it's at least not completely horrible to use it.

Answer 2

There are some great answers here, but I don't think they address why it's a security issue to allow php execution inside the CMS.

In my opinion the problem with php.module and other modules that do their own eval is that it makes it so anyone who can exploit your Drupal site (see note below) has the ability to run arbitrary php. The WordPress brute force attack going on now is getting admin (i.e. uid 1) permissions on WordPress sites. If that gives someone the ability to just deface the sites then that's a meddlesome problem, but not much more. If it gives them the ability to run arbitrary php (which it usually does) then it's horrific for those sites, other sites hosted on the same server, and even the internet as a whole: the sites become a massive botnet that can do whatever their owner wants.

If WordPress didn't allow php execution would it be a worthwhile target for this attack? Probably not.

So, what can you do? letharion's tip about disable_functions is a great one. There's also the paranoia module which can help reduce people's ability to execute php.

• Note: I said "exploit your Drupal site" which is pretty generic. It could be done via brute forcing an admin password, social engineering access to email and then doing a password reset mail, session sniffing, an XSS attack or maybe even a few other ways. But once an attacker has that kind of attack...the eval feature means your whole server becomes a great tool for the aettacker.

Answer 3

Be aware adding invalid PHP code to a form textarea can bring your site offline with a fatal error. It also makes it difficult to determine where functionality is being added from, if nothing can be found in the source code files and is instead in an obscure database field.

While it's tidier to call a function defined in a module, where the source code can be tracked properly, if you're going to do that, it's recommended to export and store those Views etc.. using a module like Features so that the configuration and code can be tracked properly in version control.

In most cases there's an API equivalent where the PHP code would better reside, for example hook_block_view or a custom Views argument handler.