- 🇬🇧United Kingdom catch
A session cookie seems tricky - if you set up the database in settings.php (or drop and recreate a database for an already-installed site) then reinstall through the UI, aren't you essentially doing the same thing as someone who would be trying to exploit this? Being able to install from the UI with a pre-configured settings.php is a feature.
I'm going to reclassify as a task after discussing this with @mstrelan in slack:
1. The majority of sites are no longer installed on production. They're started on local environments or dev/staging servers, and then that database gets synced to production.
2. Even if a site is installed on production, as noted in the original comments here, it needs to be discoverable, and unless it's been abandoned for a long time in the half-installed state described here, that won't be the case.
However if we can come up with something that doesn't break existing use-cases then it wouldn't do any harm.
- 🇺🇸United States greggles Denver, Colorado, USA
unless it's been abandoned for a long time in the half-installed state described here, that won't be the case
If a site is created and has an ssl cert the certificate transparency process (wikipedia and a better description) means it's a matter of hours for the site to be known. I forget the context, but I've seen some evidence that attackers are using the certificate transparency logs to identify sites to probe.
I do agree with you that it's less common in 2023 to upload Drupal and install it on the site, but I guess there are bulk hosting companies where that is still the standard.
- 🇳🇿New Zealand quietone
This was a bugsmash daily triage target to which catch has responded, adding tag.
- 🇬🇧United Kingdom catch
Thinking about this a bit more:
A session cookie seems tricky - if you set up the database in settings.php (or drop and recreate a database for an already-installed site) then reinstall through the UI, aren't you essentially doing the same thing as someone who would be trying to exploit this? Being able to install from the UI with a pre-configured settings.php is a feature.
A possible idea to mitigate this.
If we write to settings.php from the installer database form, we know we're in the UI installer, so we can write an additional flag $settings['installed_from_ui'] or similar (including a token if necessary) as well as a cookie. Then the next step(s) of the installer, can look for that as well as the cookie.
That way if you set up settings.php manually, you're not prevented from installing via the UI. If you're working locally and want to re-install, you can delete that line from settings.php to remove the protection. Would make things a bit less disruptive to use-cases, and we can include a note in the error message (similar to update_free_access).