[development] Remove PHP filter by default
ber at webschuur.com
Sun Jan 29 20:26:44 UTC 2006
Op zondag 29 januari 2006 18:18, schreef Karoly Negyesi:
> The problem is in restriction. Folks, understand this: as long as PHP
> filter is there, all you need is one broken contrib module and your site
> is dust. Also, I know that many shops won't even consider Drupal for this
> filter because it's too risky. If you need to say "no it's not because"
> then you have lost the argument because if you need to reason then it's
> not secure enough. (And yes, input filtering is also needed but let's
> leave something for the spring, too :) ).
The very fact that the input filter is there, is what bothers me most. Yes, it
can be restricted. It can be turned off. But you need to know about all the
ways to get there.
We have investigated the ways to become SU. in drupal 4.7 there are at least 7
totally different ways of rooting (for becoming SU is that, exactly) a drupal
site. Nearly all are related to gaining PHP rights, then using that to change
the PW of SU.
So in order to be completely secure, you have to:
* turn off "administer user" rigths (unreated to PHP filters)
* give no-one administer permissions. resulting in not allowing half of the
modules to be switched on-off, rendering flexinode (for example) unusable and
more. (we really need to find some way to cascade this, so that a users can
never give anyone more rights then he has)
* give no-one "administer input filters" rights (very unhandy if you want
ppl to control wiki syntax or so)
Or, in other words: to maintain a secure network of sites, you must configure
them to be hardly unusable, because you need to turn off a lot of crucial
features. PHP input is the biggest contributor of all this.
So, if we want Drupal to be the hosting tool, developers tool and JoeSchmoe
tool, we really need to chop out a lot of functionality and stick that into
modules that can be removed. Because a non-existing module is nothing to
worry about. Developers should (IMO) not even consider using php input, they
should deliver it with acme_inc_custom_code.module (or so).hosting providers
will want to be 500% sure that no-one can run arbitrary code. Never. And Joe
User wants to copy-paste. Only for the latter the PHP input is really needed.
Also note (unrealted, but certainly worth thinking abuot) that Rasmus pointed
uot that eval'd code performs worse and uses more memory.
And that did not even get me started about the upgrade hell when you have a
lot of b0rken PHP input (no longer existing API calls) making your site
All in all, it boils down to: Drupal is fine to ship with all the PHP input
stuff, but it must be able to get rid off it. Completely. We need to work on
PGP ber at webschuur.com
PGP berkessels at gmx.net
More information about the development