I've noticed that on a few notable Drupal sites (including several from the frontpage on Drupal.org), I have access to install.php, cron.php, and update.php. One site I found, which shall remain anonymous, even gave me the chance to change the database (I dropped them an email, so hopefully they'll close that up).
I'd like to open up a discussion about 1) whether or not these are security holes and 2) what (if anything) we could possibly do to make the Drupal setup scripts more secure in 7.x.
Comments
Comment #1
Anonymous (not verified) commentedI'm not seeing this behavior in 6, except for cron.php.
install.php tells me that Drupal is already installed, and I can run update.php if I want.
When I go to update.php, it tells me access denied.
Not seeing any security holes here. cron.php is accessible to the world by design, not really a way around it with shared hosts that don't provide SSH access.
Comment #2
brianpkennedy commentedIt may not be the best design to allow cron.php to be exposed the way it is. Imagine that anyone with drupal knowledge can write a very simple script to call cron.php on any website running drupal, several hundred times. Can it not be setup to run the cron job on the server as "php /DRUPAL_PATH/con.php" instead of using wget? This way you could limit the permissions of cron.php to limit its access?
Comment #3
jgoldberg commentedI understand cron.php is accessible by design. For a very large website that does intensive operations like search re-indexing in cron, though, it may be deemed a design flaw. If a goal of 7.x is to improve the scalability of Drupal, we may wish to rethink how we manage cron.
Comment #4
keith.smith commentedSee http://drupal.org/node/52910 for a discussion and proposed solution for restricting access to cron. update.php and install.php may each warrant a separate issue if they are allowing unnecessary access in some specific way.