.htaccess deny from all auto-blocker if plugin got deactivated + WordPress internal firewall

[KestutisIT]

So, from discussion in forums, it appears,
that website may also be hacked via deactivated plugin. So I suggest,
that after a plugin has been deactivated, WordPress would automatically create .htaccess file in plugin's folder with "deny from all" content. That would prevent from non-updated deactivated plugin vulnerability, as often people believes, that they are safe if they got deactivated suspicions plugin, of they tested something and left that plugin on the server as deactivated for years.
Also, there should be WordPress internal firewall, that should show BIG RED WARNING in all WP Admin that WordPress was not able to create .htaccess blocker for some plugin, and that user has to create that file with that content manually.

This would boost WordPress security level to next class.

[carike]

:wave:
That could probably work with very low "investment" (time) required, but that would only cover Apache users, correct?
Windows servers allow for a similar file, so that *should be possible too.
What about Nginx servers?

[jdembowski]

Replying to KestutisIT:

So, from discussion in forums, it appears,
that website may also be hacked via deactivated plugin. So I suggest,
that after a plugin has been deactivated, WordPress would automatically create .htaccess file in plugin's folder with "deny from all" content. That would prevent from non-updated deactivated plugin vulnerability, as often people believes, that they are safe if they got deactivated suspicions plugin, of they tested something and left that plugin on the server as deactivated for years.
Also, there should be WordPress internal firewall, that should show BIG RED WARNING in all WP Admin that WordPress was not able to create .htaccess blocker for some plugin, and that user has to create that file with that content manually.

This would boost WordPress security level to next class.

This does not sound like a good proposal as it's not effective for a significant proportion of WordPress installations.

What about the many WordPress installations that use nginx or others that completely ignore .htaccess files? That's just not a comprehensive solution.

[KestutisIT]

Replying to carike:

:wave:
That could probably work with very low "investment" (time) required, but that would only cover Apache users, correct?
Windows servers allow for a similar file, so that *should be possible too.
What about Nginx servers?

There is Apache to NGIX converter. Maybe there has to be IF/ELSE case. In case A - .htaccess file is created, on case B - NGIX directive has been created.

There is Apache's .htaccess to NGIX directives converer:
​https://winginx.com/en/htaccess#:~:text=About%20the%20htaccess%20to%20nginx,ported%20from%20Apache%20to%20nginx.
It gives 'deny all' directive for NGIX.

[carike]

Users on a shared server (which accounts for a very large percentage of the WordPress userbase) do not generally have shell access / do not have the necessary permissions to set NGINX directives.
Do you have a proposal as to how those can be dealt with?

[KestutisIT]

Yes, I have. With PHP script you can check if you have access to that 'X' folder or not.
If you still have it, and you see it's NGIX, you put a red warning text saying.

Please immediately contact your server administrator to add this NGIX directive:

/../x-user/.../.../x-plugin/ deny all

The red warning message will help a lot. Also user will always have an option to remove that plugin from server, and red warning will disappear.

[SergeyBiryukov]

Hi there, thanks for the ticket!

This was previously discussed in #26273, let's continue the discussion there.