By mkhelifi on 
Hello, 
I would like if it is possible to prevent access to certain core files such as the "install.php" file. Indeed, when we go to the url "/core/install.php", we have information such as the version of drupal.

Thank you

⋅ Categories: Drupal 9.x

Comments

mitpatoliya’s picture

mitpatoliya commented

You could probably use the custom module of restrict those files using permissions 

https://www.drupal.org/docs/8/modules/flysystem/file-access-control

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

If someone types in an URL like https://www.example.com/core install.php in their browser on an operational Drupal website, they shall get a page saying "Drupal already installed" and they will indeed see what version of Drupal is installed.

This is how this happens to be designed. I don't perceive this as a vulnerability. If you think it is, you may try to file a request in the core issue queue where you make a case for getting this information removed from the page.

However, if you want to restrict access to webserver to any file in core, just change the permissions bit of the file in the filesystem to deny the web server READ access to the file.

Of course, if you do this, and the file is actually required for the site to operate, this will also break your site.

It is probably OK do this with /core/install.php after you've installed Drupal, since this file is not needed beyond this point, but using the permission bits is not really a general solution to the question you ask, and I don't think this is the right way to do it.

- gisle

mkhelifi’s picture

mkhelifi commented 
I'm actually not sure if that's the right way to do it. It was my client's IT support that raised this point for me. For them, it is a vulnerability. Thank you both for your feedback.
apotek’s picture

apotek commented

On one of our client sites, core/install.php takes about seven seconds to load. We just had a site outage this morning because someone was hammering that url until our client's php-fpm pool ran out.

The page returns cache headers that make the response uncacheable by your CDN so repeated requests do go to origin every time.

cache-control
must-revalidate, no-cache, private

So while you are absolutely right that the page is not a security risk, it can easily be abused for DDOS purposes. Someone could bring your site down with a relatively low request rate of 1 or 2 requests per second (too low for your rate limiter or WAF to think anything is wrong).

So I absolutely recommend that, in a public environment, requests to this endpoint be blocked. Or remove that file. Some options:

1. When you build your deployment artifact, script the removal of that file.

2. Or use a composer install hook to remove that file after composer installs your dependencies.

mah ham